Interesting — I compared your setup against mine, and the patch itself can’t be the difference. I checked the DTS node and the EC driver in the exact jglathe tree you linked (commit
9596aa60):
- The embedded-controller@76 node there is functionally identical to mine (same reg, same GPIO 66 falling-edge interrupt). The extra “qcom,x1e-it8987-ec” compatible is unused — the driver’s of_match only lists “lenovo,yoga-slim7x-ec” — and the pinctrl entry I dropped for size reasons doesn’t matter for this.
- The driver’s suspend hook is the same code: it writes EC register 0x23 ← 0x03 (screen off) then 0x23 ← 0x01 (suspend enter). That write is what makes the EC kill the keyboard backlight and blink the power LED, exactly like Windows does.
So if your LED stays solid and the backlight doesn’t go off, my bet is the driver isn’t probing at all – i.e. the DTB your system actually boots doesn’t contain the EC node, even though it’s in the source tree. Could you check:
ls -l /sys/bus/i2c/devices/\*-0076/driver # should point to lenovo_yoga_slim7x
ls /sys/class/leds/ # should list white:indicator
If *-0076 is missing or unbound, your boot path is loading a DTB without the node. Watch out for how the kernel image boots: if it’s a UKI (systemd-stub), the stub picks its own embedded .dtbauto DTB and silently overrides
anything GRUB loads via devicetree — that’s exactly the trap that cost me my first attempt (details in the gist).
That would also explain your numbers: your 2–3%/h saving would be coming from PSCI deep actually working on 7.1.2-jg-1 (nice — resume from deep is broken on the Ubuntu Concept 7.0.0-32 kernel), not from the EC notification. The two fixes should stack.
If the driver is bound and the LED still doesn’t blink, then something else differs — could you share your BIOS/EC firmware version in that case?