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 v5:
- Move the definition of struct cd_fan_block outside of
lwmi_cd_fan_list_alloc_cache() and rename it lwmi_cd_fan_block (thanks
Ilpo Järvinen)
- Link to v4: https://patch.msgid.link/20261018-lwmi-wmi-new-api-v4-0-aafef7956c4a@rong.moe
Changes in v4:
- Fix typo (thanks Mark Pearson)
- Pass the error from guid_parse() to matchptr
- Link to v3: https://patch.msgid.link/20261014-lwmi-wmi-new-api-v3-0-e1032bed1c81@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 | 458 ++++++++++++++++++++++--------
drivers/platform/x86/lenovo/wmi-helpers.c | 61 ++--
drivers/platform/x86/lenovo/wmi-other.c | 24 +-
include/linux/wmi.h | 3 +
6 files changed, 404 insertions(+), 176 deletions(-)
---
base-commit: c03c1a14507dfaf8b856c2608f9ac216021fc222
change-id: a504a929-lwmi-wmi-new-api-f5344d48a86a
Thanks,
Rong