LpcACPIEC: Move interfacing into PawnIO module

[namazso]

Most of this file should be ported to the PawnIO module as these are the atomic commands supported by the EC. There is no reason to read or write the whitelisted port other than to implement one of these well specified atomic commands.

[kulvind3r]

Wrote an EC Reader using this module just today. Thought you might like it.

https://github.com/kulvind3r/ECReader

Leaving a comment for tracking updates on this issue, if the module is removed in future I can update the reader.

[redhot075]

Adding a concrete LpcACPIEC case that may be relevant to this work: intermittent OBF timeouts on an Acer Aspire V3-571G. I am not assuming that moving the transaction into the module alone would fix it.

Environment

• Acer Aspire V3-571G, i7-3740QM, Windows 11 Pro x64 (build 26200).
• Official PawnIO 2.2.0; signed LpcACPIEC.bin from PawnIO.Modules release 0.2.11.
• Small C#/.NET 8 x64 client using PawnIOLib. HRESULTs and output counts are checked.
• Global\Access_EC is held for the complete command. Each port operation is a separate pawnio_execute.
• No EC-command retries and no OBF bypass. Each handshake has a 100 ms timeout; the first 32 unsuccessful polls do not sleep, later polls sleep for 1 ms.

Observed register-read sequence
A status command reads B4, BD, AB in order. Some complete commands succeeded, but this attempt failed on the second register:

offset_ms duration_ms operation port value
10.363    0.102       W         0066 80
10.569    0.014       R         0066 08
10.586    0.011       W         0062 B4
10.598    0.006       R         0066 02
10.612    0.007       R         0066 02
10.619    0.006       R         0066 01
10.627    0.006       R         0062 00
10.640    0.007       R         0066 00
10.647    0.006       W         0066 80
10.655    0.007       R         0066 0A
10.662    0.011       R         0066 0A
10.673    0.027       R         0066 08
10.701    0.011       W         0062 BD
10.714    0.008       R         0066 02
10.723    0.011       R         0066 02
10.734    0.012       R         0066 00
... status remained 00 until the 101 ms timeout

No data-port read or further I/O followed the timeout; AB and subsequent status attempts were skipped. The trace is buffered and formatted after I/O, though instrumentation still has overhead. Timeouts also occurred without tracing.

Static firmware inspection
The Windows-cached DSDT declares EC ports 0x62/0x66 and GPE 0x17. No _GLK declaration was found in the inspected cached tables, while EmbeddedControl fields use Lock. The DSDT also contains FANG/FANW methods using an AML FAMX mutex and an indirect index/data interface at 0x5D–0x5F. Those methods have not been invoked, and their accepted addresses/semantics have not been established. In particular, FANG itself writes the index register. This does not establish that ACPI contention caused the timeout.

Is there a supported way, using the official signed modules, to perform a complete EC register read while coordinating correctly with the Windows ACPI EC driver? What ownership guarantees are intended for the proposed in-module operations versus the application-level Access_EC mutex? Happy to provide the full 58-entry trace if useful.