platform-x86: lenovo-wmi: Add fixes and enhancement#8
Merged
KyleGospo merged 13 commits intoogc-6.19.yfrom Feb 14, 2026
Merged
Conversation
…ffer into u32 The Windows WMI-ACPI driver converts all ACPI objects into a common buffer format, so returning a buffer with four bytes will look like an integer for WMI consumers under Windows. Therefore, some devices may simply implement the corresponding ACPI methods to always return a buffer. While lwmi_dev_evaluate_int() expects an integer (u32), convert returned >=4B buffer into u32 to support these devices. Suggested-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/f1787927-b655-4321-b9d9-bc12353c72db@gmx.de/ Signed-off-by: Rong Zhang <i@rong.moe> Reviewed-by: Derek J. Clark <derekjohn.clark@gmail.com> Tested-by: Derek J. Clark <derekjohn.clark@gmail.com> Reviewed-by: Armin Wolf <W_Armin@gmx.de> Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca> Signed-off-by: Derek J. Clark <derekjohn.clark@gmail.com>
…mi-capdata Prepare for the upcoming changes to make it suitable to retrieve and provide other Capability Data as well. Signed-off-by: Rong Zhang <i@rong.moe> Reviewed-by: Derek J. Clark <derekjohn.clark@gmail.com> Tested-by: Derek J. Clark <derekjohn.clark@gmail.com> Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca> Signed-off-by: Derek J. Clark <derekjohn.clark@gmail.com>
…tiple Capability Data The current implementation are heavily bound to capdata01. Rewrite it so that it is suitable to utilize other Capability Data as well. No functional change intended. Signed-off-by: Rong Zhang <i@rong.moe> Reviewed-by: Derek J. Clark <derekjohn.clark@gmail.com> Tested-by: Derek J. Clark <derekjohn.clark@gmail.com> Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca> Signed-off-by: Derek J. Clark <derekjohn.clark@gmail.com>
…ability Data 00 Add support for LENOVO_CAPABILITY_DATA_00 WMI data block that comes on "Other Mode" enabled hardware. Provides an interface for querying if a given attribute is supported by the hardware, as well as its default value. capdata00 always presents on devices with capdata01. lenovo-wmi-other now binds to both (no functional change intended). Signed-off-by: Rong Zhang <i@rong.moe> Reviewed-by: Derek J. Clark <derekjohn.clark@gmail.com> Tested-by: Derek J. Clark <derekjohn.clark@gmail.com> Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca> Signed-off-by: Derek J. Clark <derekjohn.clark@gmail.com>
… Test Data Add support for LENOVO_FAN_TEST_DATA WMI data block. Provides an interface for querying the min/max fan speed RPM (reference data) of a given fan ID. This interface is optional. Hence, it does not bind to lenovo-wmi-other and is not registered as a component for the moment. Appropriate binding will be implemented in the subsequent patch. Signed-off-by: Rong Zhang <i@rong.moe> Reviewed-by: Derek J. Clark <derekjohn.clark@gmail.com> Tested-by: Derek J. Clark <derekjohn.clark@gmail.com> Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca> Signed-off-by: Derek J. Clark <derekjohn.clark@gmail.com>
A capdata00 attribute (0x04050000) describes the presence of Fan Test Data. Query it, and bind Fan Test Data as a component of capdata00 accordingly. The component master of capdata00 may pass a callback while binding to retrieve fan info from Fan Test Data. Summarizing this scheme: lenovo-wmi-other <-> capdata00 <-> capdata_fan |- master |- component | |- sub-master |- sub-component The callback will be called once both the master and the sub-component are bound to the sub-master (component). This scheme is essential to solve these issues: - The component framework only supports one aggregation per master - A binding is only established until all components are found - The Fan Test Data interface may be missing on some devices - To get rid of queries for the presence of WMI GUIDs - The notifier framework cannot cleanly connect capdata_fan to lenovo-wmi-other without introducing assumptions on probing sequence capdata00 is registered as a component and a sub-master on probe, instead of chaining the registrations in one's bind callback. This is because calling (un)registration methods of the component framework causes deadlock in (un)bind callbacks, i.e., it's impossible to register capdata00 as a sub-master/component in its component/sub-master bind callback, and vice versa. Signed-off-by: Rong Zhang <i@rong.moe> Reviewed-by: Derek J. Clark <derekjohn.clark@gmail.com> Tested-by: Derek J. Clark <derekjohn.clark@gmail.com> Signed-off-by: Derek J. Clark <derekjohn.clark@gmail.com>
…orting/tuning Register an HWMON device for fan reporting/tuning according to Capability Data 00 (capdata00) and Fan Test Data (capdata_fan) provided by lenovo-wmi-capdata. The corresponding HWMON nodes are: - fanX_div: internal RPM divisor - fanX_input: current RPM - fanX_max: maximum RPM - fanX_min: minimum RPM - fanX_target: target RPM (tunable, 0=auto) Information from capdata00 and capdata_fan are used to control the visibility and constraints of HWMON attributes. Fan info from capdata00 is collected on bind, while fan info from capdata_fan is collected in a callback. Once all fan info is collected, register the HWMON device. Signed-off-by: Rong Zhang <i@rong.moe> Reviewed-by: Derek J. Clark <derekjohn.clark@gmail.com> Tested-by: Kurt Borja <kuurtb@gmail.com> Signed-off-by: Derek J. Clark <derekjohn.clark@gmail.com>
…hannel visibility
The LWMI_SUPP_MAY_{GET,SET} macros are fundamentally broken. When I
introduced them, I meant to check LWMI_SUPP_VALID *and* the
corresponding bits for get/set capabilities. However, `supported &
LWMI_SUPP_MAY_{GET,SET}' means *or*, so it accidentally passes the check
when LWMI_SUPP_VALID is set.
Fix them by only including the corresponding get/set bit without
LWMI_SUPP_VALID. Meanwhile, rename them to LWMI_SUPP_{GET,SET} to make
them less confusing.
Fixes: 67d9a39ce85f ("platform/x86: lenovo-wmi-capdata: Wire up Fan Test Data")
Signed-off-by: Rong Zhang <i@rong.moe>
Signed-off-by: Derek J. Clark <derekjohn.clark@gmail.com>
Adds LWMI_ATTR_ID macro. In the same vein as LWMI_ATTR_ID_FAN_RPM, but as a generic, to de-duplicate attribute_id assignment biolerplate. Signed-off-by: Derek J. Clark <derekjohn.clark@gmail.com>
…supported devices Adds lwmi_is_attr_01_supported, and only creates the attribute subfolder if the attribute is supported by the hardware. Due to some poorly implemented BIOS, this is a multi-step sequence of events. This is because: - Some BIOS support getting the capability data from custom mode (0xff), while others only support it in no-mode (0x00). - Similarly, some BIOS support get/set for the current value from custom mode (0xff), while others only support it in no-mode (0x00). - Some BIOS report capability data for a method that is not fully implemented. - Some BIOS have methods fully implemented, but no complimentary capability data. To ensure we only expose fully implemented methods with corresponding capability data, we check each outcome before reporting that an attribute can be supported. Checking for lwmi_is_attr_01_supported during remove is not done to ensure that we don't attempt to call cd01 or send WMI events if one of the interfaces being removed was the cause of the driver unloading. While adding members to tunable_attr_01, remove unused capdata pointer and limit size of all ID's to the appropriate size. Reported-by: Kurt Borja <kuurtb@gmail.com> Closes: https://lore.kernel.org/platform-driver-x86/DG60P3SHXR8H.3NSEHMZ6J7XRC@gmail.com/ Signed-off-by: Derek J. Clark <derekjohn.clark@gmail.com>
…ributes Use an enum for all device Id's and CPU attribute feature ID's, add missing CPU attributes. Signed-off-by: Derek J. Clark <derekjohn.clark@gmail.com>
Use an enum for all GPU attribute feature ID's and add GPU attributes. Signed-off-by: Derek J. Clark <derekjohn.clark@gmail.com>
…ting. Add charge-type power supply extension for devices that support WMI based charge enable/disable. Lenovo Legion devices that implement function ID and capdata 00 ID 0x03010001 are able to enable or disable charging through the lenovo-wmi-other interface. The ideapad_laptop driver conflicts with this if it can also provide the attribute, so we have to get the acpi_handle and check for the same ACPI methods that enable the feature in that driver. The ACPI method is more reliable from my testing when both are present, so there is no need to modify the ideapad_laptop driver instead. The power supply extension requires a name. Instead of adding a third const macro with the same information, replace LWMI_OM_FW_ATTR_BASE_PATH and LWMI_OM_HWMON_NAME with LWMI_OM_NAME and use that everywhere. Signed-off-by: Derek J. Clark <derekjohn.clark@gmail.com>
KyleGospo
approved these changes
Feb 13, 2026
pull bot
pushed a commit
that referenced
this pull request
Feb 27, 2026
The ETM decoder incorrectly assumed that auxtrace queue indices were
equivalent to CPU number. This assumption is used for inserting records
into the queue, and for fetching queues when given a CPU number. This
assumption held when Perf always opened a dummy event on every CPU, even
if the user provided a subset of CPUs on the commandline, resulting in
the indices aligning.
For example:
# event : name = cs_etm//u, , id = { 2451, 2452 }, type = 11 (cs_etm), size = 136, config = 0x4010, { sample_period, samp>
# event : name = dummy:u, , id = { 2453, 2454, 2455, 2456 }, type = 1 (PERF_TYPE_SOFTWARE), size = 136, config = 0x9 (PER>
0 0 0x200 [0xd0]: PERF_RECORD_ID_INDEX nr: 6
... id: 2451 idx: 2 cpu: 2 tid: -1
... id: 2452 idx: 3 cpu: 3 tid: -1
... id: 2453 idx: 0 cpu: 0 tid: -1
... id: 2454 idx: 1 cpu: 1 tid: -1
... id: 2455 idx: 2 cpu: 2 tid: -1
... id: 2456 idx: 3 cpu: 3 tid: -1
Since commit 811082e ("perf parse-events: Support user CPUs mixed
with threads/processes") the dummy event no longer behaves in this way,
making the ETM event indices start from 0 on the first CPU recorded
regardless of its ID:
# event : name = cs_etm//u, , id = { 771, 772 }, type = 11 (cs_etm), size = 144, config = 0x4010, { sample_period, sample>
# event : name = dummy:u, , id = { 773, 774 }, type = 1 (PERF_TYPE_SOFTWARE), size = 144, config = 0x9 (PERF_COUNT_SW_DUM>
0 0 0x200 [0x90]: PERF_RECORD_ID_INDEX nr: 4
... id: 771 idx: 0 cpu: 2 tid: -1
... id: 772 idx: 1 cpu: 3 tid: -1
... id: 773 idx: 0 cpu: 2 tid: -1
... id: 774 idx: 1 cpu: 3 tid: -1
This causes the following segfault when decoding:
$ perf record -e cs_etm//u -C 2,3 -- true
$ perf report
perf: Segmentation fault
-------- backtrace --------
#0 0xaaaabf9fd020 in ui__signal_backtrace setup.c:110
#1 0xffffab5c7930 in __kernel_rt_sigreturn [vdso][930]
#2 0xaaaabfb68d30 in cs_etm_decoder__reset cs-etm-decoder.c:85
#3 0xaaaabfb65930 in cs_etm__get_data_block cs-etm.c:2032
#4 0xaaaabfb666fc in cs_etm__run_per_cpu_timeless_decoder cs-etm.c:2551
#5 0xaaaabfb6692c in (cs_etm__process_timeless_queues cs-etm.c:2612
#6 0xaaaabfb63390 in cs_etm__flush_events cs-etm.c:921
#7 0xaaaabfb324c0 in auxtrace__flush_events auxtrace.c:2915
#8 0xaaaabfaac378 in __perf_session__process_events session.c:2285
#9 0xaaaabfaacc9c in perf_session__process_events session.c:2442
#10 0xaaaabf8d3d90 in __cmd_report builtin-report.c:1085
#11 0xaaaabf8d6944 in cmd_report builtin-report.c:1866
#12 0xaaaabf95ebfc in run_builtin perf.c:351
#13 0xaaaabf95eeb0 in handle_internal_command perf.c:404
#14 0xaaaabf95f068 in run_argv perf.c:451
#15 0xaaaabf95f390 in main perf.c:558
#16 0xffffaab97400 in __libc_start_call_main libc_start_call_main.h:74
#17 0xffffaab974d8 in __libc_start_main@@GLIBC_2.34 libc-start.c:128
#18 0xaaaabf8aa8f0 in _start perf[7a8f0]
Fix it by inserting into the queues based on CPU number, rather than
using the index.
Fixes: 811082e ("perf parse-events: Support user CPUs mixed with threads/processes")
Signed-off-by: James Clark <james.clark@linaro.org>
Tested-by: Leo Yan <leo.yan@arm.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: coresight@lists.linaro.org
Cc: Ian Rogers <irogers@google.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: John Garry <john.g.garry@oracle.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Mike Leach <mike.leach@linaro.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Suzuki Poulouse <suzuki.poulose@arm.com>
Cc: Thomas Falcon <thomas.falcon@intel.com>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
pull bot
pushed a commit
that referenced
this pull request
Feb 27, 2026
When run on a kernel without BTF info, perf crashes:
libbpf: kernel BTF is missing at '/sys/kernel/btf/vmlinux', was CONFIG_DEBUG_INFO_BTF enabled?
libbpf: failed to find valid kernel BTF
Program received signal SIGSEGV, Segmentation fault.
0x00005555556915b7 in btf.type_cnt ()
(gdb) bt
#0 0x00005555556915b7 in btf.type_cnt ()
#1 0x0000555555691fbc in btf_find_by_name_kind ()
#2 0x00005555556920d0 in btf.find_by_name_kind ()
#3 0x00005555558a1b7c in init_numa_data (con=0x7fffffffd0a0) at util/bpf_lock_contention.c:125
#4 0x00005555558a264b in lock_contention_prepare (con=0x7fffffffd0a0) at util/bpf_lock_contention.c:313
#5 0x0000555555620702 in __cmd_contention (argc=0, argv=0x7fffffffea10) at builtin-lock.c:2084
#6 0x0000555555622c8d in cmd_lock (argc=0, argv=0x7fffffffea10) at builtin-lock.c:2755
#7 0x0000555555651451 in run_builtin (p=0x555556104f00 <commands+576>, argc=3, argv=0x7fffffffea10)
at perf.c:349
#8 0x00005555556516ed in handle_internal_command (argc=3, argv=0x7fffffffea10) at perf.c:401
#9 0x000055555565184e in run_argv (argcp=0x7fffffffe7fc, argv=0x7fffffffe7f0) at perf.c:445
#10 0x0000555555651b9f in main (argc=3, argv=0x7fffffffea10) at perf.c:553
Check if btf loading failed, and don't do anything with it in
init_numa_data(). This leads to the following error message, instead of
just a crash:
libbpf: kernel BTF is missing at '/sys/kernel/btf/vmlinux', was CONFIG_DEBUG_INFO_BTF enabled?
libbpf: failed to find valid kernel BTF
libbpf: kernel BTF is missing at '/sys/kernel/btf/vmlinux', was CONFIG_DEBUG_INFO_BTF enabled?
libbpf: failed to find valid kernel BTF
libbpf: Error loading vmlinux BTF: -ESRCH
libbpf: failed to load BPF skeleton 'lock_contention_bpf': -ESRCH
Failed to load lock-contention BPF skeleton
lock contention BPF setup failed
Signed-off-by: Tycho Andersen (AMD) <tycho@kernel.org>
Acked-by: Namhyung Kim <namhyung@kernel.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Chun-Tse Shao <ctshao@google.com>
Cc: Ian Rogers <irogers@google.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: James Clark <james.clark@linaro.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: K Prateek Nayak <kprateek.nayak@amd.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ravi Bangoria <ravi.bangoria@amd.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR adds 2 patch series. The first was accepted into pd-x86/for-next already and can be dropped in kernel 7.0. The second has not yet been accepted and requires review.
The purpose of these patches is to add features to the lenovo-wmi-* drivers. The first series adds fan tunables for some older Lenovo laptops as well as enabling the grabbing of capability data from the capdata00 structure, which is needed for the second series. The second series fixes some bugs and adds multiple new tunables for CPU and GPU on Lenovo laptops, as well as enabling battery charge limiting on the Legion Go 1.
Series 1 Links:
https://lore.kernel.org/platform-driver-x86/20260120182104.163424-1-i@rong.moe/
https://lore.kernel.org/platform-driver-x86/20260207172327.80111-1-i@rong.moe/
Series 2 Link:
https://lore.kernel.org/platform-driver-x86/20260213081243.794288-1-derekjohn.clark@gmail.com/
Signed-off-by: Derek J. Clark derekjohn.clark@gmail.com