Re: [PATCH RFC 0/2] platform/x86: Add Emdoor Intel EWMI platform driver

[Ziqiang Xia <xiazq123666@gmail.com>]

Hi Armin,

Thank you for taking a look at this!

On Fri, Nov 13, 2026 at 09:37:44PM +0100, Armin Wolf wrote:
> Interesting.
> 
> IMHO using direct EC addresses will eventually turn into a
> maintainability nightmare. I am aware of the issue with CreateField(),
> AFAIK you can workaround this issue by simply submitting an oversized
> buffer to wmidev_invoke_method().
> 
> Can you share the output of acpidump please?
> 
> Thanks,
> Armin Wolf

1. CreateField() bug in legacy WMAA-WMCB methods
------------------------------------------------
On this DSDT (all 13 legacy methods WMAA through WMCB under \_SB.EWMI),
the out-of-bounds CreateField() is not applied to the input buffer
(Arg2). Instead, the AML allocates a hardcoded 8-byte local return
buffer (Local0) and defines fields past bit 63 on Local0 itself, e.g.
in WMAA:

    Local0 = Buffer (0x08){}
    CreateWordField (Local0, Zero, RTNC)
    CreateWordField (Local0, 0x02, ALID)
    CreateField (Local0, 0x20, 0x3F, RES3)

Because bit offset 0x20 (32) + length 0x3f (63) = 95 bits exceeds the
64-bit Local0 buffer allocated inside the method, passing a larger
input buffer to wmidev_invoke_method() does not enlarge Local0 and
ACPICA still aborts with AE_AML_BUFFER_LIMIT before entering the switch.
Fortunately WMCD, WMCC, and _WED(0xD0) do not have this bug.

2. Eliminating direct EC addresses (ec_read()) in v2
----------------------------------------------------
I agree completely regarding maintainability. RFC v1 has zero ec_write()
calls and uses ec_read() in three places:

- Temperatures (temp_regs {0x70, 0x73, 0x72, 0x62}, i.e. TSR1..TSR4):
  Checking SSDT5 (\_SB.IETM) and /sys/class/thermal on this machine,
  TSR2 (0x73), TSR3 (0x72), and TSR4 (0x62) are already exposed via
  standard ACPI DPTF thermal zones (SEN2, SEN3, and SEN4 under
  int3403_thermal), and CPU temperature (TSR1 / 0x70) is already covered
  by coretemp / x86_pkg_temp / DPTF TCPU. Meanwhile both fan tachometers
  (fan1_input, fan2_input) come purely from WMCD GFNS (0x02/0x01) with
  no direct EC access. I will drop temp_regs completely in v2 so hwmon
  is 100% pure WMI for the two fans.

- auto_power_on (0xf5 / H_EC.ATPU):
  WMCC (C75665A3-4382-4646-ADC8-C81AE146E455) only implements the setter
  (Arg1 == 1, Arg2 == 0/1 writing 0x00/0xA0 to ATPU) and has no WMI
  getter.

- win_lock / fn_lock (0x5d / H_EC.EC5D):
  WMCD GWLS (0x03/0x01) and GFLS (0x03/0x03) write ZZTT=0xD0 and
  TIZZ=0xD3/0xD2, wait only Sleep(0x14) (20 ms), and read EC5D before the
  EC finishes populating the shared mailbox. Calling the same WMI method
  twice under a mutex with 25-100 ms delays (550 reads per step) reduced
  win_lock -EIO errors from 26/550 to 1/550, but fn_lock still returned
  occasional stale values because the second WMI call immediately
  rewrites ZZTT/TIZZ before the settled EC5D byte is read (and _QF6/_QF9
  hotkeys also overwrite EC5D).

Note that platform_profile (GPFM/SPFM), dual-fan hwmon (GFNS),
touchpad_enabled (GTPS/STPS), and the 0xD0 WMI hotkeys all work 100%
via pure WMI without any ec_read() or per-BIOS register offsets.

For v2, would you prefer dropping all direct ec_read() calls completely
so the driver is strictly pure WMI (dropping temp_regs, auto_power_on,
and fn_lock/win_lock unless a reliable pure-WMI path works), or keeping
DMI-gated EC5D readback only for fn_lock/win_lock?

3. acpidump output
------------------
The sanitized ACPI tables (DSDT and SSDT1..SSDT28, Windows licensing
table omitted) and decoded ewmi.mof are uploaded here:

  https://gist.github.com/winddd666/8f739d1cab5beb503f606093ade10d65

Direct raw URLs:
  acpidump.txt:
    https://gist.githubusercontent.com/winddd666/8f739d1cab5beb503f606093ade10d65/raw/15e1f0d4c98096674f9a958e431096b1b49d1a40/acpidump.txt
  ewmi.mof:
    https://gist.githubusercontent.com/winddd666/8f739d1cab5beb503f606093ade10d65/raw/8eff35b93fee7ed6e2d8aab47fd1ad4137bb13cd/ewmi.mof

Individual tables can be extracted with "acpixtract -a acpidump.txt".

Best regards,
Ziqiang Xia