On Tue, Oct 13, 2026, at 3:21 PM, Rong Zhang wrote:
> Some devices do not support LENOVO_CAPABILITY_DATA_01 and define the
> query method as a stub that returns zero buffer. Unfortunately, some
> devices do not implement the stub properly, causing WMI errors
> (including ACPI errors). This was reported by Charles.
>
> The current lenovo-wmi-* implementation enforces the binding between
> LENOVO_CAPABILITY_DATA_00+01 and LENOVO_OTHER_MODE because of a
> limitation of the device component framework. When the capdata device
> bailing out due to a WMI error, lenovo-wmi-other becomes unbound and
> unable to provide firmware-attributes or hwmon/power_supply_ext devices
> for the other functional capdata device.
>
> Therefore, errors must be non-fatal in order not to break the
> assumptions made by the device component framework.
>
> Poison the capdata device by releasing the capability data list in this
> case. After that, NULL list will be passed to lenovo-wmi-other on bind.
> The latter will provide whatever is available, or unbind the components
> if nothing is available.
>
> A poisoned capdata device releases or skips allocating most resources,
> e.g., the capability data list and the debugfs directory. The device
> itself is only used to satisfy the component dependency of lenovo-wmi-
> other and coordinate with the latter about the absence of the capability
> data.
>
> Meanwhile, for devices that properly stubs the WMI query method (but
> still declares >0 instances), keeping the capability data list with
> empty data is meaningless and causes lenovo-wmi-other to call
> lwmi_cd*_get_data() to retrieve nonexistent capdata in vain. These
> capdata devices are poisoned as well to save resources.
>
> In order to release or skip allocating most resources for poisoned
> devices, some preparatory work is done in prior. With the preparatory
> work, it also skips allocating most resources for the WMI devices that
> declare 0 instance.
>
> Also identify missing components using the new wmidev_exists() interface
> (introduced at the very beginning of the series), and skip adding them
> to the match list, so that all components in the list must present,
> fulfilling the binding requirement. Some devices need this because they
> either do not have the WMI GUID of LENOVO_CAPABILITY_DATA_01, or do not
> implement the query method, causing the WMI core not to create the
> corresponding WMI device. This was reported by Navon.
>
> The new WMI API is also adopted to conform to the behavior of the
> Windows WMI-ACPI driver and improve robustness on various WMI ACPI
> method implementation.
>
> Finally, add myself as a LENOVO drivers maintainer as previously
> suggested by Derek.
>
> Reported-by: Charles <hanker007@gmail.com>
> Closes:
> https://msgid.link/CAKtz0s8UYRQYW_0bh=0TMx47Axm-W-muEay-r3rqUBS1NHMPVw@mail.gmail.com/
> Reported-by: Navon John Lukose <navonjohnlukose@gmail.com>
> Closes:
> https://msgid.link/20260928190901.1369497-1-navonjohnlukose@gmail.com
> Suggested-by: Mark Pearson <mpearson-lenovo@squebb.ca>
> Link:
> https://msgid.link/9789f452-d7eb-4f1e-8a13-7335332193a7@app.fastmail.com
> Suggested-by: Derek J. Clark <derekjohn.clark@gmail.com>
> Link: https://msgid.link/782FE636-A06A-4E12-9563-786374805947@gmail.com
> Signed-off-by: Rong Zhang <i@rong.moe>
> ---
> Changes in v3:
> - Shorten the comments of struct lwmi_cd_priv's members (thanks Derek
> J. Clark)
> - Leave struct cd_fan_block's __packed attribute as is (thanks Armin
> Wolf)
> - Link to v2:
> https://patch.msgid.link/20261009-lwmi-wmi-new-api-v2-0-402828382679@rong.moe
>
> Changes in v2:
> - Add PATCH 1 ("platform/wmi: Introduce wmidev_exists()") to the series
> as discussed at
> https://msgid.link/83776200-4A60-4756-A99F-D5A3BB4D834A@rong.moe
> - Add PATCH 2 ("lenovo-wmi-capdata: Do not stop the AC notifier chain on
> error") to the series, as adopting the new WMI API will intentionally
> catch more faulty firmware and propagate more errors
> - Synchronize mutex initialization with release-acquire barriers (thanks
> Ilpo Järvinen)
> - Refine line wrap (ditto)
> - Replace the term "poison" with "stub" (ditto)
> - Add PATCH 10 ("platform/x86: lenovo-wmi-capdata: Do not match missing
> components") to the series to solve the report made by Navon
> - Update outdated comments, function documentations and commit messages
> - Link to v1:
> https://patch.msgid.link/20260914-lwmi-wmi-new-api-v1-0-7a400f2f69f8@rong.moe
>
> ---
> Armin Wolf (1):
> platform/wmi: Introduce wmidev_exists()
>
> Rong Zhang (11):
> platform/x86: lenovo-wmi-capdata: Do not stop the AC notifier
> chain on error
> platform/x86: lenovo-wmi-capdata: Only allocate sub-master info
> when necessary
> platform/x86: lenovo-wmi-capdata: Store a pointer to component
> info
> platform/x86: lenovo-wmi-capdata: Defer mutex initialization
> platform/x86: lenovo-wmi-{capdata,other}: Only allocate capdata
> list when necessary
> platform/x86: lenovo-wmi-capdata: Adopt new WMI API
> platform/x86: lenovo-wmi-capdata: Register component even on WMI
> error
> platform/x86: lenovo-wmi-capdata: Detect stubbed capdata device
> platform/x86: lenovo-wmi-capdata: Do not match missing components
> platform/x86: lenovo-wmi-helpers: Adopt new WMI API
> MAINTAINERS: Add myself as a LENOVO drivers co-maintainer
>
> MAINTAINERS | 1 +
> drivers/platform/wmi/core.c | 33 ++-
> drivers/platform/x86/lenovo/wmi-capdata.c | 447 ++++++++++++++++++++++--------
> drivers/platform/x86/lenovo/wmi-helpers.c | 61 ++--
> drivers/platform/x86/lenovo/wmi-other.c | 24 +-
> include/linux/wmi.h | 3 +
> 6 files changed, 397 insertions(+), 172 deletions(-)
> ---
> base-commit: af32da41b0327b9c6a37856ba82b6760d6c8d10e
> change-id: a504a929-lwmi-wmi-new-api-f5344d48a86a
>
> Thanks,
> Rong
For the series (with the minor typo noted in #7) - looks good to me.
Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Mark