LpcACPIEC: add atomic read and range IOCTLs - #88
Conversation
|
I changed this to draft, please test it on the unrestricted driver (you'll have to use 2.1.0 or your own builds because 2.2.0 accidentally shipped with signature verification enabled on the unrestricted driver as well) before marking it as ready. Also get rid of the "test" that checks substrings on the source code, wtf... |
|
Thanks for the clarification. Understood:\n\n- We will keep the PR as Draft.\n- We will test the module with the unrestricted 2.1.0 driver or a locally built equivalent, and will not use 2.2.0 because of the signature-verification regression.\n- The source-substring test has been removed in commit 38d1017.\n\nWe have not marked the PR ready. We will report the actual runtime result here after testing with the unrestricted driver. |
|
Runtime testing is complete. I kept the PR as Draft and did not mark it ready. Test setup:
Single-run results (21 cases total):
Overall result: FAIL (client exit code 7). The module loads and byte reads work on this machine, but the full range-read contract does not pass because the valid range cases at the end of the EC address space timed out. I will leave the PR in Draft. The exact stdout/stderr and hashes are available if you need them. |
|
I found and fixed a separate deterministic issue in the range-output path. The previous
Commit Verification:
|
|
Runtime retest completed with the patched module from commit Setup:
Results:
The byte timeout set changed with the read order compared with the previous run, so I am treating these as an unresolved EC/protocol or machine-state issue rather than attributing them to the output-padding change. The temporary test service was stopped and deleted after the run. The PR remains Draft. |
Summary
RD_ECsequence intoLpcACPIECioctl_ec_read_byteand one-requestioctl_ec_read_rangeThe caller must continue to hold
\\BaseNamedObjects\\Access_ECfor the complete request.Scope
This is intentionally the read-only first stage of #7. It does not add a high-level write IOCTL and does not use the optional EC hardware Burst Mode (
0x82/0x83). A range is still a sequence of standardRD_ECcommands, but it executes inside one PawnIO request.The module and caller-side contract have been compiled and statically validated. Runtime testing of the new module is still pending because the available production PawnIO installation rejects locally built unsigned modules.
Validation
tests/lpc_acpi_ec_batch_contract.ps10xFF, and exact packed output sizing