[RFC PATCH v2 0/2] Monitor Yoga Slim 7x EC sensors without taking over cooling

[Birk Skyum <birk.skyum@pm.me>]

The Yoga Slim 7x firmware tested here (EC 0.99.0, BIOS NHCN62WW) returns
00 00 00 to command 0x42. The upstream driver correctly rejects that
malformed thermal capability response. Its legacy fan RPM query (0x22,
fan ID 1) and thermistor query (0x29) work, and the firmware ramps the fan
automatically under CPU load.

This series adds a Lenovo-specific, read-only path to the existing driver
and KUnit tests using a simulated I2C adapter. It does not replace the
strict reference-board response validation, guess a writable fan count,
or include calibration, LUT programming or temperature reporting.

Changes in v2:
- Move the platform-driver documentation from Documentation/hwmon/ to
  Documentation/admin-guide/laptops/, following Guenter's review [3].
- Update the documentation index and MAINTAINERS path accordingly.

Driver and test code are unchanged from v1 [4]. The hardware and KUnit
results below are from that version; no new hardware test is claimed.

This builds on Daniel J Blueman's pending binding and board patches [1].
They remain separate prerequisites, with Daniel's authorship unchanged.
The sensor transactions are documented in the public Yoga DSDT and Maya
Matuszczyk's protocol notes; Anvesh Jain P's pending fan-profile series
also implements the RPM query [2].

Testing on the Yoga with the EC node enabled and its existing 7.2 kernel:
- W=1 external-module build.
- Three bind/read/unload cycles; read-only fan1_input and temp1_input.
- Bounded CPU load: fan rose from 0 to approximately 2800 RPM, with a
  maximum SoC reading of 55.4 C. Original profile 0x15 was unchanged.
- Previous monitor restored after testing; boot files unchanged.

On the stated mainline base, an arm64 KUnit kernel booted in QEMU passes
all seven tests. These cover sensor decoding, error handling, compatible
selection, probe, read-only attributes and no-write PM/remove callbacks.
The QEMU results validate code paths, not Yoga suspend behavior.

Two design questions for this RFC:
- Is this read-only match-data path the preferred way to accommodate
  the Lenovo firmware alongside the reference-board work?
- Should the pending Lenovo binding omit the qcom,hamoa-crd-ec fallback,
  given that this firmware cannot satisfy the reference driver's probe?

EC standby notifications and desktop power-profile integration are not
implemented or claimed by this series. Those need separate validation.

[1] https://lore.kernel.org/all/20260526112409.66325-1-daniel@quora.org/
[2] https://lkml.iu.edu/hypermail/linux/kernel/2607.3/08806.html
[3] https://lists.openwall.net/linux-kernel/2026/09/08/290
[4] https://lists.openwall.net/linux-kernel/2026/09/08/96

Birk Skyum (2):
  platform: arm64: qcom-hamoa-ec: monitor Slim 7x legacy sensors
  platform: arm64: qcom-hamoa-ec: test sensor and variant handling

 Documentation/admin-guide/laptops/index.rst   |   1 +
 Documentation/admin-guide/laptops/qcom-ec.rst |  40 +++
 MAINTAINERS                                   |   2 +
 drivers/platform/arm64/Kconfig                |  16 +-
 drivers/platform/arm64/qcom-hamoa-ec-test.c   | 294 ++++++++++++++++++
 drivers/platform/arm64/qcom-hamoa-ec.c        | 157 +++++++++-
 6 files changed, 505 insertions(+), 5 deletions(-)
 create mode 100644 Documentation/admin-guide/laptops/qcom-ec.rst
 create mode 100644 drivers/platform/arm64/qcom-hamoa-ec-test.c


base-commit: 28924df2a08f440c73991b83028032c901de2ae4
-- 
2.53.0