The pointer div_addr is being assigned a value that is never used, it is
being re-assigned a different value near the end of the function where
it is being read in the next statement. The initialization is redundant
and can be removed.
Cleans up clang scan build warning:
drivers/clk/xilinx/clk-xlnx-clock-wizard.c:501:16: warning: Value stored
to 'div_addr' during its initialization is never read [deadcode.DeadStores]
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Link: https://lore.kernel.org/r/20240223134347.3908301-1-colin.i.king@gmail.com
Reviewed-by: Michal Simek <michal.simek@amd.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Commit eaae75754d ("docs: turn off "smart quotes" in the HTML build")
disabled conversion of quote marks along with that of dashes.
Despite the short summary, the change affects not only HTML build
but also other build targets including PDF.
However, as "smart quotes" had been enabled for more than half a
decade already, quite a few readers of HTML pages are likely expecting
conversions of "foo" -> “foo” and 'bar' -> ‘bar’.
Furthermore, in LaTeX typesetting convention, it is common to use
distinct marks for opening and closing quote marks.
To satisfy such readers' expectation, restore conversion of quotes
only by setting smartquotes_action [1].
Link: [1] https://www.sphinx-doc.org/en/master/usage/configuration.html#confval-smartquotes_action
Cc: stable@vger.kernel.org # v6.4
Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/r/20240225094600.65628-1-akiyks@gmail.com
[WHY]
Some eDP panels' ext caps don't write initial values. The value of
dpcd_addr (0x317) can be random and the backlight control interface
will be incorrect.
[HOW]
Add new panel patches to remove sink ext caps.
Cc: Mario Limonciello <mario.limonciello@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org # 6.5.x
Cc: Tsung-hua Lin <tsung-hua.lin@amd.com>
Cc: Chris Chi <moukong.chi@amd.com>
Reviewed-by: Wayne Lin <wayne.lin@amd.com>
Acked-by: Alex Hung <alex.hung@amd.com>
Signed-off-by: Ryan Lin <tsung-hua.lin@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
clkdev DEV ID information is limited to an array of 20 bytes
(MAX_DEV_ID). It is possible that the ID could be longer than
that. If so, the lookup will fail because the "real ID" will
not match the copied value.
For instance, generating a device name for the I2C Designware
module using the PCI ID can result in a name of:
i2c_designware.39424
clkdev_create() will store:
i2c_designware.3942
The stored name is one off and will not match correctly during probe.
Increase the size of the ID to allow for a longer name.
Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: Michael J. Ruhl <michael.j.ruhl@intel.com>
Link: https://lore.kernel.org/r/20240223202556.2194021-1-michael.j.ruhl@intel.com
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
The adev can be found from bo by amdgpu_ttm_adev(bo->tbo.bdev),
and adev is also not used in the function
amdgpu_amdkfd_map_gtt_bo_to_gart().
Signed-off-by: Eric Huang <jinhuieric.huang@amd.com>
Reviewed-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Fix mask used for esm ctrl register to get pcie link
speed on smu_v11_0_3, smu_v13_0_2 & smu_v13_0_6
Fixes: 511a95552e ("drm/amd/pm: Add SMU 13.0.6 support")
Fixes: c05d1c4015 ("drm/amd/swsmu: add aldebaran smu13 ip support (v3)")
Fixes: f1c3785931 ("drm/amd/powerplay: add Arcturus support for gpu metrics export")
Signed-off-by: Asad Kamal <asad.kamal@amd.com>
Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
Reviewed-by: Le Ma <le.ma@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Skip reporting pcie link width/speed on vfs for
smu_v13_0_6 & smu_v13_0_2
Signed-off-by: Asad Kamal <asad.kamal@amd.com>
Reviewed-by: Yang Wang <kevinyang.wang@amd.com>
Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
v1:
enabel pp_od_clk_voltage node for gfx 9.4.3 SRIOV and BM.
v2:
add onevf check for gfx 9.4.3
v3:
refine code check order to make function clearly.
Signed-off-by: Yang Wang <kevinyang.wang@amd.com>
Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
When building with CONFIG_SYSFS=n, the build error below is triggered:
ld: drivers/power/supply/power_supply_core.o:(.data+0x0): undefined
reference to `power_supply_attr_group'
The problem is that power_supply_attr_group is needed in
power_supply_core.c but defined in power_supply_sysfs.c, which is only
targeted with CONFIG_SYSFS=y. Therefore, move the extern declaration into
the #ifdef block that checks for CONFIG_SYSFS, and define an empty static
const struct otherwise. This is safe because the macro __ATRIBUTE_GROUPS in
power_supply_core.c will expand into an empty attribute_group array.
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reported-by: Nathan Chancellor <nathan@kernel.org>
Link: https://lore.kernel.org/all/20240227214916.GA3699076@dev-arch.thelio-3990X/
Fixes: 7b46b60944 ("power: supply: core: constify the struct device_type usage")
Signed-off-by: Ricardo B. Marliere <ricardo@marliere.net>
Tested-by: Nathan Chancellor <nathan@kernel.org> # build
Link: https://lore.kernel.org/r/20240228-device_cleanup-power-v1-1-52c0321c48e1@marliere.net
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
rk3588 syscon clock fixes and removal of overall clock-number
from the rk3588 binding header and a prerequisite for later
improvements to the rk3588 linked clocks.
-----BEGIN PGP SIGNATURE-----
iQFEBAABCAAuFiEE7v+35S2Q1vLNA3Lx86Z5yZzRHYEFAmXe7ScQHGhlaWtvQHNu
dGVjaC5kZQAKCRDzpnnJnNEdgdLPCACLFH4I+aJ8OV/SuKW+NroDpgss39x082YV
wpYp3Q+JEh7K2ZoESmvaqm1Fi5B5bCSo10LBgcC343S/rkmQGrXKSRYScfMDVR6K
GGSz/o+Aub4WdUFjsZbj+lI97XslFuReBSNQftz5ZgNXH1HObX69dqAJXhX6Pdmg
nbQ92PG8FJxjOlRvJGOhhs91c7UQwPWEY87xsJze2Vbv3oYZzbDVuXRtjwB20OMP
J0fIpRSZvLd/89s6BamOKyKXkBuAJuuoF9S3jm54/EDcqkZO6hY7fTR95jSTOmHh
eE3vc2F5G3kHWjNFIvqlA7izzlavd150qFYwqi6LGstwbdQWg/Lp
=SPXE
-----END PGP SIGNATURE-----
Merge tag 'v6.9-rockchip-clk1' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into clk-rockchip
Pull Rockchip clk driver updates from Heiko Stuebner:
- New pll-rate for rk3568
- i2s rate improvements for rk3399
- rk3588 syscon clock fixes and removal of overall clock-number from
the rk3588 binding header
- a prerequisite for later improvements to the rk3588 linked clocks
* tag 'v6.9-rockchip-clk1' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip:
clk: rockchip: rk3399: Allow to set rate of clk_i2s0_frac's parent
clk: rockchip: rk3588: use linked clock ID for GATE_LINK
clk: rockchip: rk3588: fix indent
clk: rockchip: rk3588: fix pclk_vo0grf and pclk_vo1grf
dt-bindings: clock: rk3588: add missing PCLK_VO1GRF
dt-bindings: clock: rk3588: drop CLK_NR_CLKS
clk: rockchip: rk3588: fix CLK_NR_CLKS usage
clk: rockchip: rk3568: Add PLL rate for 128MHz
When building without CONFIG_SYSFS, there is an error because of a
recent refactoring that failed to update the stub of
power_supply_init_attrs():
drivers/power/supply/power_supply_core.c: In function 'power_supply_class_init':
drivers/power/supply/power_supply_core.c:1630:9: error: too few arguments to function 'power_supply_init_attrs'
1630 | power_supply_init_attrs();
| ^~~~~~~~~~~~~~~~~~~~~~~
In file included from drivers/power/supply/power_supply_core.c:25:
drivers/power/supply/power_supply.h:25:20: note: declared here
25 | static inline void power_supply_init_attrs(struct device_type *dev_type) {}
| ^~~~~~~~~~~~~~~~~~~~~~~
Update the stub function to take no parameters like the rest of the
refactoring, which resolves the build error.
Fixes: 7b46b60944 ("power: supply: core: constify the struct device_type usage")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Ricardo B. Marliere <ricardo@marliere.net>
Link: https://lore.kernel.org/r/20240227-fix-power_supply_init_attrs-stub-v1-1-43365e68d4b3@kernel.org
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Puranjay Mohan says:
====================
bpf, arm64: use BPF prog pack allocator in BPF JIT
Changes in V8 => V9:
V8: https://lore.kernel.org/bpf/20240221145106.105995-1-puranjay12@gmail.com/
1. Rebased on bpf-next/master
2. Added Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Changes in V7 => V8:
V7: https://lore.kernel.org/bpf/20240125133159.85086-1-puranjay12@gmail.com/
1. Rebase on bpf-next/master
2. Fix __text_poke() by removing usage of 'ret' that was never set.
Changes in V6 => V7:
V6: https://lore.kernel.org/all/20240124164917.119997-1-puranjay12@gmail.com/
1. Rebase on bpf-next/master.
Changes in V5 => V6:
V5: https://lore.kernel.org/all/20230908144320.2474-1-puranjay12@gmail.com/
1. Implement a text poke api to reduce code repeatition.
2. Use flush_icache_range() in place of caches_clean_inval_pou() in the
functions that modify code.
3. Optimize the bpf_jit_free() by not copying the all instructions on
the rw image to the ro_image
Changes in V4 => v5:
1. Remove the patch for making prog pack allocator portable as it will come
through the RISCV tree[1].
2. Add a new function aarch64_insn_set() to be used in
bpf_arch_text_invalidate() for putting illegal instructions after a
program is removed. The earlier implementation of bpf_arch_text_invalidate()
was calling aarch64_insn_patch_text_nosync() in a loop and making it slow
because each call invalidated the cache.
Here is test_tag now:
[root@ip-172-31-6-176 bpf]# time ./test_tag
test_tag: OK (40945 tests)
real 0m19.695s
user 0m1.514s
sys 0m17.841s
test_tag without these patches:
[root@ip-172-31-6-176 bpf]# time ./test_tag
test_tag: OK (40945 tests)
real 0m21.487s
user 0m1.647s
sys 0m19.106s
test_tag in the previous version was really slow > 2 minutes. see [2]
3. Add cache invalidation in aarch64_insn_copy() so other users can call the
function without worrying about the cache. Currently only bpf_arch_text_copy()
is using it, but there might be more users in the future.
Chanes in V3 => V4: Changes only in 3rd patch
1. Fix the I-cache maintenance: Clean the data cache and invalidate the i-Cache
only *after* the instructions have been copied to the ROX region.
Chanes in V2 => V3: Changes only in 3rd patch
1. Set prog = orig_prog; in the failure path of bpf_jit_binary_pack_finalize()
call.
2. Add comments explaining the usage of the offsets in the exception table.
Changes in v1 => v2:
1. Make the naming consistent in the 3rd patch:
ro_image and image
ro_header and header
ro_image_ptr and image_ptr
2. Use names dst/src in place of addr/opcode in second patch.
3. Add Acked-by: Song Liu <song@kernel.org> in 1st and 2nd patch.
BPF programs currently consume a page each on ARM64. For systems with many BPF
programs, this adds significant pressure to instruction TLB. High iTLB pressure
usually causes slow down for the whole system.
Song Liu introduced the BPF prog pack allocator[3] to mitigate the above issue.
It packs multiple BPF programs into a single huge page. It is currently only
enabled for the x86_64 BPF JIT.
This patch series enables the BPF prog pack allocator for the ARM64 BPF JIT.
====================================================
Performance Analysis of prog pack allocator on ARM64
====================================================
To test the performance of the BPF prog pack allocator on ARM64, a stresser
tool[4] was built. This tool loads 8 BPF programs on the system and triggers
5 of them in an infinite loop by doing system calls.
The runner script starts 20 instances of the above which loads 8*20=160 BPF
programs on the system, 5*20=100 of which are being constantly triggered.
In the above environment we try to build Python-3.8.4 and try to find different
iTLB metrics for the compilation done by gcc-12.2.0.
The source code[5] is configured with the following command:
./configure --enable-optimizations --with-ensurepip=install
Then the runner script is executed with the following command:
./run.sh "perf stat -e ITLB_WALK,L1I_TLB,INST_RETIRED,iTLB-load-misses -a make -j32"
This builds Python while 160 BPF programs are loaded and 100 are being constantly
triggered and measures iTLB related metrics.
The output of the above command is discussed below before and after enabling the
BPF prog pack allocator.
The tests were run on qemu-system-aarch64 with 32 cpus, 4G memory, -machine virt,
-cpu host, and -enable-kvm.
Results
-------
Before enabling prog pack allocator:
------------------------------------
Performance counter stats for 'system wide':
333278635 ITLB_WALK
6762692976558 L1I_TLB
25359571423901 INST_RETIRED
15824054789 iTLB-load-misses
189.029769053 seconds time elapsed
After enabling prog pack allocator:
-----------------------------------
Performance counter stats for 'system wide':
190333544 ITLB_WALK
6712712386528 L1I_TLB
25278233304411 INST_RETIRED
5716757866 iTLB-load-misses
185.392650561 seconds time elapsed
Improvements in metrics
-----------------------
Compilation time ---> 1.92% faster
iTLB-load-misses/Sec (Less is better) ---> 63.16% decrease
ITLB_WALK/1000 INST_RETIRED (Less is better) ---> 42.71% decrease
ITLB_Walk/L1I_TLB (Less is better) ---> 42.47% decrease
[1] https://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git/commit/?h=for-next&id=20e490adea279d49d57b800475938f5b67926d98
[2] https://lore.kernel.org/all/CANk7y0gcP3dF2mESLp5JN1+9iDfgtiWRFGqLkCgZD6wby1kQOw@mail.gmail.com/
[3] https://lore.kernel.org/bpf/20220204185742.271030-1-song@kernel.org/
[4] https://github.com/puranjaymohan/BPF-Allocator-Bench
[5] https://www.python.org/ftp/python/3.8.4/Python-3.8.4.tgz
====================
Link: https://lore.kernel.org/r/20240228141824.119877-1-puranjay12@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Use bpf_jit_binary_pack_alloc for memory management of JIT binaries in
ARM64 BPF JIT. The bpf_jit_binary_pack_alloc creates a pair of RW and RX
buffers. The JIT writes the program into the RW buffer. When the JIT is
done, the program is copied to the final RX buffer
with bpf_jit_binary_pack_finalize.
Implement bpf_arch_text_copy() and bpf_arch_text_invalidate() for ARM64
JIT as these functions are required by bpf_jit_binary_pack allocator.
Signed-off-by: Puranjay Mohan <puranjay12@gmail.com>
Acked-by: Song Liu <song@kernel.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Link: https://lore.kernel.org/r/20240228141824.119877-3-puranjay12@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
The text_poke API is used to implement functions like memcpy() and
memset() for instruction memory (RO+X). The implementation is similar to
the x86 version.
This will be used by the BPF JIT to write and modify BPF programs. There
could be more users of this in the future.
Signed-off-by: Puranjay Mohan <puranjay12@gmail.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Link: https://lore.kernel.org/r/20240228141824.119877-2-puranjay12@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Setting the uniquifier for fscache via the fsc= mount
option is currently broken in NFSv4.
Fix this by passing fscache_uniq to root_fc if possible.
Signed-off-by: Chen Hanxiao <chenhx.fnst@fujitsu.com>
Reviewed-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
While decoding filelayout getdeviceinfo received, print out the
information about the location of data servers (IPs).
Generic getdeviceinfo tracepoints prints the MDS's ip for the
dstaddr. In this patch, separate the MDS's address from the
DS's addresses.
Signed-off-by: Olga Kornievskaia <kolga@netapp.com>
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Switch order of operations to avoid creating a short XDR buffer:
e.g., buflen = 12, old xdrlen = 12, new xdrlen = 20.
Having a short XDR buffer leads to lxa_maxcount be a few bytes
less than what is needed to retrieve the whole list when using
a buflen as returned by a call with size = 0:
buflen = listxattr(path, NULL, 0);
buf = malloc(buflen);
buflen = listxattr(path, buf, buflen);
For a file with one attribute (name = '123456'), the first call
with size = 0 will return buflen = 12 ('user.123456\x00').
The second call with size = 12, sends LISTXATTRS with
lxa_maxcount = 12 + 8 (cookie) + 4 (array count) = 24. The
XDR buffer needs 8 (cookie) + 4 (array count) + 4 (name count)
+ 6 (name len) + 2 (padding) + 4 (eof) = 28 which is 4 bytes
shorter than the lxa_maxcount provided in the call.
Fixes: 04a5da690e ("NFSv4.2: define limits and sizes for user xattr handling")
Signed-off-by: Jorge Mora <mora@netapp.com>
Reviewed-by: Benjamin Coddington <bcodding@redhat.com>
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
A call to listxattr() with a buffer size = 0 returns the actual
size of the buffer needed for a subsequent call. When size > 0,
nfs4_listxattr() does not return an error because either
generic_listxattr() or nfs4_listxattr_nfs4_label() consumes
exactly all the bytes then size is 0 when calling
nfs4_listxattr_nfs4_user() which then triggers the following
kernel BUG:
[ 99.403778] kernel BUG at mm/usercopy.c:102!
[ 99.404063] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
[ 99.408463] CPU: 0 PID: 3310 Comm: python3 Not tainted 6.6.0-61.fc40.aarch64 #1
[ 99.415827] Call trace:
[ 99.415985] usercopy_abort+0x70/0xa0
[ 99.416227] __check_heap_object+0x134/0x158
[ 99.416505] check_heap_object+0x150/0x188
[ 99.416696] __check_object_size.part.0+0x78/0x168
[ 99.416886] __check_object_size+0x28/0x40
[ 99.417078] listxattr+0x8c/0x120
[ 99.417252] path_listxattr+0x78/0xe0
[ 99.417476] __arm64_sys_listxattr+0x28/0x40
[ 99.417723] invoke_syscall+0x78/0x100
[ 99.417929] el0_svc_common.constprop.0+0x48/0xf0
[ 99.418186] do_el0_svc+0x24/0x38
[ 99.418376] el0_svc+0x3c/0x110
[ 99.418554] el0t_64_sync_handler+0x120/0x130
[ 99.418788] el0t_64_sync+0x194/0x198
[ 99.418994] Code: aa0003e3 d000a3e0 91310000 97f49bdb (d4210000)
Issue is reproduced when generic_listxattr() returns 'system.nfs4_acl',
thus calling lisxattr() with size = 16 will trigger the bug.
Add check on nfs4_listxattr() to return ERANGE error when it is
called with size > 0 and the return value is greater than size.
Fixes: 012a211abd ("NFSv4.2: hook in the user extended attribute handlers")
Signed-off-by: Jorge Mora <mora@netapp.com>
Reviewed-by: Benjamin Coddington <bcodding@redhat.com>
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
With this patch, mount command will show fsc=xxx if set:
If -o fsc=6666
clientaddr=192.168.122.208,fsc=6666,local_lock=none
If only -o fsc
clientaddr=192.168.122.208,fsc,local_lock=none
Signed-off-by: Chen Hanxiao <chenhx.fnst@fujitsu.com>
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
In order to get the latency per xprt under the same clientid this patch
adds xprt_id to the tracepoint output.
Signed-off-by: Olga Kornievskaia <kolga@netapp.com>
Tested-by: Chen Hanxiao <chenhx.fnst@fujitsu.com>
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
The intent is to check if the strings' are truncated or not. So, >= should
be used instead of >, because strlcat() and snprintf() return the length of
the output, excluding the trailing NULL.
Fixes: a02d692611 ("SUNRPC: Provide functions for managing universal addresses")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: Benjamin Coddington <bcodding@redhat.com>
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Allocate the common ucall pool using vm_vaddr_alloc_shared() so that the
ucall structures will be placed in shared (unencrypted) memory for VMs
with support for protected (encrypted) memory, e.g. x86's SEV.
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Sean Christopherson <seanjc@google.com>
Cc: Vishal Annapurve <vannapurve@google.com>
Cc: Ackerly Tng <ackerleytng@google.com>
cc: Andrew Jones <andrew.jones@linux.dev>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Michael Roth <michael.roth@amd.com>
Tested-by: Carlos Bilbao <carlos.bilbao@amd.com>
Signed-off-by: Peter Gonda <pgonda@google.com>
[sean: massage changelog]
Link: https://lore.kernel.org/r/20240223004258.3104051-7-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Test programs may wish to allocate shared vaddrs for things like
sharing memory with the guest. Since protected vms will have their
memory encrypted by default an interface is needed to explicitly
request shared pages.
Implement this by splitting the common code out from vm_vaddr_alloc()
and introducing a new vm_vaddr_alloc_shared().
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Sean Christopherson <seanjc@google.com>
Cc: Vishal Annapurve <vannapurve@google.com>
Cc: Ackerly Tng <ackerleytng@google.com>
cc: Andrew Jones <andrew.jones@linux.dev>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Michael Roth <michael.roth@amd.com>
Reviewed-by: Itaru Kitayama <itaru.kitayama@fujitsu.com>
Tested-by: Carlos Bilbao <carlos.bilbao@amd.com>
Signed-off-by: Michael Roth <michael.roth@amd.com>
Signed-off-by: Peter Gonda <pgonda@google.com>
Link: https://lore.kernel.org/r/20240223004258.3104051-6-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Add support for differentiating between protected (a.k.a. private, a.k.a.
encrypted) memory and normal (a.k.a. shared) memory for VMs that support
protected guest memory, e.g. x86's SEV. Provide and manage a common
bitmap for tracking whether a given physical page resides in protected
memory, as support for protected memory isn't x86 specific, i.e. adding a
arch hook would be a net negative now, and in the future.
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Sean Christopherson <seanjc@google.com>
Cc: Vishal Annapurve <vannapurve@google.com>
Cc: Ackerley Tng <ackerleytng@google.com>
cc: Andrew Jones <andrew.jones@linux.dev>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Michael Roth <michael.roth@amd.com>
Reviewed-by: Itaru Kitayama <itaru.kitayama@fujitsu.com>
Tested-by: Carlos Bilbao <carlos.bilbao@amd.com>
Originally-by: Michael Roth <michael.roth@amd.com>
Signed-off-by: Peter Gonda <pgonda@google.com>
Co-developed-by: Sean Christopherson <seanjc@google.com>
Link: https://lore.kernel.org/r/20240223004258.3104051-5-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Add sparsebit_for_each_set_range() to allow iterator over a range of set
bits in a range. This will be used by x86 SEV guests to process protected
physical pages (each such page needs to be encrypted _after_ being "added"
to the VM).
Tested-by: Carlos Bilbao <carlos.bilbao@amd.com>
Signed-off-by: Ackerley Tng <ackerleytng@google.com>
[sean: split to separate patch]
Link: https://lore.kernel.org/r/20240223004258.3104051-4-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Make all sparsebit struct pointers "const" where appropriate. This will
allow adding a bitmap to track protected/encrypted physical memory that
tests can access in a read-only fashion.
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Sean Christopherson <seanjc@google.com>
Cc: Vishal Annapurve <vannapurve@google.com>
Cc: Ackerley Tng <ackerleytng@google.com>
Cc: Andrew Jones <andrew.jones@linux.dev>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Michael Roth <michael.roth@amd.com>
Tested-by: Carlos Bilbao <carlos.bilbao@amd.com>
Signed-off-by: Michael Roth <michael.roth@amd.com>
Signed-off-by: Peter Gonda <pgonda@google.com>
[sean: massage changelog]
Link: https://lore.kernel.org/r/20240223004258.3104051-3-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Carve out space in the @shape passed to the various VM creation helpers to
allow using the shape to control the subtype of VM, e.g. to identify x86's
SEV VMs (which are "regular" VMs as far as KVM is concerned).
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Sean Christopherson <seanjc@google.com>
Cc: Vishal Annapurve <vannapurve@google.com>
Cc: Ackerley Tng <ackerleytng@google.com>
Cc: Andrew Jones <andrew.jones@linux.dev>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Michael Roth <michael.roth@amd.com>
Tested-by: Carlos Bilbao <carlos.bilbao@amd.com>
Link: https://lore.kernel.org/r/20240223004258.3104051-2-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Use the kselftest_harness.h interface in this test to get TAP
output, so that it is easier for the user to see what the test
is doing.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Link: https://lore.kernel.org/r/20240208204844.119326-9-thuth@redhat.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Use the kvm_test_harness.h interface in this test to get TAP
output, so that it is easier for the user to see what the test
is doing.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Link: https://lore.kernel.org/r/20240208204844.119326-8-thuth@redhat.com
[sean: make host_cap static]
Signed-off-by: Sean Christopherson <seanjc@google.com>
Use the kvm_test_harness.h interface in this test to get TAP
output, so that it is easier for the user to see what the test
is doing.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Link: https://lore.kernel.org/r/20240208204844.119326-7-thuth@redhat.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
The sync_regs test currently does not have any output (unless one
of the TEST_ASSERT statement fails), so it's hard to say for a user
whether a certain new sub-test has been included in the binary or
not. Let's make this a little bit more user-friendly and include
some TAP output via the kselftest_harness.h / kvm_test_harness.h
interface.
To be able to use the interface, we have to break up the huge main()
function here in more fine grained parts - then we can use the new
KVM_ONE_VCPU_TEST() macro to define the individual tests. Since these
are run with a separate VM now, we have also to make sure to create
the expected state at the beginning of each test, so some parts grow
a little bit - which should be OK considering that the individual
tests are more self-contained now.
Suggested-by: David Matlack <dmatlack@google.com>
Suggested-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Link: https://lore.kernel.org/r/20240208204844.119326-6-thuth@redhat.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Most tests are currently not giving any proper output for the user
to see how much sub-tests have already been run, or whether new
sub-tests are part of a binary or not. So it would be good to
support TAP output in the KVM selftests. There is already a nice
framework for this in the kselftest_harness.h header which we can
use. But since we also need a vcpu in most KVM selftests, it also
makes sense to introduce our own wrapper around this which takes
care of creating a VM with one vcpu, so we don't have to repeat
this boilerplate in each and every test. Thus let's introduce
a KVM_ONE_VCPU_TEST() macro here which takes care of this.
Suggested-by: Sean Christopherson <seanjc@google.com>
Link: https://lore.kernel.org/all/Y2v+B3xxYKJSM%2FfH@google.com/
Signed-off-by: Thomas Huth <thuth@redhat.com>
Link: https://lore.kernel.org/r/20240208204844.119326-5-thuth@redhat.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Extract the code to set a vCPU's entry point out of vm_arch_vcpu_add() and
into a new API, vcpu_arch_set_entry_point(). Providing a separate API
will allow creating a KVM selftests hardness that can handle tests that
use different entry points for sub-tests, whereas *requiring* the entry
point to be specified at vCPU creation makes it difficult to create a
generic harness, e.g. the boilerplate setup/teardown can't easily create
and destroy the VM and vCPUs.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Link: https://lore.kernel.org/r/20240208204844.119326-4-thuth@redhat.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
If an eDP panel is not powered on then any attempts to talk to it over
the DP AUX channel will timeout. Unfortunately these attempts may be
quite slow. Userspace can initiate these attempts either via a
/dev/drm_dp_auxN device or via the created i2c device.
Making the DP AUX drivers timeout faster is a difficult proposition.
In theory we could just poll the panel's HPD line in the AUX transfer
function and immediately return an error there. However, this is
easier said than done. For one thing, there's no hard requirement to
hook the HPD line up for eDP panels and it's OK to just delay a fixed
amount. For another thing, the HPD line may not be fast to probe. On
parade-ps8640 we need to wait for the bridge chip's firmware to boot
before we can get the HPD line and this is a slow process.
The fact that the transfers are taking so long to timeout is causing
real problems. The open source fwupd daemon sometimes scans DP busses
looking for devices whose firmware need updating. If it happens to
scan while a panel is turned off this scan can take a long time. The
fwupd daemon could try to be smarter and only scan when eDP panels are
turned on, but we can also improve the behavior in the kernel.
Let's let eDP panels drivers specify that a panel is turned off and
then modify the common AUX transfer code not to attempt a transfer in
this case.
Tested-by: Steev Klimaszewski <steev@kali.org>
Reviewed-by: Hsin-Yi Wang <hsinyi@chromium.org>
Tested-by: Eizan Miyamoto <eizan@chromium.org>
Acked-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240202141109.1.I24277520ac754ea538c9b14578edc94e1df11b48@changeid
Revert a recent EC driver change that introduced an unexpected and
undesirable user-visible difference in behavior (Rafael J. Wysocki).
-----BEGIN PGP SIGNATURE-----
iQJGBAABCAAwFiEE4fcc61cGeeHD/fCwgsRv/nhiVHEFAmXfh9MSHHJqd0Byand5
c29ja2kubmV0AAoJEILEb/54YlRxE1sP/RuDelNCmPOVplzhGohKcm0pGhOrp0KU
HrRNxt8ZYn0WeBx8YvURKobTEU2/n3GdpTC/8XJV5y5Q9OCWXqAwpmLCB8qcC5bj
JJmAw2gpXupaa2GSuDj9KA8HkjwXmLz67lXQqeb8em34CQewF+ZFwaVriY9idfpF
cP9on5TL+vU5ZHbAelknAdP/Wmw2hQgeHV5NPsqwMqV03I7oZQaxq5G4q3AOzFa3
eYK7ZIYQkhRRI+b5MxpNQDLHBP1dbr1xE0korh2O4tynav4oXYhNADtMEMZpHdA4
NNT3ffQ2fimjtDm3gIWIVKgv+2beN+rB7lpfiQKADxgN6KCkIz9iwPM5R2636x/d
gr5kWxQjUl8eJn2zOQ83Pc79htqGqIaZRzTIWacB3jhdKW4ZoeVZlyKRvWayMzXG
YICpoTMrdbQmFOWXS8hRx8MZ7P/axyoqazMMEV26OQauJD0AHuM+u9uj5zDR7lKQ
hR33as6/HwfP3CuxwrtGZSkqi56AdtVwFBEXGyO612qEsAgSjF1J2mGlqumlViQ1
8q+yonmVRy7c8aYsITXg9x6KrliBPnMqGb1SohcHtGC1NlvtHypywBC2gFrVbOIf
QuctvhEyLVDHdCY7N800nT0l/kKqorODUc8UCNXKlbIbaQ5kr9QEZz8MNQefR0iU
RpvH8bqK1weS
=vyUq
-----END PGP SIGNATURE-----
Merge tag 'acpi-6.8-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull ACPI fix from Rafael Wysocki:
"Revert a recent EC driver change that introduced an unexpected and
undesirable user-visible difference in behavior (Rafael Wysocki)"
* tag 'acpi-6.8-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
Revert "ACPI: EC: Use a spin lock without disabing interrupts"
Fix a latent bug in the intel-pstate cpufreq driver that has been
exposed by the recent schedutil governor changes (Doug Smythies).
-----BEGIN PGP SIGNATURE-----
iQJGBAABCAAwFiEE4fcc61cGeeHD/fCwgsRv/nhiVHEFAmXfiG4SHHJqd0Byand5
c29ja2kubmV0AAoJEILEb/54YlRx+MAP/jPyZb4g9fIrkZ6++7+PDfB4F/dwM8+a
yNTAkaIJ4H5bMenTkgTvDKETgogFo+tRraPiwk0a0oRZ6rF4HhNHMUOuXkynh9q8
rDxsIq8DtUURrtd8VAEtJ+lof3v9DO8Xpl6tvCksrJWJQXEldiOx1JNcavUnDb3H
tf0MNps9gZMFqSLNFlID4vFsaOYIq5PGpw73A91MBKTuVNB9VD4/camKIJPHr5WL
rZk3fzO2MqaI1WxPD1RL87r8Bj+a/1c5PGMJMCwJkeBqhAw+sfuP9GHoA21P2O+k
9N3gz1dqCWGs/hVp4vldnp3X+B7HcBUTOUoSctr0pxEaqTXqlTZ4IzprDEnzqU64
vR5OjKOGTkUhXvcQYEBNIgr9OsHr6mdjXmBZhHbnC7cSb4Mvn+xur6vV/qSXQtS+
J+xazNcMAoCyomChrWKljzRVkLBJ7bYSPDpGyiFPztdEtSUEhtopW9wgwUZ6/Ou4
JlgVZ6/hbfFTgH1BAqIwttWEoXZmNoTx8r416P1vr71YgZGwYDh+lh4mXUkGiwxb
cpHR3lEIMNfD9lOkhi+KcfDhyfi8fiok1pE6EvbdS6fKhyMbrkPYvONMuLfniMlX
4acobj7Xg5M3TQgvDo4aojEBIsWNOMuaLzth/tja6p//34ll07rqXcwTKD6KVXZ8
rSKyupjUWLuZ
=UaYX
-----END PGP SIGNATURE-----
Merge tag 'pm-6.8-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull power management fix from Rafael Wysocki:
"Fix a latent bug in the intel-pstate cpufreq driver that has been
exposed by the recent schedutil governor changes (Doug Smythies)"
* tag 'pm-6.8-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
cpufreq: intel_pstate: fix pstate limits enforcement for adjust_perf call back
KUnit's assertion macros have variants which accept a printf format
string, to allow tests to specify a more detailed message on failure.
These (and the related KUNIT_FAIL() macro) ultimately wrap the
__kunit_do_failed_assertion() function, which accepted a printf format
specifier, but did not have the __printf attribute, so gcc couldn't warn
on incorrect agruments.
It turns out there were quite a few tests with such incorrect arguments.
Add the __printf() specifier now that we've fixed these errors, to
prevent them from recurring.
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: David Gow <davidgow@google.com>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Justin Stitt <justinstitt@google.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
The drm_buddy_test's alloc_contiguous test used a u64 for the page size,
which was then updated to be an 'unsigned long' to avoid 64-bit
multiplication division helpers.
However, the variable is logged by some KUNIT_ASSERT_EQ_MSG() using the
'%d' or '%llu' format specifiers, the former of which is always wrong,
and the latter is no longer correct now that ps is no longer a u64. Fix
these to all use '%lu'.
Also, drm_mm_test calls KUNIT_FAIL() with an empty string as the
message. gcc and clang warns if a printf format string is empty, so
give these some more detailed error messages, which should be more
useful anyway.
Fixes: a64056bb5a ("drm/tests/drm_buddy: add alloc_contiguous test")
Fixes: fca7526b7d ("drm/tests/drm_buddy: fix build failure on 32-bit targets")
Fixes: fc8d29e298 ("drm: selftest: convert drm_mm selftest to KUnit")
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Acked-by: Christian König <christian.koenig@amd.com>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Justin Stitt <justinstitt@google.com>
Signed-off-by: David Gow <davidgow@google.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Add a transport level callback to allow it to handle the consequences of
dequeuing the request that was in the process of being transmitted.
For something like a TCP connection, we may need to disconnect if the
request was partially transmitted.
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
If the connection has been scheduled to shut down, we must assume that
the socket is not in a state to accept further transmissions until the
connection has been re-established.
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
If the TCP connection attempt fails without ever establishing a
connection, then assume the problem may be the server is rejecting us
due to port reuse.
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Add Lunar Lake-M PCI ID for processor thermal device.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Make use of the common spi-peripheral-props.yaml to pull in the common
spi device properties and limit the spi-max-frequency to 10 MHz as this
is the max. frequency if VDDIO >= 1.62V.
Note all listed devices can either operate in I2C or in SPI mode.
Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20240221174305.3423039-1-m.felsch@pengutronix.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Per i.MX93 Reference Mannual Rev.4, 12/2013, there is no interrupt 268,
so drop it.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20240226130826.3824251-1-peng.fan@oss.nxp.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reference the of_device_id table in the driver structure, so it will be
used for module autoloading and device matching. This fixes clang W=1
warning:
isl29501.c:999:34: error: unused variable 'isl29501_i2c_matches' [-Werror,-Wunused-const-variable]
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20240225201654.49450-2-krzysztof.kozlowski@linaro.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Drop description of non-existing 'struct pm8xxx_chan_info' member:
qcom-pm8xxx-xoadc.c:386: warning: Excess struct member 'scale_fn_type' description in 'pm8xxx_chan_info'
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20240225202744.60500-1-krzysztof.kozlowski@linaro.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add the support to provide an optional label like we do for ADC
channels to identify the device more easily.
Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20240226121234.545662-1-m.felsch@pengutronix.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
