platform/chrome: Fix MEC concurrency problems for Framework Laptop
Status from this message: This series was applied to chrome-platform/linux.git (for-kernelci)
Get series with b4
b4 am [email protected]Versions newest first · linked by author and title
- v3 Latest5 patches 2 repliesApplied 5/5
- v25 patches 10 repliesSuperseded
- v16 patches 12 repliesSuperseded
Changes in v3 from the cover letter
* Use ACPI_COMPANION instead of adev variable.
* Stricter error checking in probe.
* Remove a few blank lines.
* Rebase to latest ChromeOS for-next branch.
Patches in v3 All 5 applied
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/5 | platform/chrome: cros_ec_lpc: MEC access can return error codedrivers/ drivers/ drivers/ +1 more | +112 | 0 replies | Applied |
| 2/5 | platform/chrome: cros_ec_lpc: MEC access can use an AML mutexdrivers/ drivers/ | +85 | 2 replies | Applied |
| 3/5 | platform/chrome: cros_ec_lpc: Add a new quirk for ACPI iddrivers/ | +38 | 0 replies | Applied |
| 4/5 | platform/chrome: cros_ec_lpc: Add a new quirk for AML mutexdrivers/ | +19 | 0 replies | Applied |
| 5/5 | platform/chrome: cros_ec_lpc: Add quirks for Framework Laptopdrivers/ | +7 | 0 replies | Applied |
Reviews trailers per patch
None of the 5 patches has a Reviewed-by or Acked-by.
| Patch | Dustin L. Howett |
|---|---|
| Series | T-b |
| 1/5 | |
| 2/5 | |
| 3/5 | |
| 4/5 | |
| 5/5 |
Trailers given in replies are filled; those carried in the patches from earlier versions are outlined with dashes.
Cover letter [PATCH v3 0/5] platform/chrome: Fix MEC concurrency problems for Framework Laptop
Framework Laptops with the Microchip EC have a problem where the EC "stops working" after a while. Symptoms include the Fn key not working, and "bad packet checksum" errors appearing in the system log.
The problem is caused by ACPI code which accesses the Microchip EC (MEC) memory using the Microchip EMI protocol. It uses an AML mutex to prevent concurrent access. But the cros_ec_lpc driver is not aware of this mutex. The ACPI code and LPC driver both attempt to talk to the EC at the same time, messing up communication with the EC.
The solution is to have the cros_ec_lpc_mec code find and use the AML mutex. But to make it all work we have to do a few more things:
* Allow the cros_ec_lpc_mec code to return error codes in case it can't lock the mutex.
* Have the cros_ec_lpc code find the correct ACPI device (PNP0C09) and then the AML mutex itself.
* Use the quirks mechanism to specify the AML mutex name.
Tested-on: link, hx20, azalea
Changes in v3:
* Use ACPI_COMPANION instead of adev variable.
* Stricter error checking in probe.
* Remove a few blank lines.
* Rebase to latest ChromeOS for-next branch.
Changes in v2:
* Put ACPI id in a quirk, not the acpi_match_table.
* Add return code check for mutex unlock.
* Remove "in_range" check which belongs in a separate patch.
* Use "ret" not "sum" variable (same value but clearer).
* Remove excessive error logging.
* Rebase to latest ChromeOS for-next branch.
Ben Walsh (5):
platform/chrome: cros_ec_lpc: MEC access can return error code platform/chrome: cros_ec_lpc: MEC access can use an AML mutex platform/chrome: cros_ec_lpc: Add a new quirk for ACPI id platform/chrome: cros_ec_lpc: Add a new quirk for AML mutex platform/chrome: cros_ec_lpc: Add quirks for Framework Laptop
drivers/platform/chrome/cros_ec_lpc.c | 206 +++++++++++++++------ drivers/platform/chrome/cros_ec_lpc_mec.c | 85 ++++++++- drivers/platform/chrome/cros_ec_lpc_mec.h | 18 +- drivers/platform/chrome/wilco_ec/mailbox.c | 22 ++- 4 files changed, 261 insertions(+), 70 deletions(-)
base-commit: 106d6739823369c734a8fc3b13634274eee4f60e
Signature · 1 line
2.45.1