Re: [PATCH v12 0/3] spi: pxa2xx: MacBook8,1 quirk, runtime PM, and LPSS S3 resume state fixes

[Andy Shevchenko]

On Sat, Jul 18, 2026 at 10:52:06PM +0800, Shih-Yuan Lee wrote:
> Hi Mark,
> 
> This 3-patch series resolves issues in the spi-pxa2xx host controller driver
> related to Intel LPSS SPI controllers and the Apple MacBook8,1.
> 
> Patch 1 moves the forced PIO mode quirk for the Apple MacBook8,1 LPSS SPI
> controller from the client driver (applespi) to the host controller PCI glue
> driver (spi-pxa2xx-pci) where it belongs.
> 
> Patch 2 fixes runtime PM and interrupt handling in PIO mode: when DMA is
> disabled, aggressive runtime clock gating causes PCIe Completion Timeouts on
> subsequent MMIO accesses. It scopes autosuspend lockout strictly to LPSS controllers,
> tracks clock state to avoid disable underflows, protects shared IRQ handling,
> preserves the if (!pm_runtime_suspended(dev)) check in suspend/resume to avoid
> PM state desynchronization on non-LPSS SoCs, and uses pm_runtime_put_sync() upon
> driver remove to correctly synchronize the PM state machine to RPM_SUSPENDED.
> 
> Patch 3 fixes S3 suspend/resume for Intel LPSS SPI controllers. The LPSS
> power domain is fully removed across S3, losing all private register state.
> Accessing MMIO on resume while the block is held in reset causes a PCIe Completion
> Timeout and a watchdog system reset. To fix this, we save the LPSS private
> registers in struct driver_data during suspend, de-assert resets first on
> resume, and restore the saved registers.

> Changes in v12:
>   - Addressed feedback from Sashiko review on the v11 patchset for Patch 2:
>   - Preserved the if (!pm_runtime_suspended(dev)) check prior to enabling/disabling
>     the clock in pxa2xx_spi_suspend() and pxa2xx_spi_resume(). On non-LPSS platforms,
>     if a device was runtime suspended prior to system sleep, unconditionally enabling
>     its hardware clock during system resume forced the clock ON while the PM core
>     retained RPM_SUSPENDED. Restoring this check prevents PM state desynchronization,
>     avoiding power leaks on non-LPSS platforms.

What's going on here, please?

It's v12 and you haven't even a thought to add the authors of the drivers, nor
any one from Intel whose SoCs are under the question here.a Besides that the patches
need more work.

-- 
With Best Regards,
Andy Shevchenko