[PATCH v16 6/7] spi: pxa2xx: restore LPSS private register state on S3 resume

[Andy Shevchenko]

On Sun, Jul 26, 2026 at 07:48:27PM +0800, Shih-Yuan Lee (FourDollars) wrote:

...

> > Is this series AI-assisted?

> Yes, I used an LLM assistant to help format and polish the commit messages.
> However, all hardware register analysis (such as inspecting BAR0 +
> 0x204 LPSS Private Resets), DSDT ACPI overrides, schematic
> verifications for logic board 820-00244-A, and physical S3
> suspend/resume hardware testing on MacBook8,1 were performed
> empirically on real hardware.

Check the kernel documentation if you need or may use Assisted-by tag.

...

> > This is an ugly hack.
> >
> > Saving context is done in drivers/acpi/x86/lpss.c (see #1 why this file).
> > If something wrong in the flow it has to be fixed there, not here.
> I checked drivers/acpi/x86/lpss.c and its LPSS_SAVE_CTX mechanism.
> However, on MacBook8,1, the LPSS SPI controller is instantiated as a
> PCI device (00:15.4 / 8086:9ce6) bound to spi-pxa2xx-pci.c, rather
> than an ACPI platform device handled by drivers/acpi/x86/lpss.c. As a
> result, acpi_lpss_restore_ctx() is never invoked for this PCI device.
> 
> Physical hardware S3 testing (rtcwake -m mem) confirms that across S3
> suspend, LPSS_PRIV_RESETS (BAR0 + 0x204) is reset to 0x00000000
> (functional block held in reset) by the PCH, causing all post-resume
> SPI transfers to fail  continuously with -110 timeouts (applespi
> spi-APP000D:00: SPI transfer timed out).
> 
> I understand your point about not doing context saving in spi-pxa2xx.c.
> Would moving the LPSS private register context save/restore into
> spi-pxa2xx-pci.c (the PCI glue driver) be an acceptable approach for
> PCI-enumerated devices?

I see. Can we do something similar to what drivers/pci/pci-mid.c does?
And somehow to unify the core part of the context saving, et cetera
between two ACPI and PCI cases?

-- 
With Best Regards,
Andy Shevchenko