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

On 9/8/2026 7:28 PM, Birk Skyum wrote:
> 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?

The read-only match-data path looks fine, but it should be integrated
with the existing LUT match data. We should not replace the current
match-data usage.

> - Should the pending Lenovo binding omit the qcom,hamoa-crd-ec fallback,
>   given that this firmware cannot satisfy the reference driver's probe?

If this firmware cannot pass the reference-board thermal-capability
probe, I think the Lenovo binding should not use qcom,hamoa-crd-ec as a
fallback. The fallback should be used only if the device is functionally
compatible with the reference-board driver, not only because it uses the
same EC chip.

In that case, the binding changes in Daniel’s patch also need to be updated.

-- 
Best Regards,
Anvesh

Hi Anvesh,

Thanks for the review and for raising the firmware comparison with Daniel.

Agreed on preserving the LUT match data. My v2 is based on
28924df2a08f440c73991b83028032c901de2ae4, which does not contain that
implementation, and I could not find it in the current mainline driver
either. Could you point me to the latest series or branch you would like
me to target? I can integrate the read-only variant with that match data
without changing the existing LUT behavior.

On your thermistor comment on patch 1, would a DT thermal sensor and a
monitoring-only thermal zone, without cooling maps, be the interface you
have in mind? I can keep fan RPM under hwmon and leave cooling under
firmware control.

I also agree that sharing the EC chip is not sufficient to justify the
qcom,hamoa-crd-ec fallback. I would like to compare firmware behavior
before treating the capability-query failure as a model-wide limitation,
then coordinate any binding adjustment with Daniel's series.

For that comparison, my existing September 8 test recorded:

  Yoga Slim 7x 14Q8X9 / 83ED
  BIOS NHCN62WW, EC 0.99.0
  Firmware query 0x0e: 03 00 63 00
  Capability query 0x42: 00 00 00, identical across three reads

The capability transfer completed with three bytes, but its count byte
was zero rather than two. The unmodified driver rejected it with EINVAL.
The separate read-only sensor test successfully read RPM and temperature
while firmware controlled the fans.

These are the earlier results, not a fresh test or evidence that a BIOS
update would or would not resolve it. Daniel, I am happy to compare your
versions and capability response, or repeat targeted read-only checks if
there is a useful difference to investigate.

Thanks,
Birk