Re: [PATCH v2 00/12] platform/x86: lenovo-wmi-{other,capdata,helpers}: Improve robustness on faulty firmware

["Derek J. Clark" <derekjohn.clark@gmail.com>]

On October 9, 2026 5:53:42 AM PDT, Rong Zhang <i@rong.moe> 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.

Hi Rong,

I'll try to fully test all my devices this weekend to add a T/b tag. In the mantime, everything looks good, save for that minor nit you already acked. 

With that resolved, for the series:
Reviewed-by: Derek J. Clark <derekjohn.clark@gmail.com>

Thanks,
- 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 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 | 450 ++++++++++++++++++++++--------
> drivers/platform/x86/lenovo/wmi-helpers.c |  61 ++--
> drivers/platform/x86/lenovo/wmi-other.c   |  24 +-
> include/linux/wmi.h                       |   3 +
> 6 files changed, 400 insertions(+), 172 deletions(-)
>---
>base-commit: af32da41b0327b9c6a37856ba82b6760d6c8d10e
>change-id: a504a929-lwmi-wmi-new-api-f5344d48a86a
>
>Thanks,
>Rong
>