| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <bd88ef1f-2695-4cc2-fa78-f3e62d436edb@linux.intel.com>
Date: Fri, 9 Jan 2026 11:50:54 +0200 (EET)
From: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
To: "Derek J. Clark" <derekjohn.clark@...il.com>, Armin Wolf <W_Armin@....de>
cc: Rong Zhang <i@...g.moe>, Mark Pearson <mpearson-lenovo@...ebb.ca>,
Hans de Goede <hansg@...nel.org>, Guenter Roeck <linux@...ck-us.net>,
platform-driver-x86@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
linux-hwmon@...r.kernel.org
Subject: Re: [PATCH v7 0/7] platform/x86: lenovo-wmi-{capdata,other}: Add
HWMON for fan speed
On Fri, 9 Jan 2026, Derek J. Clark wrote:
> On November 25, 2025 11:49:21 AM PST, Rong Zhang <i@...g.moe> wrote:
> >Lenovo WMI Other Mode interface also supports querying or setting fan
> >speed RPM. This capability is described by LENOVO_CAPABILITY_DATA_00.
> >Besides, LENOVO_FAN_TEST_DATA provides reference data for self-test of
> >cooling fans, including minimum and maximum fan speed RPM.
> >
> >This patchset turns lenovo-wmi-capdata01 into a unified driver (now
> >named lenovo-wmi-capdata) for LENOVO_CAPABILITY_DATA_{00,01} and
> >LENOVO_FAN_TEST_DATA; then adds HWMON support for lenovo-wmi-other:
> >
> > - fanX_enable: enable/disable the fan (tunable)
> > - fanX_input: current RPM
> > - fanX_max: maximum RPM
> > - fanX_min: minimum RPM
> > - fanX_target: target RPM (tunable)
> >
> >LENOVO_CAPABILITY_DATA_{00,01} presents on all devices, so
> >both binds to lenovo-wmi-other. However, some device does not have
> >LENOVO_FAN_TEST_DATA and its presence is described by
> >LENOVO_CAPABILITY_DATA_00; hence, the former binds to the latter and a
> >callback is used to pass the data to lenovo-wmi-other.
> >
> >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.
> >
> >The implementation does not rely on a specific binding sequence. This
> >has been fuzz-tested using:
> >
> > #!/bin/bash
> >
> > DRV_DIR=/sys/bus/wmi/drivers/lenovo_wmi_cd
> > CAPDATA_GUIDS=(
> > $(find "$DRV_DIR"/ -name '*-*-*-*-*-*' -printf "%f ")
> > )
> >
> > b() { sudo tee "$DRV_DIR"/bind <<<"$1"; }
> > u() { sudo tee "$DRV_DIR"/unbind <<<"$1"; }
> >
> > for guid in "${CAPDATA_GUIDS[@]}"; do
> > u "$guid"
> > done
> >
> > while read -rsa perm; do
> > for guid in "${perm[@]}"; do
> > b "$guid"
> > done
> > sensors | grep -A3 lenovo_wmi_other || true
> > for guid in "${perm[@]}"; do
> > u "$guid"
> > done
> > done < <(python3 -c "
> > from itertools import permutations
> > ps = permutations('${CAPDATA_GUIDS[*]}'.split())
> > for p in ps: print(' '.join(p))")
> >
> > for guid in "${CAPDATA_GUIDS[@]}"; do
> > b "$guid"
> > done
> >
> >Tested on ThinkBook 14 G7+ ASP.
> >
> >Changes in v7:
> >- Fix missing #include (thanks Ilpo Järvinen)
> >- Fix formatting issues (ditto)
> >- dev_dbg() instead of dev_info() on probe success (ditto)
> >- Rearrange to drop some gotos (ditto)
> >- Move the declarations of __free()-managed variables to where they are
> > assigned (ditto)
> >- Improve the readability of struct definition and error paths (ditto)
> >- Prevent back-and-forth changes (ditto)
> >- Fix mistakenly inverted boundary check
> >- Emit unaligned access to Fan Test Data's WMI block
> >- Properly calculate array index when we truncate Fan Test Data
> >- Fix typo
> >- Link to v6: https://lore.kernel.org/r/20251122184522.18677-1-i@rong.moe/
> >
> >Changes in v6:
> >- Fix mistaken error paths
> >- Link to v5: https://lore.kernel.org/r/20251114175927.52533-1-i@rong.moe/
> >
> >Changes in v5:
> >- Do not cast pointer to non-pointer or vice versa (thanks kernel test
> > robot)
> >- Fix missing include (ditto)
> >- Link to v4: https://lore.kernel.org/r/20251113191152.96076-1-i@rong.moe/
> >
> >Changes in v4:
> >- Get rid of wmi_has_guid() (thanks Armin Wolf's inspiration)
> > - Add [PATCH v4 6/7], please review & test
> > - Check 0x04050000.supported and bind capdata_fan to capdata00
> > - Rework HWMON registration
> > - Collect fan info from capdata00 and capdata_fan separately
> > - Use a callback to collect fan info from capdata_fan
> > - Trigger HWMON registration only if all fan info is collected
> > - Do not check 0x04050000.supported, implied by the presence of
> > capdata_fan
> >- Drop Reviewed-by & Tested-by from [PATCH v4 7/7] due to the changes,
> > please review & test
> >- Link to v3: https://lore.kernel.org/r/20251031155349.24693-1-i@rong.moe/
> >
> >Changes in v3:
> >- Fix grammar (thanks Derek J. Clark)
> >- Link to v2: https://lore.kernel.org/r/20251030193955.107148-1-i@rong.moe/
> >
> >Changes in v2:
> >- Add a workaround for ACPI methods that return a 4B buffer for u32
> > (thanks Armin Wolf)
> >- Fix function documentation (thanks kernel test bot)
> >- Reword documentation (thanks Derek J. Clark)
> >- Squash min/max reporting patch into the initial HWMON one (ditto)
> >- Query 0x04050000 for interface availability (ditto)
> > - New parameter "expose_all_fans" to skip this check
> >- Enforce min/max RPM constraint on set (ditto)
> > - New parameter "relax_fan_constraint" to disable this behavior
> > - Drop parameter "ignore_fan_cap", superseded by the next one
> > - New parameter "expose_all_fans" to expose fans w/o such data
> >- Assume auto mode on probe (ditto)
> >- Do not register HWMON device if no fan can be exposed
> >- fanX_target: Return -EBUSY instead of raw target value when fan stops
> >- Link to v1: https://lore.kernel.org/r/20251019210450.88830-1-i@rong.moe/
> >
> >Rong Zhang (7):
> > platform/x86: lenovo-wmi-helpers: Convert returned buffer into u32
> > platform/x86: Rename lenovo-wmi-capdata01 to lenovo-wmi-capdata
> > platform/x86: lenovo-wmi-{capdata,other}: Support multiple Capability
> > Data
> > platform/x86: lenovo-wmi-capdata: Add support for Capability Data 00
> > platform/x86: lenovo-wmi-capdata: Add support for Fan Test Data
> > platform/x86: lenovo-wmi-capdata: Wire up Fan Test Data
> > platform/x86: lenovo-wmi-other: Add HWMON for fan reporting/tuning
> >
> > .../wmi/devices/lenovo-wmi-other.rst | 43 +-
> > drivers/platform/x86/lenovo/Kconfig | 5 +-
> > drivers/platform/x86/lenovo/Makefile | 2 +-
> > drivers/platform/x86/lenovo/wmi-capdata.c | 812 ++++++++++++++++++
> > drivers/platform/x86/lenovo/wmi-capdata.h | 65 ++
> > drivers/platform/x86/lenovo/wmi-capdata01.c | 302 -------
> > drivers/platform/x86/lenovo/wmi-capdata01.h | 25 -
> > drivers/platform/x86/lenovo/wmi-helpers.c | 21 +-
> > drivers/platform/x86/lenovo/wmi-other.c | 515 ++++++++++-
> > 9 files changed, 1433 insertions(+), 357 deletions(-)
> > create mode 100644 drivers/platform/x86/lenovo/wmi-capdata.c
> > create mode 100644 drivers/platform/x86/lenovo/wmi-capdata.h
> > delete mode 100644 drivers/platform/x86/lenovo/wmi-capdata01.c
> > delete mode 100644 drivers/platform/x86/lenovo/wmi-capdata01.h
> >
> >
> >base-commit: ac3fd01e4c1efce8f2c054cdeb2ddd2fc0fb150d
>
> Ilpo,
>
> Is there any particular reason this appears to be stalled? I'd like to
> start work on some features that rely on the capdata00 interface but I'm
> waiting on this to be applied as there has been frequent back and forth
> on exactly how to add the different components.
Hi,
I was thinking Armin might still take a look at it but perhaps his latest
message was effectively saying "the current approach is fine"?
(And it has been holiday period too.)
--
i.
Powered by blists - more mailing lists