summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-06-16tools headers UAPI: Sync linux/kvm.h with the kernel sourcesArnaldo Carvalho de Melo
To pick the changes in: 5b9db9c16f428ada ("RISC-V: KVM: add KVM_CAP_RISCV_MP_STATE_RESET") a7484c80e5ca1ae0 ("KVM: arm64: Allow userspace to request KVM_ARM_VCPU_EL2*") 79462faa2b2aa89d ("KVM: TDX: Handle TDG.VP.VMCALL<ReportFatalError>") That just rebuilds perf, as these patches don't add any new KVM ioctl to be harvested for the the 'perf trace' ioctl syscall argument beautifiers. This addresses this perf build warning: Warning: Kernel ABI header differences: diff -u tools/include/uapi/linux/kvm.h include/uapi/linux/kvm.h Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Anup Patel <anup@brainfault.org> Cc: Binbin Wu <binbin.wu@linux.intel.com> Cc: Ian Rogers <irogers@google.com> Cc: James Clark <james.clark@linaro.org> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Kan Liang <kan.liang@linux.intel.com> Cc: Marc Zyngier <maz@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Radim Krčmář <rkrcmar@ventanamicro.com> Link: https://lore.kernel.org/r/aEruUUJvR0bfCg7_@x1 Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2025-06-16tools headers UAPI: Sync the drm/drm.h with the kernel sourcesArnaldo Carvalho de Melo
Picking the changes from: c2d3a730069545f2 ("drm/syncobj: Extend EXPORT_SYNC_FILE for timeline syncobjs") Silencing these perf build warnings: Warning: Kernel ABI header differences: diff -u tools/include/uapi/drm/drm.h include/uapi/drm/drm.h No changes in tooling as these are just C comment documentation changes: $ tools/perf/trace/beauty/drm_ioctl.sh > before $ cp include/uapi/drm/drm.h tools/include/uapi/drm/drm.h $ tools/perf/trace/beauty/drm_ioctl.sh > after $ diff -u before after $ Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Christian König <christian.koenig@amd.com> Cc: Ian Rogers <irogers@google.com> Cc: James Clark <james.clark@linaro.org> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Kan Liang <kan.liang@linux.intel.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Rob Clark <robin.clark@oss.qualcomm.com> Link: https://lore.kernel.org/r/aErtHs3T2hdPjjHx@x1 Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2025-06-16perf beauty: Update copy of linux/socket.h with the kernel sourcesArnaldo Carvalho de Melo
To pick the changes in: b1e904999542ad67 ("net: pass const to msg_data_left()") That don't result in any changes in the tables generated from that header. This silences this perf build warning: Warning: Kernel ABI header differences: diff -u tools/perf/trace/beauty/include/linux/socket.h include/linux/socket.h Please see tools/include/uapi/README for details. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Breno Leitao <leitao@debian.org> Cc: Ian Rogers <irogers@google.com> Cc: Jakub Kicinski <kuba@kernel.org> Cc: James Clark <james.clark@linaro.org> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Kan Liang <kan.liang@linux.intel.com> Cc: Namhyung Kim <namhyung@kernel.org> Link: https://lore.kernel.org/r/aErrK24XLUILFH_P@x1 Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2025-06-16tools headers UAPI: Sync kvm header with the kernel sourcesArnaldo Carvalho de Melo
To pick the changes in: c9c1e20b4c7d60fa ("KVM: x86: Introduce Intel specific quirk KVM_X86_QUIRK_IGNORE_GUEST_PAT") 012426d6f59cab21 ("KVM: TDX: Finalize VM initialization") c846b451d3c5d4ba ("KVM: TDX: Add an ioctl to create initial guest memory") 488808e682e72bdb ("KVM: x86: Introduce KVM_TDX_GET_CPUID") a50f673f25e0ba2b ("KVM: TDX: Do TDX specific vcpu initialization") 0186dd29a251866d ("KVM: TDX: add ioctl to initialize VM with TDX specific parameters") 61bb28279623b636 ("KVM: TDX: Get system-wide info about TDX module on initialization") b2aaf38ced6905b8 ("KVM: TDX: Add place holder for TDX VM specific mem_enc_op ioctl") This addresses these perf build warnings: Warning: Kernel ABI header differences: diff -u tools/arch/x86/include/uapi/asm/kvm.h arch/x86/include/uapi/asm/kvm.h Please see tools/include/uapi/README for further details. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Ian Rogers <irogers@google.com> Cc: Isaku Yamahata <isaku.yamahata@intel.com> Cc: James Clark <james.clark@linaro.org> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Kan Liang <kan.liang@linux.intel.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Xiaoyao Li <xiaoyao.li@intel.com> Cc: Yan Zhao <yan.y.zhao@intel.com> Link: https://lore.kernel.org/r/aErqLPktXIzGyS-m@x1 Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2025-06-16tools headers x86 svm: Sync svm headers with the kernel sourcesArnaldo Carvalho de Melo
To pick the changes in: 827547bc3a2a2af6 ("KVM: SVM: Add architectural definitions/assets for Bus Lock Threshold") That triggers: CC /tmp/build/perf-tools/arch/x86/util/kvm-stat.o LD /tmp/build/perf-tools/arch/x86/util/perf-util-in.o LD /tmp/build/perf-tools/arch/x86/perf-util-in.o LD /tmp/build/perf-tools/arch/perf-util-in.o LD /tmp/build/perf-tools/perf-util-in.o AR /tmp/build/perf-tools/libperf-util.a LINK /tmp/build/perf-tools/perf The SVM_EXIT_BUS_LOCK exit reason was added to SVM_EXIT_REASONS, used in kvm-stat.c. This addresses this perf build warning: Warning: Kernel ABI header differences: diff -u tools/arch/x86/include/uapi/asm/svm.h arch/x86/include/uapi/asm/svm.h Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Ian Rogers <irogers@google.com> Cc: James Clark <james.clark@linaro.org> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Kan Liang <kan.liang@linux.intel.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Nikunj A Dadhania <nikunj@amd.com> Cc: Sean Christopherson <seanjc@google.com> Link: https://lore.kernel.org/r/aErcjuTTCVEZ-8Nb@x1 Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2025-06-16tools headers UAPI: Sync KVM's vmx.h header with the kernel sourcesArnaldo Carvalho de Melo
To pick the changes in: 6c441e4d6e729616 ("KVM: TDX: Handle EXIT_REASON_OTHER_SMI") c42856af8f70d983 ("KVM: TDX: Add a place holder for handler of TDX hypercalls (TDG.VP.VMCALL)") That makes 'perf kvm-stat' aware of this new TDCALL exit reason, thus addressing the following perf build warning: Warning: Kernel ABI header differences: diff -u tools/arch/x86/include/uapi/asm/vmx.h arch/x86/include/uapi/asm/vmx.h Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Ian Rogers <irogers@google.com> Cc: Isaku Yamahata <isaku.yamahata@intel.com> Cc: James Clark <james.clark@linaro.org> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Kan Liang <kan.liang@linux.intel.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Paolo Bonzini <pbonzini@redhat.com> Link: https://lore.kernel.org/r/aErcVn_4plQyODR1@x1 Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2025-06-16tools kvm headers arm64: Update KVM header from the kernel sourcesArnaldo Carvalho de Melo
To pick the changes from: b7628c7973765c85 ("KVM: arm64: Allow userspace to limit the number of PMU counters for EL2 VMs") That doesn't result in any changes in tooling (built on a Raspberry PI 5 running Debian GNU/Linux 12 (bookworm)), only addresses this perf build warning: Warning: Kernel ABI header differences: diff -u tools/arch/arm64/include/uapi/asm/kvm.h arch/arm64/include/uapi/asm/kvm.h Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Ian Rogers <irogers@google.com> Cc: James Clark <james.clark@linaro.org> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Kan Liang <kan.liang@linux.intel.com> Cc: Marc Zyngier <maz@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Link: https://lore.kernel.org/r/ Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2025-06-16tools headers UAPI: Sync linux/prctl.h with the kernel sources to pick FUTEX ↵Arnaldo Carvalho de Melo
knob To pick the changes in: 63e8595c060a1fef ("futex: Allow to make the private hash immutable") 80367ad01d93ac78 ("futex: Add basic infrastructure for local task local hash") That adds a FUTEX knob: $ tools/perf/trace/beauty/prctl_option.sh > before $ cp include/uapi/linux/prctl.h tools/perf/trace/beauty/include/uapi/linux/prctl.h $ tools/perf/trace/beauty/prctl_option.sh > after $ diff -u before after --- before 2025-06-09 14:50:45.162579336 -0300 +++ after 2025-06-09 14:50:52.797660024 -0300 @@ -72,6 +72,7 @@ [75] = "SET_SHADOW_STACK_STATUS", [76] = "LOCK_SHADOW_STACK_STATUS", [77] = "TIMER_CREATE_RESTORE_IDS", + [78] = "FUTEX_HASH", }; static const char *prctl_set_mm_options[] = { [1] = "START_CODE", $ That now will be used to decode the syscall option and also to compose filters, for instance: [root@five ~]# perf trace -e syscalls:sys_enter_prctl --filter option==SET_NAME 0.000 Isolated Servi/3474327 syscalls:sys_enter_prctl(option: SET_NAME, arg2: 0x7f23f13b7aee) 0.032 DOM Worker/3474327 syscalls:sys_enter_prctl(option: SET_NAME, arg2: 0x7f23deb25670) 7.920 :3474328/3474328 syscalls:sys_enter_prctl(option: SET_NAME, arg2: 0x7f23e24fbb10) 7.935 StreamT~s #374/3474328 syscalls:sys_enter_prctl(option: SET_NAME, arg2: 0x7f23e24fb970) 8.400 Isolated Servi/3474329 syscalls:sys_enter_prctl(option: SET_NAME, arg2: 0x7f23e24bab10) 8.418 StreamT~s #374/3474329 syscalls:sys_enter_prctl(option: SET_NAME, arg2: 0x7f23e24ba970) ^C[root@five ~]# This addresses this perf build warning: Warning: Kernel ABI header differences: diff -u tools/perf/trace/beauty/include/uapi/linux/prctl.h include/uapi/linux/prctl.h Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Ian Rogers <irogers@google.com> Cc: James Clark <james.clark@linaro.org> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Kan Liang <kan.liang@linux.intel.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: https://lore.kernel.org/r/aEiYOtKkrVDT03hZ@x1 Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2025-06-16perf mem: Document new output fields (op, cache, mem, dtlb, snoop)Namhyung Kim
Update the documentation of the new fields with examples and caveats. Also update the related documentation for AMD IBS. Reviewed-by: Ravi Bangoria <ravi.bangoria@amd.com> Signed-off-by: Namhyung Kim <namhyung@kernel.org> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Ian Rogers <irogers@google.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Kan Liang <kan.liang@linux.intel.com> Cc: Peter Zijlstra <peterz@infradead.org> Link: https://lore.kernel.org/r/20250610005742.2173050-1-namhyung@kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2025-06-16tools headers: Update the fs headers with the kernel sourcesArnaldo Carvalho de Melo
To pick up changes from: 5d894321c49e6137 ("fs: add atomic write unit max opt to statx") a516403787e08119 ("fs/proc: extend the PAGEMAP_SCAN ioctl to report guard regions") c07d3aede2b26830 ("fscrypt: add support for hardware-wrapped keys") These are used to beautify fs syscall arguments, albeit the changes in this update are not affecting those beautifiers. This addresses these tools/ build warnings: Warning: Kernel ABI header differences: diff -u tools/include/uapi/linux/fscrypt.h include/uapi/linux/fscrypt.h diff -u tools/include/uapi/linux/stat.h include/uapi/linux/stat.h diff -u tools/perf/trace/beauty/include/uapi/linux/fs.h include/uapi/linux/fs.h diff -u tools/perf/trace/beauty/include/uapi/linux/stat.h include/uapi/linux/stat.h Please see tools/include/uapi/README for details (it's in the first patch of this series). Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Andrei Vagin <avagin@gmail.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Andrii Nakryiko <andrii@kernel.org> Cc: Darrick J. Wong <djwong@kernel.org> Cc: Eric Biggers <ebiggers@google.com> Cc: Ian Rogers <irogers@google.com> Cc: James Clark <james.clark@linaro.org> Cc: Jiri Olsa <jolsa@kernel.org> Cc: John Garry <john.g.garry@oracle.com> Cc: Kan Liang <kan.liang@linux.intel.com> Cc: Liam R. Howlett <liam.howlett@oracle.com> Cc: Namhyung Kim <namhyung@kernel.org> Link: https://lore.kernel.org/r/aEce1keWdO-vGeqe@x1 Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2025-06-16perf test: Restrict uniquifying test to machines with 'uncore_imc'Chun-Tse Shao
The test would fail if target machine does not have 'uncore_imc' devices. Since event uniquifying behavior is similar among different architectures, we are restricting the test to only run on machines with `uncore_imc` devices. Suggested-by: Ian Rogers <irogers@google.com> Signed-off-by: Chun-Tse Shao <ctshao@google.com> Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Kan Liang <kan.liang@linux.intel.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: https://lore.kernel.org/r/20250521224513.1104129-1-ctshao@google.com [ Skip the test, i.e. return 2, instead of returning 0 as if the test had succeed ] Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2025-06-16Merge tag 'powerpc-6.16-3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux Pull powerpc fixes from Madhavan Srinivasan: - Fix to handle VDSO32 with pcrel - Couple of dts fixes in microwatt and mpc8315erdb - Fix to handle PE bridge reconfiguration in VFIO EEH recovery path - Fix ioctl macros related to struct termio Thanks to Christophe Leroy, Ganesh Goudar, J. Neuschäfer, Justin M. Forbes, Michael Ellerman, Narayana Murty N, Tulio Magno, and Vaibhav Jain * tag 'powerpc-6.16-3' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: powerpc: Fix struct termio related ioctl macros powerpc: dts: mpc8315erdb: Add GPIO controller node powerpc/microwatt: Fix model property in device tree powerpc/eeh: Fix missing PE bridge reconfiguration during VFIO EEH recovery powerpc/vdso: Fix build of VDSO32 with pcrel
2025-06-16Merge tag 'vfs-6.16-rc3.fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs Pull vfs fixes from Christian Brauner: - Fix a regression in overlayfs caused by reworking the lookup_one*() set of helpers - Make sure that the name of the dentry is printed in overlayfs' mkdir() helper - Add missing iocb values to TRACE_IOCB_STRINGS define - Unlock the superblock during iterate_supers_type(). This was an accidental internal api change - Drop a misleading assert in file_seek_cur_needs_f_lock() helper - Never refuse to return PIDFD_GET_INGO when parent pid is zero That can trivially happen in container scenarios where the parent process might be located in an ancestor pid namespace - Don't revalidate in try_lookup_noperm() as that causes regression for filesystems such as cifs - Fix simple_xattr_list() and reset the err variable after security_inode_listsecurity() got called so as not to confuse userspace about the length of the xattr * tag 'vfs-6.16-rc3.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs: fs: drop assert in file_seek_cur_needs_f_lock fs: unlock the superblock during iterate_supers_type ovl: fix debug print in case of mkdir error VFS: change try_lookup_noperm() to skip revalidation fs: add missing values to TRACE_IOCB_STRINGS fs/xattr.c: fix simple_xattr_list() ovl: fix regression caused by lookup helpers API changes pidfs: never refuse ppid == 0 in PIDFD_GET_INFO
2025-06-16hwmon: (ltc4282) avoid repeated register writeNuno Sá
The fault enabled bits were being mistankenly enabled twice in case the FW property is present. Remove one of the writes. Fixes: cbc29538dbf7 ("hwmon: Add driver for LTC4282") Signed-off-by: Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20250611-fix-ltc4282-repetead-write-v1-1-fe46edd08cf1@analog.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-06-16hwmon: (occ) fix unaligned accessesArnd Bergmann
Passing a pointer to an unaligned integer as a function argument is undefined behavior: drivers/hwmon/occ/common.c:492:27: warning: taking address of packed member 'accumulator' of class or structure 'power_sensor_2' may result in an unaligned pointer value [-Waddress-of-packed-member] 492 | val = occ_get_powr_avg(&power->accumulator, | ^~~~~~~~~~~~~~~~~~ drivers/hwmon/occ/common.c:493:13: warning: taking address of packed member 'update_tag' of class or structure 'power_sensor_2' may result in an unaligned pointer value [-Waddress-of-packed-member] 493 | &power->update_tag); | ^~~~~~~~~~~~~~~~~ Move the get_unaligned() calls out of the function and pass these through argument registers instead. Fixes: c10e753d43eb ("hwmon (occ): Add sensor types and versions") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20250610092553.2641094-1-arnd@kernel.org Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-06-16hwmon: (occ) Rework attribute registration for stack usageArnd Bergmann
clang produces an output with excessive stack usage when building the occ_setup_sensor_attrs() function, apparently the result of having a lot of struct literals and building with the -fno-strict-overflow option that leads clang to skip some optimization in case the 'attr' pointer overruns: drivers/hwmon/occ/common.c:775:12: error: stack frame size (1392) exceeds limit (1280) in 'occ_setup_sensor_attrs' [-Werror,-Wframe-larger-than] Replace the custom macros for initializing the attributes with a simpler function call that does not run into this corner case. Link: https://godbolt.org/z/Wf1Yx76a5 Fixes: 54076cb3b5ff ("hwmon (occ): Add sensor attributes and register hwmon device") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20250610092315.2640039-1-arnd@kernel.org Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-06-16hwmon: (ftsteutates) Fix TOCTOU race in fts_read()Gui-Dong Han
In the fts_read() function, when handling hwmon_pwm_auto_channels_temp, the code accesses the shared variable data->fan_source[channel] twice without holding any locks. It is first checked against FTS_FAN_SOURCE_INVALID, and if the check passes, it is read again when used as an argument to the BIT() macro. This creates a Time-of-Check to Time-of-Use (TOCTOU) race condition. Another thread executing fts_update_device() can modify the value of data->fan_source[channel] between the check and its use. If the value is changed to FTS_FAN_SOURCE_INVALID (0xff) during this window, the BIT() macro will be called with a large shift value (BIT(255)). A bit shift by a value greater than or equal to the type width is undefined behavior and can lead to a crash or incorrect values being returned to userspace. Fix this by reading data->fan_source[channel] into a local variable once, eliminating the race condition. Additionally, add a bounds check to ensure the value is less than BITS_PER_LONG before passing it to the BIT() macro, making the code more robust against undefined behavior. This possible bug was found by an experimental static analysis tool developed by our team. Fixes: 1c5759d8ce05 ("hwmon: (ftsteutates) Replace fanX_source with pwmX_auto_channels_temp") Cc: stable@vger.kernel.org Signed-off-by: Gui-Dong Han <hanguidong02@gmail.com> Link: https://lore.kernel.org/r/20250606071640.501262-1-hanguidong02@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-06-16regulator: fan53555: add enable_time support and soft-start timesHeiko Stuebner
The datasheets for all the fan53555 variants (and clones using the same interface) define so called soft start times, from enabling the regulator until at least some percentage of the output (i.e. 92% for the rk860x types) are available. The regulator framework supports this with the enable_time property but currently the fan53555 driver does not define enable_times for any variant. I ran into a problem with this while testing the new driver for the Rockchip NPUs (rocket), which does runtime-pm including disabling and enabling a rk8602 as needed. When reenabling the regulator while running a load, fatal hangs could be observed while enabling the associated power-domain, which the regulator supplies. Experimentally setting the regulator to always-on, made the issue disappear, leading to the missing delay to let power stabilize. And as expected, setting the enable-time to a non-zero value according to the datasheet also resolved the regulator-issue. The datasheets in nearly all cases only specify "typical" values, except for the fan53555 type 08. There both a typical and maximum value are listed - 40uS apart. For all typical values I've added 100uS to be on the safe side. Individual details for the relevant regulators below: - fan53526: The datasheet for all variants lists a typical value of 150uS, so make that 250uS with safety margin. - fan53555: types 08 and 18 (unsupported) are given a typical enable time of 135uS but also a maximum of 175uS so use that value. All the other types only have a typical time in the datasheet of 300uS, so give a bit margin by setting it to 400uS. - rk8600 + rk8602: Datasheet reports a typical value of 260us, so use 360uS to be safe. - syr82x + syr83x: All datasheets report typical soft-start values of 300uS for these regulators, so use 400uS. - tcs452x: Datasheet sadly does not report a soft-start time, so I've not set an enable-time Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patch.msgid.link/20250606190418.478633-1-heiko@sntech.de Signed-off-by: Mark Brown <broonie@kernel.org>
2025-06-16ASoC: SOF: imx8: add core shutdown operation for imx8/imx8xLaurentiu Mihalcea
Currently, the DSP core from i.MX8QM/i.MX8QXP is able to operate while the firmware image is being loaded. Because of this, the DSP may change the content of the firmware data just after it was loaded, thus leading to the data having unexpected values when the DSP is reset (via run()). Fix this by implementing the core_shutdown() operation that will put the DSP in stall during suspend(). The stall will be removed during the run() opertion, thus guaranteeing that the DSP core will not be able to run while the firmware image is being loaded. Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Link: https://patch.msgid.link/20250613194310.1128733-1-laurentiumihalcea111@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-06-16mailmap: add entry for Danilo KrummrichDanilo Krummrich
Add an entry to remap my Red Hat address. Link: https://lore.kernel.org/r/20250614092054.161658-1-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-16fs: drop assert in file_seek_cur_needs_f_lockLuis Henriques
The assert in function file_seek_cur_needs_f_lock() can be triggered very easily because there are many users of vfs_llseek() (such as overlayfs) that do their custom locking around llseek instead of relying on fdget_pos(). Just drop the overzealous assertion. Fixes: da06e3c51794 ("fs: don't needlessly acquire f_lock") Suggested-by: Jan Kara <jack@suse.cz> Suggested-by: Mateusz Guzik <mjguzik@gmail.com> Signed-off-by: Luis Henriques <luis@igalia.com> Link: https://lore.kernel.org/20250613101111.17716-1-luis@igalia.com Signed-off-by: Christian Brauner <brauner@kernel.org>
2025-06-16gpio: spacemit: Add missing MODULE_DEVICE_TABLEVivian Wang
The gpio-spacemit-k1 driver can be compiled as a module. Add missing MODULE_DEVICE_TABLE so it can be matched by modalias and automatically loaded by udev. Fixes: d00553240ef8 ("gpio: spacemit: add support for K1 SoC") Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn> Reviewed-by: Yixun Lan <dlan@gentoo.org> Link: https://lore.kernel.org/r/20250613-k1-gpio-of-table-v1-1-9015da8fdfdb@iscas.ac.cn Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-06-16wifi: rtw89: coex: Add PTA grant signal setting offload to firmware featureChing-Te Ku
In the before experience there are many issue occurred because of the grant control signal can not be set in time especially WiFi power save enter/leave. To control the signal more accuracy, offload the control to firmware. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250611035523.36432-11-pkshih@realtek.com
2025-06-16wifi: rtw89: coex: Update hardware PTA resource binding logicChing-Te Ku
WiFi 7 generation has 2 MAC, the PTA should bind the input/output to correct MAC to do the packet arbitration as expected. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250611035523.36432-10-pkshih@realtek.com
2025-06-16wifi: rtw89: coex: Update BTG control for WiFi 7Ching-Te Ku
BTG means a path work for Bluetooth & Wi-Fi 2.4GHz. To earn a better coexistence performance, need to do some RF setting for BTG path. WiFi 7 generation offload the feature to firmware, to get a more accuracy control. And decrease driver I/O. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250611035523.36432-9-pkshih@realtek.com
2025-06-16wifi: rtw89: coex: Update Pre-AGC logic for WiFi 7Ching-Te Ku
Pre-AGC is Wi-Fi auto Rx gain control. The mechanism need to switching very fast, especially while Wi-Fi is under 2GHz/5GHz multi-port scenario. To earn a more accuracy & sensitive gain control, in the WiFi 7 later firmware, Pre-AGC mechanism has offloaded to firmware. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250611035523.36432-8-pkshih@realtek.com
2025-06-16wifi: rtw89: coex: Add H2C command to collect driver outsource information ↵Ching-Te Ku
to firmware In order to reduce driver I/O & some detail instant hardware control, some of the necessary API offload to Wi-Fi firmware. Collect the reference parameters to let firmware do decisions. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250611035523.36432-7-pkshih@realtek.com
2025-06-16wifi: rtw89: coex: refine debug log with format version and readable stringChing-Te Ku
Fix unexpected line warp. Collect firmware report format version and driver support report format version code to check unexpected C2H report exception. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250611035523.36432-6-pkshih@realtek.com
2025-06-16wifi: rtw89: coex: Update Wi-Fi status logic for WiFi 7Ching-Te Ku
Because WiFi 7 generation has dual MAC, logic need to assign & save the information to correct index. Update the related logic. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250611035523.36432-5-pkshih@realtek.com
2025-06-16wifi: rtw89: coex: Implement Wi-Fi MLO related logicChing-Te Ku
To make the logic can work well with WiFi 7 & before generations, extend & add logic for WiFi 7. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250611035523.36432-4-pkshih@realtek.com
2025-06-16wifi: rtw89: coex: RTL8922A add Wi-Fi firmware support for v0.35.63.0Ching-Te Ku
There were some driver API offloaded to firmware, and to recognize the feature add a version tag for it. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250611035523.36432-3-pkshih@realtek.com
2025-06-16wifi: rtw89: introduce rtw89_query_mr_chanctx_info() for multi-role chanctx infoZong-Zhe Yang
Add Wi-Fi 7 MLO related multi-role (MR) chanctx descriptors and query function. They are designed for other components, e.g. coex, which are interested in the following info. * whether a MLD exists and how many active link * the number of AP mode and station mode respectively * how many chanctx and the number of 2/5/6 GHz respectively Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250611035523.36432-2-pkshih@realtek.com
2025-06-16wifi: rtw89: scan abort when assign/unassign_vifChih-Kang Chang
If scan happen during start_ap, the register which control TX might be turned off during scan. Additionally, if set_channel occurs during scan will backup this register and set to firmware after set_channel done. When scan complete, firmware will also set TX by this register, causing TX to be disabled and beacon can't be TX. Therefore, in assign/unassign_vif call scan abort before set_channel to avoid scan racing with set_channel. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250610130034.14692-13-pkshih@realtek.com
2025-06-16wifi: rtw89: mcc: enlarge TX retry count when GC authChih-Kang Chang
The auth retry only continue 40ms, but the GO might switch to STA role 50ms when MCC. Therefore, enlarge the TX retry count from 32 to 60 to let GC TX time overlapping with GO timeslot. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250610130034.14692-12-pkshih@realtek.com
2025-06-16wifi: rtw89: mcc: use anchor pattern when bcn offset less than min of tobChih-Kang Chang
When the beacon offset is less than minimum of auxiliary tob (aux->duration - aux->limit.max_toa), the upper bound of the reference toa might be negative and lower than the lower bound, which causes the auxiliary result to exceed the NoA limit. Therefore, in this case, the anchor pattern is used for calculation. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250610130034.14692-11-pkshih@realtek.com
2025-06-16wifi: rtw89: mcc: clear normal flow NoA when MCC startChih-Kang Chang
Clear NoA setting before MCC starts. Otherwise, nulldata will be blocked to TX because firmware use the normal flow NoA to calculate timing. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250610130034.14692-10-pkshih@realtek.com
2025-06-16wifi: rtw89: mcc: enlarge scan time of GC when GO in MCCChih-Kang Chang
In original scan, the scan time only 45ms. The GO in MCC mode only stay 50ms and switch to STA role 50ms, which might cause GC can't scan GO. Therefore, enlarge scan time to 105ms to ensure GC have time overlapping with GO. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250610130034.14692-9-pkshih@realtek.com
2025-06-16wifi: rtw89: mcc: adjust TX nulldata early time from 3ms to 7msChih-Kang Chang
Adjust TX nulldata early time to let nulldata have more contention time to TX. Otherwise, AP is hard to receive nulldata 1, which causes the throughput test failed due to packet drops. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250610130034.14692-8-pkshih@realtek.com
2025-06-16wifi: rtw89: TX nulldata 0 after scan completeChih-Kang Chang
HW scan leak to TX nulldata 0 to AP after scan completed, which allowed AP start to TX packet to us. Therefore, driver TX nulldata 0 after scan completed. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250610130034.14692-7-pkshih@realtek.com
2025-06-16wifi: rtw89: mcc: stop TX during MCC prepareChih-Kang Chang
Stop TX during the MCC configuration period to prevent packet leakage. The stop time is defined as 'start_tsf - tsf', which means the duration from when MCC configuration begins until MCC starts. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250610130034.14692-6-pkshih@realtek.com
2025-06-16wifi: rtw89: mcc: adjust beacon filter when MCC and detect connectionChih-Kang Chang
MCC needs to wait at most 300ms to start. Additionally, if scanning happens before MCC starts, it will miss some beacons, which might cause beacon loss. Therefore, we reset beacon filter when MCC start to let hardware reset beacon loss counter. Additionally, GO is forbid to enter courtesy mode might cause STA beacon loss. Therefore, disable beacon filter when GO+STA. However, In WiFi 7 chip, even when GC+STA enable courtesy mode, the beacon might loss because switching to courtesy timeslot will disable TX/RX. If the TOB(time offset behind) or TOA(time offset ahead) is too close to the edge of timeslot, the beacon might not be received. Therefore, disable beacon filter when GC+STA in WiFi 7 chip. Because disabling the beacon filter might prevent disconnection when the AP power-off without sending a deauth. Therefore, driver TX QOS nulldata periodically to detect the AP status, and the connection is terminated if no ACK is received for 6 seconds. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250610130034.14692-5-pkshih@realtek.com
2025-06-16wifi: rtw89: mcc: correct frequency when MCCChih-Kang Chang
The frequency get from PPDU status set as center channel during MCC, but we need to report to mac80211 as primary channel. Therefore, we use the chanctx information in software to instead it. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250610130034.14692-4-pkshih@realtek.com
2025-06-16wifi: rtw89: mcc: update format of RF notify MCC H2C commandChih-Kang Chang
The RF notify MCC H2C command format of 8852C different from other chip, therefore add v0 format to update it. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250610130034.14692-3-pkshih@realtek.com
2025-06-16wifi: rtw89: extend HW scan of WiFi 6 chips for extra OP chan when concurrencyZong-Zhe Yang
HW scan flow has considered the timing when to get back op for the scanning interface. But, when concurrency, there are two interfaces with connection. The OP channel of another one was not back originally. It then easily lead to connection loss when scanning during concurrency. So, HW scan flow is extended to deal with second OP channel. And, H2C command is also extended to fill second MAC ID. The changes mentioned above are done for WiFi 6 chips first. HW scan has different handling architectures including FW and driver on WiFi 7 chips. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250610130034.14692-2-pkshih@realtek.com
2025-06-16drm/i915/dsi: Fix off by one in BXT_MIPI_TRANS_VTOTALVille Syrjälä
BXT_MIPI_TRANS_VTOTAL must be programmed with vtotal-1 instead of vtotal. Make it so. Cc: stable@vger.kernel.org Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250314150136.22564-1-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit 7b3685c9b38c3097f465efec8b24dbed63258cf6) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2025-06-16drm/i915/pmu: Fix build error with GCOV and AutoFDO enabledTzung-Bi Shih
i915_pmu.c may fail to build with GCOV and AutoFDO enabled. ../drivers/gpu/drm/i915/i915_pmu.c:116:3: error: call to '__compiletime_assert_487' declared with 'error' attribute: BUILD_BUG_ON failed: bit > BITS_PER_TYPE(typeof_member(struct i915_pmu, enable)) - 1 116 | BUILD_BUG_ON(bit > | ^ Here is a way to reproduce the issue: $ git checkout v6.15 $ mkdir build $ ./scripts/kconfig/merge_config.sh -O build -n -m <(cat <<EOF CONFIG_DRM=y CONFIG_PCI=y CONFIG_DRM_I915=y CONFIG_PERF_EVENTS=y CONFIG_DEBUG_FS=y CONFIG_GCOV_KERNEL=y CONFIG_GCOV_PROFILE_ALL=y CONFIG_AUTOFDO_CLANG=y EOF ) $ PATH=${PATH}:${HOME}/llvm-20.1.5-x86_64/bin make LLVM=1 O=build \ olddefconfig $ PATH=${PATH}:${HOME}/llvm-20.1.5-x86_64/bin make LLVM=1 O=build \ CLANG_AUTOFDO_PROFILE=...PATH_TO_SOME_AFDO_PROFILE... \ drivers/gpu/drm/i915/i915_pmu.o Although not super sure what happened, by reviewing the code, it should depend on `__builtin_constant_p(bit)` directly instead of assuming `__builtin_constant_p(config)` makes `bit` a builtin constant. Also fix a nit, to reuse the `bit` local variable. Fixes: a644fde77ff7 ("drm/i915/pmu: Change bitmask of enabled events to u32") Reviewed-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20250612083023.562585-1-tzungbi@kernel.org (cherry picked from commit 686d773186bf72b739bab7e12eb8665d914676ee) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2025-06-16wifi: rtlwifi: fix possible skb memory leak in _rtl_pci_init_one_rxdesc()Thomas Fourier
When `dma_mapping_error()` is true, if a new `skb` has been allocated, then it must be de-allocated. Compile tested only Signed-off-by: Thomas Fourier <fourier.thomas@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250613074014.69856-2-fourier.thomas@gmail.com
2025-06-16wifi: rtlwifi: rtl8821ae: make the read-only array params static constColin Ian King
Don't populate the read-only array params on the stack at run time, instead make it static const. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250611135521.172521-1-colin.i.king@gmail.com
2025-06-16wifi: rtlwifi: avoid stack size warning for _read_eeprom_infoArnd Bergmann
txpower_info_{2g,5g} are too big to fit on the stack, but in most of the rtlwifi variants this stays below the warning limit for stack frames. In rtl8192ee and a few others, I see a case where clang decides to fully inline this into rtl92ee_read_eeprom_info, triggering this warning: drivers/net/wireless/realtek/rtlwifi/rtl8192ee/hw.c:2178:6: error: stack frame size (1312) exceeds limit (1280) in 'rtl92ee_read_eeprom_info' [-Werror,-Wframe-larger-than] Mark _rtl92ee_read_txpower_info_from_hwpg() as noinline_for_stack to and mark _rtl92ee_get_chnl_group() as __always_inline to make clang behave the same way as gcc. Inlining _rtl92ee_get_chnl_group helps let the compiler see that the index is always in range. The same change appears to be necessary in all rtlwifi variants. A more thorough approach would be to avoid the use of the two structures on the stack entirely and combine them with the struct rtl_efuse data that is dynamically allocated and holds the same information. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250610092240.2639751-1-arnd@kernel.org
2025-06-15lib/crypto/curve25519-hacl64: Disable KASAN with clang-17 and olderNathan Chancellor
After commit 6f110a5e4f99 ("Disable SLUB_TINY for build testing"), which causes CONFIG_KASAN to be enabled in allmodconfig again, arm64 allmodconfig builds with clang-17 and older show an instance of -Wframe-larger-than (which breaks the build with CONFIG_WERROR=y): lib/crypto/curve25519-hacl64.c:757:6: error: stack frame size (2336) exceeds limit (2048) in 'curve25519_generic' [-Werror,-Wframe-larger-than] 757 | void curve25519_generic(u8 mypublic[CURVE25519_KEY_SIZE], | ^ When KASAN is disabled, the stack usage is roughly quartered: lib/crypto/curve25519-hacl64.c:757:6: error: stack frame size (608) exceeds limit (128) in 'curve25519_generic' [-Werror,-Wframe-larger-than] 757 | void curve25519_generic(u8 mypublic[CURVE25519_KEY_SIZE], | ^ Using '-Rpass-analysis=stack-frame-layout' shows the following variables and many, many 8-byte spills when KASAN is enabled: Offset: [SP-144], Type: Variable, Align: 8, Size: 40 Offset: [SP-464], Type: Variable, Align: 8, Size: 320 Offset: [SP-784], Type: Variable, Align: 8, Size: 320 Offset: [SP-864], Type: Variable, Align: 32, Size: 80 Offset: [SP-896], Type: Variable, Align: 32, Size: 32 Offset: [SP-1016], Type: Variable, Align: 8, Size: 120 When KASAN is disabled, there are still spills but not at many and the variables list is smaller: Offset: [SP-192], Type: Variable, Align: 32, Size: 80 Offset: [SP-224], Type: Variable, Align: 32, Size: 32 Offset: [SP-344], Type: Variable, Align: 8, Size: 120 Disable KASAN for this file when using clang-17 or older to avoid blowing out the stack, clearing up the warning. Signed-off-by: Nathan Chancellor <nathan@kernel.org> Acked-by: "Jason A. Donenfeld" <Jason@zx2c4.com> Acked-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20250609-curve25519-hacl64-disable-kasan-clang-v1-1-08ea0ac5ccff@kernel.org Signed-off-by: Eric Biggers <ebiggers@google.com>
generated by cgit (git 2.34.1) at 2025-09-17 00:43:21 +0000