* [PATCH v16 1/7] spi: pxa2xx: introduce clock enable and disable helper functions
2026-07-20 16:21 [PATCH v16 0/7] spi: pxa2xx: Fix PM and interrupt issues on Intel LPSS SPI Shih-Yuan Lee
@ 2026-07-20 16:21 ` Shih-Yuan Lee
2026-07-20 19:22 ` Andy Shevchenko
2026-07-20 16:21 ` [PATCH v16 2/7] spi: pxa2xx: introduce suspended flag for interrupt synchronization Shih-Yuan Lee
` (5 subsequent siblings)
6 siblings, 1 reply; 25+ messages in thread
From: Shih-Yuan Lee @ 2026-07-20 16:21 UTC (permalink / raw)
To: Mark Brown
Cc: Andy Shevchenko, Mika Westerberg, Lukas Wunner, Daniel Mack,
Haojian Zhuang, Robert Jarzmik, linux-arm-kernel, linux-spi,
linux-kernel, Shih-Yuan Lee
The driver disables the clock during PM runtime suspend, PM system
suspend, and device unbinding (remove). It also disables the clock
on various error unwinding paths in pxa2xx_spi_probe().
However, if the clock is already disabled (for example, if the device is
already runtime-suspended during driver unbinding), calling the common
clock framework's clk_disable_unprepare() again leads to clock prepare/enable
count underflows, generating kernel warnings.
Introduce pxa2xx_spi_clk_enable() and pxa2xx_spi_clk_disable() helper
functions that track the clock enable state using a new 'clk_enabled'
boolean flag in struct driver_data.
This ensures clk_disable_unprepare() is called only when the clock is
active, preventing clock underflows during suspend transitions and unbind.
It also allows the probe function to safely unwind resource allocations
without triggering clock underflows.
Signed-off-by: Shih-Yuan Lee <fourdollars@debian.org>
---
drivers/spi/spi-pxa2xx.c | 37 +++++++++++++++++++++++++++++--------
drivers/spi/spi-pxa2xx.h | 2 ++
2 files changed, 31 insertions(+), 8 deletions(-)
diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index 6291d7c2e06f..d50152aad348 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -713,6 +713,28 @@ static void handle_bad_msg(struct driver_data *drv_data)
dev_err(drv_data->ssp->dev, "bad message state in interrupt handler\n");
}
+static int pxa2xx_spi_clk_enable(struct driver_data *drv_data)
+{
+ int ret;
+
+ if (drv_data->clk_enabled)
+ return 0;
+
+ ret = clk_prepare_enable(drv_data->ssp->clk);
+ if (ret == 0)
+ drv_data->clk_enabled = true;
+
+ return ret;
+}
+
+static void pxa2xx_spi_clk_disable(struct driver_data *drv_data)
+{
+ if (drv_data->clk_enabled) {
+ clk_disable_unprepare(drv_data->ssp->clk);
+ drv_data->clk_enabled = false;
+ }
+}
+
static irqreturn_t ssp_int(int irq, void *dev_id)
{
struct driver_data *drv_data = dev_id;
@@ -1352,7 +1374,7 @@ int pxa2xx_spi_probe(struct device *dev, struct ssp_device *ssp,
}
/* Enable SOC clock */
- status = clk_prepare_enable(ssp->clk);
+ status = pxa2xx_spi_clk_enable(drv_data);
if (status)
goto out_error_dma_irq_alloc;
@@ -1449,7 +1471,7 @@ int pxa2xx_spi_probe(struct device *dev, struct ssp_device *ssp,
return status;
out_error_clock_enabled:
- clk_disable_unprepare(ssp->clk);
+ pxa2xx_spi_clk_disable(drv_data);
out_error_dma_irq_alloc:
pxa2xx_spi_dma_release(drv_data);
@@ -1468,7 +1490,7 @@ void pxa2xx_spi_remove(struct device *dev)
/* Disable the SSP at the peripheral and SOC level */
pxa_ssp_disable(ssp);
- clk_disable_unprepare(ssp->clk);
+ pxa2xx_spi_clk_disable(drv_data);
/* Release DMA */
if (drv_data->controller_info->enable_dma)
@@ -1492,7 +1514,7 @@ static int pxa2xx_spi_suspend(struct device *dev)
pxa_ssp_disable(ssp);
if (!pm_runtime_suspended(dev))
- clk_disable_unprepare(ssp->clk);
+ pxa2xx_spi_clk_disable(drv_data);
return 0;
}
@@ -1500,12 +1522,11 @@ static int pxa2xx_spi_suspend(struct device *dev)
static int pxa2xx_spi_resume(struct device *dev)
{
struct driver_data *drv_data = dev_get_drvdata(dev);
- struct ssp_device *ssp = drv_data->ssp;
int status;
/* Enable the SSP clock */
if (!pm_runtime_suspended(dev)) {
- status = clk_prepare_enable(ssp->clk);
+ status = pxa2xx_spi_clk_enable(drv_data);
if (status)
return status;
}
@@ -1518,7 +1539,7 @@ static int pxa2xx_spi_runtime_suspend(struct device *dev)
{
struct driver_data *drv_data = dev_get_drvdata(dev);
- clk_disable_unprepare(drv_data->ssp->clk);
+ pxa2xx_spi_clk_disable(drv_data);
return 0;
}
@@ -1526,7 +1547,7 @@ static int pxa2xx_spi_runtime_resume(struct device *dev)
{
struct driver_data *drv_data = dev_get_drvdata(dev);
- return clk_prepare_enable(drv_data->ssp->clk);
+ return pxa2xx_spi_clk_enable(drv_data);
}
EXPORT_NS_GPL_DEV_PM_OPS(pxa2xx_spi_pm_ops, SPI_PXA2xx) = {
diff --git a/drivers/spi/spi-pxa2xx.h b/drivers/spi/spi-pxa2xx.h
index 447be0369384..820e573a3c60 100644
--- a/drivers/spi/spi-pxa2xx.h
+++ b/drivers/spi/spi-pxa2xx.h
@@ -72,6 +72,8 @@ struct driver_data {
void __iomem *lpss_base;
+ bool clk_enabled;
+
/* Optional slave FIFO ready signal */
struct gpio_desc *gpiod_ready;
};
--
2.39.5
^ permalink raw reply related [flat|nested] 25+ messages in thread* Re: [PATCH v16 1/7] spi: pxa2xx: introduce clock enable and disable helper functions
2026-07-20 16:21 ` [PATCH v16 1/7] spi: pxa2xx: introduce clock enable and disable helper functions Shih-Yuan Lee
@ 2026-07-20 19:22 ` Andy Shevchenko
0 siblings, 0 replies; 25+ messages in thread
From: Andy Shevchenko @ 2026-07-20 19:22 UTC (permalink / raw)
To: Shih-Yuan Lee
Cc: Mark Brown, Mika Westerberg, Lukas Wunner, Daniel Mack,
Haojian Zhuang, Robert Jarzmik, linux-arm-kernel, linux-spi,
linux-kernel
On Tue, Jul 21, 2026 at 12:21:10AM +0800, Shih-Yuan Lee wrote:
> The driver disables the clock during PM runtime suspend, PM system
> suspend, and device unbinding (remove). It also disables the clock
> on various error unwinding paths in pxa2xx_spi_probe().
>
> However, if the clock is already disabled (for example, if the device is
> already runtime-suspended during driver unbinding), calling the common
> clock framework's clk_disable_unprepare() again leads to clock prepare/enable
> count underflows, generating kernel warnings.
Any real life example here?
> Introduce pxa2xx_spi_clk_enable() and pxa2xx_spi_clk_disable() helper
> functions that track the clock enable state using a new 'clk_enabled'
> boolean flag in struct driver_data.
>
> This ensures clk_disable_unprepare() is called only when the clock is
> active, preventing clock underflows during suspend transitions and unbind.
> It also allows the probe function to safely unwind resource allocations
> without triggering clock underflows.
...
Same issue, I have no cover letter in my mailbox. Please, slow down and check
your email setup. Something is wrong.
...
> +static int pxa2xx_spi_clk_enable(struct driver_data *drv_data)
> +{
> + int ret;
> +
> + if (drv_data->clk_enabled)
> + return 0;
> +
> + ret = clk_prepare_enable(drv_data->ssp->clk);
> + if (ret == 0)
> + drv_data->clk_enabled = true;
> +
> + return ret;
Use usual pattern
if (ret)
return ret;
...
return 0;
> +}
> +static void pxa2xx_spi_clk_disable(struct driver_data *drv_data)
> +{
> + if (drv_data->clk_enabled) {
if (!drv_data->clk_enabled)
return;
> + clk_disable_unprepare(drv_data->ssp->clk);
> + drv_data->clk_enabled = false;
> + }
> +}
...
> struct driver_data {
> void __iomem *lpss_base;
>
> + bool clk_enabled;
How is this protected against simultaneously called enable/disable on different
CPUs?
> /* Optional slave FIFO ready signal */
> struct gpio_desc *gpiod_ready;
> };
Whenever you add the field, check with `pahole` that the layout is optimal.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 25+ messages in thread
* [PATCH v16 2/7] spi: pxa2xx: introduce suspended flag for interrupt synchronization
2026-07-20 16:21 [PATCH v16 0/7] spi: pxa2xx: Fix PM and interrupt issues on Intel LPSS SPI Shih-Yuan Lee
2026-07-20 16:21 ` [PATCH v16 1/7] spi: pxa2xx: introduce clock enable and disable helper functions Shih-Yuan Lee
@ 2026-07-20 16:21 ` Shih-Yuan Lee
2026-07-20 17:18 ` Mark Brown
2026-07-20 16:21 ` [PATCH v16 3/7] spi: pxa2xx: overhaul teardown and suspend sequence using pxa2xx_spi_off Shih-Yuan Lee
` (4 subsequent siblings)
6 siblings, 1 reply; 25+ messages in thread
From: Shih-Yuan Lee @ 2026-07-20 16:21 UTC (permalink / raw)
To: Mark Brown
Cc: Andy Shevchenko, Mika Westerberg, Lukas Wunner, Daniel Mack,
Haojian Zhuang, Robert Jarzmik, linux-arm-kernel, linux-spi,
linux-kernel, Shih-Yuan Lee
When a shared interrupt line is used, the interrupt handler ssp_int()
can be triggered by other devices sharing the line. The handler must
ensure it does not access the SSP controller registers via MMIO when
the device is powered down or when its clock is gated; otherwise, it
will cause PCIe Completion Timeouts and system hangs.
Currently, ssp_int() guards MMIO access using:
if (pm_runtime_suspended(drv_data->ssp->dev)) return IRQ_NONE;
However, during PM transitions (such as system suspend or runtime PM
autosuspend), device callbacks execute to disable the hardware and gate the
clock, but the PM state machine does not mark the device as RPM_SUSPENDED
until after the suspend callback returns. During this transitional state
(RPM_SUSPENDING), pm_runtime_suspended() returns false. If a shared
interrupt fires after the clock has been gated but before the PM state has
transitioned, ssp_int() will execute, attempt MMIO reads on the unclocked
register space, and hang the system.
Formal verification using Spin/PROMELA confirms that a scheduling window
exists where the interrupt thread accesses MMIO when clk_enabled is false,
violating safety properties.
Introduce a custom 'suspended' boolean flag in struct driver_data to
track the device's suspended state across all PM transitions. Check
both 'drv_data->suspended' and '!drv_data->clk_enabled' in ssp_int()
to return IRQ_NONE immediately before any MMIO access is attempted.
This closes the state transition race condition and mathematically guarantees
deadlock-free, safe shared interrupt handling during power transitions.
Signed-off-by: Shih-Yuan Lee <fourdollars@debian.org>
---
drivers/spi/spi-pxa2xx.c | 51 ++++++++++++++++++++++++++--------------
drivers/spi/spi-pxa2xx.h | 1 +
2 files changed, 35 insertions(+), 17 deletions(-)
diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index d50152aad348..c44349ab2b52 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -730,8 +730,8 @@ static int pxa2xx_spi_clk_enable(struct driver_data *drv_data)
static void pxa2xx_spi_clk_disable(struct driver_data *drv_data)
{
if (drv_data->clk_enabled) {
- clk_disable_unprepare(drv_data->ssp->clk);
drv_data->clk_enabled = false;
+ clk_disable_unprepare(drv_data->ssp->clk);
}
}
@@ -743,12 +743,12 @@ static irqreturn_t ssp_int(int irq, void *dev_id)
u32 status;
/*
- * The IRQ might be shared with other peripherals so we must first
- * check that are we RPM suspended or not. If we are we assume that
- * the IRQ was not for us (we shouldn't be RPM suspended when the
- * interrupt is enabled).
+ * The IRQ might be shared with other peripherals or trigger during
+ * power state transitions. First check if device is suspended or if
+ * clock is disabled; if so, return IRQ_NONE immediately to avoid
+ * unclocked MMIO reads.
*/
- if (pm_runtime_suspended(drv_data->ssp->dev))
+ if (drv_data->suspended || !drv_data->clk_enabled)
return IRQ_NONE;
/*
@@ -1310,6 +1310,7 @@ int pxa2xx_spi_probe(struct device *dev, struct ssp_device *ssp,
drv_data->controller = controller;
drv_data->controller_info = platform_info;
drv_data->ssp = ssp;
+ drv_data->suspended = true;
/* The spi->mode bits understood by this driver: */
controller->mode_bits = SPI_CPOL | SPI_CPHA | SPI_CS_HIGH | SPI_LOOP;
@@ -1352,11 +1353,6 @@ int pxa2xx_spi_probe(struct device *dev, struct ssp_device *ssp,
| SSSR_ROR | SSSR_TUR;
}
- status = request_irq(ssp->irq, ssp_int, IRQF_SHARED, dev_name(dev),
- drv_data);
- if (status < 0)
- return dev_err_probe(dev, status, "cannot get IRQ %d\n", ssp->irq);
-
/* Setup DMA if requested */
if (platform_info->enable_dma) {
status = pxa2xx_spi_dma_setup(drv_data);
@@ -1376,7 +1372,16 @@ int pxa2xx_spi_probe(struct device *dev, struct ssp_device *ssp,
/* Enable SOC clock */
status = pxa2xx_spi_clk_enable(drv_data);
if (status)
- goto out_error_dma_irq_alloc;
+ goto out_error_dma_alloc;
+
+ drv_data->suspended = false;
+
+ status = request_irq(ssp->irq, ssp_int, IRQF_SHARED, dev_name(dev),
+ drv_data);
+ if (status < 0) {
+ status = dev_err_probe(dev, status, "cannot get IRQ %d\n", ssp->irq);
+ goto out_error_clock_enabled;
+ }
controller->max_speed_hz = clk_get_rate(ssp->clk);
/*
@@ -1456,7 +1461,7 @@ int pxa2xx_spi_probe(struct device *dev, struct ssp_device *ssp,
"ready", GPIOD_OUT_LOW);
if (IS_ERR(drv_data->gpiod_ready)) {
status = PTR_ERR(drv_data->gpiod_ready);
- goto out_error_clock_enabled;
+ goto out_error_irq_alloc;
}
}
@@ -1465,17 +1470,19 @@ int pxa2xx_spi_probe(struct device *dev, struct ssp_device *ssp,
status = spi_register_controller(controller);
if (status) {
dev_err_probe(dev, status, "problem registering SPI controller\n");
- goto out_error_clock_enabled;
+ goto out_error_irq_alloc;
}
return status;
+out_error_irq_alloc:
+ free_irq(ssp->irq, drv_data);
+
out_error_clock_enabled:
pxa2xx_spi_clk_disable(drv_data);
-out_error_dma_irq_alloc:
+out_error_dma_alloc:
pxa2xx_spi_dma_release(drv_data);
- free_irq(ssp->irq, drv_data);
return status;
}
@@ -1511,6 +1518,7 @@ static int pxa2xx_spi_suspend(struct device *dev)
if (status)
return status;
+ drv_data->suspended = true;
pxa_ssp_disable(ssp);
if (!pm_runtime_suspended(dev))
@@ -1531,6 +1539,8 @@ static int pxa2xx_spi_resume(struct device *dev)
return status;
}
+ drv_data->suspended = false;
+
/* Start the queue running */
return spi_controller_resume(drv_data->controller);
}
@@ -1539,6 +1549,7 @@ static int pxa2xx_spi_runtime_suspend(struct device *dev)
{
struct driver_data *drv_data = dev_get_drvdata(dev);
+ drv_data->suspended = true;
pxa2xx_spi_clk_disable(drv_data);
return 0;
}
@@ -1546,8 +1557,14 @@ static int pxa2xx_spi_runtime_suspend(struct device *dev)
static int pxa2xx_spi_runtime_resume(struct device *dev)
{
struct driver_data *drv_data = dev_get_drvdata(dev);
+ int ret;
- return pxa2xx_spi_clk_enable(drv_data);
+ ret = pxa2xx_spi_clk_enable(drv_data);
+ if (ret)
+ return ret;
+
+ drv_data->suspended = false;
+ return 0;
}
EXPORT_NS_GPL_DEV_PM_OPS(pxa2xx_spi_pm_ops, SPI_PXA2xx) = {
diff --git a/drivers/spi/spi-pxa2xx.h b/drivers/spi/spi-pxa2xx.h
index 820e573a3c60..44f37bf9c519 100644
--- a/drivers/spi/spi-pxa2xx.h
+++ b/drivers/spi/spi-pxa2xx.h
@@ -72,6 +72,7 @@ struct driver_data {
void __iomem *lpss_base;
+ bool suspended;
bool clk_enabled;
/* Optional slave FIFO ready signal */
--
2.39.5
^ permalink raw reply related [flat|nested] 25+ messages in thread* Re: [PATCH v16 2/7] spi: pxa2xx: introduce suspended flag for interrupt synchronization
2026-07-20 16:21 ` [PATCH v16 2/7] spi: pxa2xx: introduce suspended flag for interrupt synchronization Shih-Yuan Lee
@ 2026-07-20 17:18 ` Mark Brown
0 siblings, 0 replies; 25+ messages in thread
From: Mark Brown @ 2026-07-20 17:18 UTC (permalink / raw)
To: Shih-Yuan Lee
Cc: Andy Shevchenko, Mika Westerberg, Lukas Wunner, Daniel Mack,
Haojian Zhuang, Robert Jarzmik, linux-arm-kernel, linux-spi,
linux-kernel
[-- Attachment #1: Type: text/plain, Size: 2423 bytes --]
On Tue, Jul 21, 2026 at 12:21:11AM +0800, Shih-Yuan Lee wrote:
> When a shared interrupt line is used, the interrupt handler ssp_int()
> can be triggered by other devices sharing the line. The handler must
> ensure it does not access the SSP controller registers via MMIO when
> the device is powered down or when its clock is gated; otherwise, it
> will cause PCIe Completion Timeouts and system hangs.
> Currently, ssp_int() guards MMIO access using:
> if (pm_runtime_suspended(drv_data->ssp->dev)) return IRQ_NONE;
...
> Introduce a custom 'suspended' boolean flag in struct driver_data to
> track the device's suspended state across all PM transitions. Check
> both 'drv_data->suspended' and '!drv_data->clk_enabled' in ssp_int()
> to return IRQ_NONE immediately before any MMIO access is attempted.
> static void pxa2xx_spi_clk_disable(struct driver_data *drv_data)
> {
> if (drv_data->clk_enabled) {
> - clk_disable_unprepare(drv_data->ssp->clk);
> drv_data->clk_enabled = false;
> + clk_disable_unprepare(drv_data->ssp->clk);
> }
> }
It's probably better to avoid extra changes like this, it makes the
patch bigger and a bit harder to review.
> @@ -743,12 +743,12 @@ static irqreturn_t ssp_int(int irq, void *dev_id)
> u32 status;
>
> /*
> - * The IRQ might be shared with other peripherals so we must first
> - * check that are we RPM suspended or not. If we are we assume that
> - * the IRQ was not for us (we shouldn't be RPM suspended when the
> - * interrupt is enabled).
> + * The IRQ might be shared with other peripherals or trigger during
> + * power state transitions. First check if device is suspended or if
> + * clock is disabled; if so, return IRQ_NONE immediately to avoid
> + * unclocked MMIO reads.
> */
> - if (pm_runtime_suspended(drv_data->ssp->dev))
> + if (drv_data->suspended || !drv_data->clk_enabled)
> return IRQ_NONE;
>
> /*
The local flags *must* be racy - I'm not seeing any locking which
protects them, nor anything that stops something else dropping a runtime
PM reference and powering things down after we checked here. There's a
helper in the power management code pm_runtime_get_if_active() which I
think is what you want here, it'll tell you if the device is runtime
suspended and if the device is active it'll ensure nothing else drops
the last reference while we're running.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* [PATCH v16 3/7] spi: pxa2xx: overhaul teardown and suspend sequence using pxa2xx_spi_off
2026-07-20 16:21 [PATCH v16 0/7] spi: pxa2xx: Fix PM and interrupt issues on Intel LPSS SPI Shih-Yuan Lee
2026-07-20 16:21 ` [PATCH v16 1/7] spi: pxa2xx: introduce clock enable and disable helper functions Shih-Yuan Lee
2026-07-20 16:21 ` [PATCH v16 2/7] spi: pxa2xx: introduce suspended flag for interrupt synchronization Shih-Yuan Lee
@ 2026-07-20 16:21 ` Shih-Yuan Lee
2026-07-20 19:53 ` Andy Shevchenko
2026-07-20 16:21 ` [PATCH v16 4/7] spi: pxa2xx: lock out runtime autosuspend for Intel LPSS SPI in PIO mode Shih-Yuan Lee
` (3 subsequent siblings)
6 siblings, 1 reply; 25+ messages in thread
From: Shih-Yuan Lee @ 2026-07-20 16:21 UTC (permalink / raw)
To: Mark Brown
Cc: Andy Shevchenko, Mika Westerberg, Lukas Wunner, Daniel Mack,
Haojian Zhuang, Robert Jarzmik, linux-arm-kernel, linux-spi,
linux-kernel, Shih-Yuan Lee
When removing the driver or suspending the device, the clock must not
be disabled while shared interrupts are still active. Gating the clock
before waiting for in-flight interrupt handlers to complete results
in race conditions where the handler performs unclocked MMIO accesses,
causing PCIe Completion Timeouts.
Overhaul the remove, suspend, and runtime_suspend paths to use a strict
synchronized teardown order:
1. Disable hardware interrupt generation at the controller level.
2. Mark the device state as suspended (suspended = true) to prevent
subsequent interrupt handlers from attempting MMIO reads.
3. Call synchronize_irq() to wait for any active interrupt handlers
to drain completely.
4. Gate the clock via pxa2xx_spi_clk_disable().
Additionally, commit 29d7e05c5f75 ("spi: pxa2xx: Avoid touching
SSCR0_SSE on MMP2") documented that disabling the hardware block via SSE on
MMP2 SoC platforms corrupts the RX/TX FIFO. Instead of calling
pxa_ssp_disable() directly, use the helper function pxa2xx_spi_off(),
which respects the MMP2 platform quirk by bypassing SSE register writes.
Signed-off-by: Shih-Yuan Lee <fourdollars@debian.org>
---
drivers/spi/spi-pxa2xx.c | 45 ++++++++++++++++++++++++++++------------
1 file changed, 32 insertions(+), 13 deletions(-)
diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index c44349ab2b52..6bfd3382acc3 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -1495,16 +1495,24 @@ void pxa2xx_spi_remove(struct device *dev)
spi_unregister_controller(drv_data->controller);
- /* Disable the SSP at the peripheral and SOC level */
- pxa_ssp_disable(ssp);
+ /* Disable SSP interrupt generation on hardware level while clock is active */
+ pxa2xx_spi_off(drv_data);
+
+ /* Mark as suspended to prevent further IRQ handling */
+ drv_data->suspended = true;
+
+ /* Wait for any pending interrupt handlers to complete */
+ synchronize_irq(ssp->irq);
+
+ /* Release IRQ */
+ free_irq(ssp->irq, drv_data);
+
+ /* Safe to disable the SSP clock now */
pxa2xx_spi_clk_disable(drv_data);
/* Release DMA */
if (drv_data->controller_info->enable_dma)
pxa2xx_spi_dma_release(drv_data);
-
- /* Release IRQ */
- free_irq(ssp->irq, drv_data);
}
EXPORT_SYMBOL_NS_GPL(pxa2xx_spi_remove, "SPI_PXA2xx");
@@ -1519,10 +1527,10 @@ static int pxa2xx_spi_suspend(struct device *dev)
return status;
drv_data->suspended = true;
- pxa_ssp_disable(ssp);
+ pxa2xx_spi_off(drv_data);
+ synchronize_irq(ssp->irq);
- if (!pm_runtime_suspended(dev))
- pxa2xx_spi_clk_disable(drv_data);
+ pxa2xx_spi_clk_disable(drv_data);
return 0;
}
@@ -1530,6 +1538,7 @@ static int pxa2xx_spi_suspend(struct device *dev)
static int pxa2xx_spi_resume(struct device *dev)
{
struct driver_data *drv_data = dev_get_drvdata(dev);
+ struct ssp_device *ssp = drv_data->ssp;
int status;
/* Enable the SSP clock */
@@ -1542,7 +1551,15 @@ static int pxa2xx_spi_resume(struct device *dev)
drv_data->suspended = false;
/* Start the queue running */
- return spi_controller_resume(drv_data->controller);
+ status = spi_controller_resume(drv_data->controller);
+ if (status) {
+ drv_data->suspended = true;
+ synchronize_irq(ssp->irq);
+ pxa2xx_spi_clk_disable(drv_data);
+ return status;
+ }
+
+ return 0;
}
static int pxa2xx_spi_runtime_suspend(struct device *dev)
@@ -1550,6 +1567,8 @@ static int pxa2xx_spi_runtime_suspend(struct device *dev)
struct driver_data *drv_data = dev_get_drvdata(dev);
drv_data->suspended = true;
+ pxa2xx_spi_off(drv_data);
+ synchronize_irq(drv_data->ssp->irq);
pxa2xx_spi_clk_disable(drv_data);
return 0;
}
@@ -1557,11 +1576,11 @@ static int pxa2xx_spi_runtime_suspend(struct device *dev)
static int pxa2xx_spi_runtime_resume(struct device *dev)
{
struct driver_data *drv_data = dev_get_drvdata(dev);
- int ret;
+ int status;
- ret = pxa2xx_spi_clk_enable(drv_data);
- if (ret)
- return ret;
+ status = pxa2xx_spi_clk_enable(drv_data);
+ if (status)
+ return status;
drv_data->suspended = false;
return 0;
--
2.39.5
^ permalink raw reply related [flat|nested] 25+ messages in thread* Re: [PATCH v16 3/7] spi: pxa2xx: overhaul teardown and suspend sequence using pxa2xx_spi_off
2026-07-20 16:21 ` [PATCH v16 3/7] spi: pxa2xx: overhaul teardown and suspend sequence using pxa2xx_spi_off Shih-Yuan Lee
@ 2026-07-20 19:53 ` Andy Shevchenko
0 siblings, 0 replies; 25+ messages in thread
From: Andy Shevchenko @ 2026-07-20 19:53 UTC (permalink / raw)
To: Shih-Yuan Lee
Cc: Mark Brown, Mika Westerberg, Lukas Wunner, Daniel Mack,
Haojian Zhuang, Robert Jarzmik, linux-arm-kernel, linux-spi,
linux-kernel
On Tue, Jul 21, 2026 at 12:21:12AM +0800, Shih-Yuan Lee wrote:
> When removing the driver or suspending the device, the clock must not
> be disabled while shared interrupts are still active. Gating the clock
> before waiting for in-flight interrupt handlers to complete results
> in race conditions where the handler performs unclocked MMIO accesses,
> causing PCIe Completion Timeouts.
>
> Overhaul the remove, suspend, and runtime_suspend paths to use a strict
> synchronized teardown order:
> 1. Disable hardware interrupt generation at the controller level.
> 2. Mark the device state as suspended (suspended = true) to prevent
> subsequent interrupt handlers from attempting MMIO reads.
> 3. Call synchronize_irq() to wait for any active interrupt handlers
> to drain completely.
> 4. Gate the clock via pxa2xx_spi_clk_disable().
>
> Additionally, commit 29d7e05c5f75 ("spi: pxa2xx: Avoid touching
> SSCR0_SSE on MMP2") documented that disabling the hardware block via SSE on
> MMP2 SoC platforms corrupts the RX/TX FIFO. Instead of calling
> pxa_ssp_disable() directly, use the helper function pxa2xx_spi_off(),
> which respects the MMP2 platform quirk by bypassing SSE register writes.
...
> + /* Wait for any pending interrupt handlers to complete */
> + synchronize_irq(ssp->irq);
Unneeded. free_irq() implies that.
> + /* Release IRQ */
> + free_irq(ssp->irq, drv_data);
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 25+ messages in thread
* [PATCH v16 4/7] spi: pxa2xx: lock out runtime autosuspend for Intel LPSS SPI in PIO mode
2026-07-20 16:21 [PATCH v16 0/7] spi: pxa2xx: Fix PM and interrupt issues on Intel LPSS SPI Shih-Yuan Lee
` (2 preceding siblings ...)
2026-07-20 16:21 ` [PATCH v16 3/7] spi: pxa2xx: overhaul teardown and suspend sequence using pxa2xx_spi_off Shih-Yuan Lee
@ 2026-07-20 16:21 ` Shih-Yuan Lee
2026-07-20 19:55 ` Andy Shevchenko
2026-07-20 16:21 ` [PATCH v16 5/7] spi: pxa2xx: disable DMA for Apple MacBook8,1 Shih-Yuan Lee
` (2 subsequent siblings)
6 siblings, 1 reply; 25+ messages in thread
From: Shih-Yuan Lee @ 2026-07-20 16:21 UTC (permalink / raw)
To: Mark Brown
Cc: Andy Shevchenko, Mika Westerberg, Lukas Wunner, Daniel Mack,
Haojian Zhuang, Robert Jarzmik, linux-arm-kernel, linux-spi,
linux-kernel, Shih-Yuan Lee
When operating in PIO mode on Intel LPSS SPI controllers, runtime PM
autosuspend clock-gates the hardware block when idle. On subsequent
transfers, MMIO accesses to trigger resume are performed before the runtime
PM state machine can wake the controller, causing PCIe Completion Timeouts.
This issue does not affect DMA mode, where the DMA engine holds the required
resources, nor does it affect non-LPSS controllers.
Lock out runtime PM autosuspend for LPSS SPI controllers specifically
when operating in PIO mode.
Acquire a runtime PM reference via pm_runtime_get_noresume() in
pxa2xx_spi_probe() after registration, and release it via
pm_runtime_put_noidle() in pxa2xx_spi_remove() before hardware teardown to
ensure the runtime PM reference held in probe is released without invoking
runtime_suspend on already-unclocked hardware.
Signed-off-by: Shih-Yuan Lee <fourdollars@debian.org>
---
drivers/spi/spi-pxa2xx.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index 6bfd3382acc3..34241a6742eb 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -1473,6 +1473,9 @@ int pxa2xx_spi_probe(struct device *dev, struct ssp_device *ssp,
goto out_error_irq_alloc;
}
+ if (is_lpss_ssp(drv_data) && !platform_info->enable_dma)
+ pm_runtime_get_noresume(dev);
+
return status;
out_error_irq_alloc:
@@ -1495,6 +1498,13 @@ void pxa2xx_spi_remove(struct device *dev)
spi_unregister_controller(drv_data->controller);
+ /* Release the PM reference held in probe for LPSS PIO mode before
+ * hardware teardown so the PM core does not invoke runtime_suspend
+ * on already-unclocked hardware.
+ */
+ if (is_lpss_ssp(drv_data) && !drv_data->controller_info->enable_dma)
+ pm_runtime_put_noidle(dev);
+
/* Disable SSP interrupt generation on hardware level while clock is active */
pxa2xx_spi_off(drv_data);
--
2.39.5
^ permalink raw reply related [flat|nested] 25+ messages in thread* Re: [PATCH v16 4/7] spi: pxa2xx: lock out runtime autosuspend for Intel LPSS SPI in PIO mode
2026-07-20 16:21 ` [PATCH v16 4/7] spi: pxa2xx: lock out runtime autosuspend for Intel LPSS SPI in PIO mode Shih-Yuan Lee
@ 2026-07-20 19:55 ` Andy Shevchenko
0 siblings, 0 replies; 25+ messages in thread
From: Andy Shevchenko @ 2026-07-20 19:55 UTC (permalink / raw)
To: Shih-Yuan Lee
Cc: Mark Brown, Mika Westerberg, Lukas Wunner, Daniel Mack,
Haojian Zhuang, Robert Jarzmik, linux-arm-kernel, linux-spi,
linux-kernel
On Tue, Jul 21, 2026 at 12:21:13AM +0800, Shih-Yuan Lee wrote:
> When operating in PIO mode on Intel LPSS SPI controllers, runtime PM
> autosuspend clock-gates the hardware block when idle. On subsequent
> transfers, MMIO accesses to trigger resume are performed before the runtime
> PM state machine can wake the controller, causing PCIe Completion Timeouts.
> This issue does not affect DMA mode, where the DMA engine holds the required
> resources, nor does it affect non-LPSS controllers.
>
> Lock out runtime PM autosuspend for LPSS SPI controllers specifically
> when operating in PIO mode.
>
> Acquire a runtime PM reference via pm_runtime_get_noresume() in
> pxa2xx_spi_probe() after registration, and release it via
> pm_runtime_put_noidle() in pxa2xx_spi_remove() before hardware teardown to
> ensure the runtime PM reference held in probe is released without invoking
> runtime_suspend on already-unclocked hardware.
.runtime_suspend()
// this is how we refer to the callbacks.
...
> + /* Release the PM reference held in probe for LPSS PIO mode before
> + * hardware teardown so the PM core does not invoke runtime_suspend
> + * on already-unclocked hardware.
> + */
/*
* Keep the comment style as per SPI and many other subsystems
* and as in this example.
*/
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 25+ messages in thread
* [PATCH v16 5/7] spi: pxa2xx: disable DMA for Apple MacBook8,1
2026-07-20 16:21 [PATCH v16 0/7] spi: pxa2xx: Fix PM and interrupt issues on Intel LPSS SPI Shih-Yuan Lee
` (3 preceding siblings ...)
2026-07-20 16:21 ` [PATCH v16 4/7] spi: pxa2xx: lock out runtime autosuspend for Intel LPSS SPI in PIO mode Shih-Yuan Lee
@ 2026-07-20 16:21 ` Shih-Yuan Lee
2026-07-20 19:27 ` Andy Shevchenko
2026-07-21 9:00 ` Lukas Wunner
2026-07-20 16:21 ` [PATCH v16 6/7] spi: pxa2xx: restore LPSS private register state on S3 resume Shih-Yuan Lee
2026-07-20 16:21 ` [PATCH v16 7/7] spi: pxa2xx: rename local status variable to ret Shih-Yuan Lee
6 siblings, 2 replies; 25+ messages in thread
From: Shih-Yuan Lee @ 2026-07-20 16:21 UTC (permalink / raw)
To: Mark Brown
Cc: Andy Shevchenko, Mika Westerberg, Lukas Wunner, Daniel Mack,
Haojian Zhuang, Robert Jarzmik, linux-arm-kernel, linux-spi,
linux-kernel, Shih-Yuan Lee
On MacBook8,1 (early 2015 12" MacBook), the LPSS SPI controller at
00:15.4 suffers from hardware DMA handshake failures and interrupt
routing bugs, causing keyboard/touchpad transactions to fail when
DMA is enabled.
Move the forced PIO mode DMI quirk to spi-pxa2xx-pci.c (the LPSS host
controller PCI glue driver) to avoid layering violations in client
drivers (such as applespi).
Add an explicit DMI match table for MacBook8,1 and a module parameter
spi_pxa2xx_force_pio to allow forcing PIO mode on demand.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=108331
Signed-off-by: Shih-Yuan Lee <fourdollars@debian.org>
---
drivers/spi/spi-pxa2xx-pci.c | 35 +++++++++++++++++++++++++++++++++--
1 file changed, 33 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-pxa2xx-pci.c b/drivers/spi/spi-pxa2xx-pci.c
index cae77ac18520..31bdaa096d9e 100644
--- a/drivers/spi/spi-pxa2xx-pci.c
+++ b/drivers/spi/spi-pxa2xx-pci.c
@@ -18,9 +18,14 @@
#include <linux/dmaengine.h>
#include <linux/platform_data/dma-dw.h>
+#include <linux/dmi.h>
#include "spi-pxa2xx.h"
+static bool spi_pxa2xx_force_pio;
+module_param_named(force_pio, spi_pxa2xx_force_pio, bool, 0444);
+MODULE_PARM_DESC(force_pio, "Force PIO mode (disables DMA) for SPI transfers. ([0] = disabled, 1 = enabled)");
+
#define PCI_DEVICE_ID_INTEL_QUARK_X1000 0x0935
#define PCI_DEVICE_ID_INTEL_BYT 0x0f0e
#define PCI_DEVICE_ID_INTEL_MRFLD 0x1194
@@ -93,6 +98,32 @@ static void lpss_dma_put_device(void *dma_dev)
pci_dev_put(dma_dev);
}
+static const struct dmi_system_id pxa2xx_spi_pci_dmi_table[] = {
+ {
+ .ident = "Apple MacBook8,1",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "MacBook8,1"),
+ },
+ },
+ { }
+};
+
+static bool pxa2xx_spi_pci_can_dma(struct pci_dev *dev)
+{
+ if (spi_pxa2xx_force_pio) {
+ pci_info(dev, "Forcing PIO mode (disabling DMA)\n");
+ return false;
+ }
+
+ if (dmi_check_system(pxa2xx_spi_pci_dmi_table)) {
+ pci_info(dev, "MacBook8,1 detected: disabling DMA to force PIO mode\n");
+ return false;
+ }
+
+ return true;
+}
+
static int lpss_spi_setup(struct pci_dev *dev, struct pxa2xx_spi_controller *c)
{
struct ssp_device *ssp = &c->ssp;
@@ -166,7 +197,7 @@ static int lpss_spi_setup(struct pci_dev *dev, struct pxa2xx_spi_controller *c)
c->dma_filter = lpss_dma_filter;
c->dma_burst_size = 1;
- c->enable_dma = 1;
+ c->enable_dma = pxa2xx_spi_pci_can_dma(dev);
return 0;
}
@@ -238,7 +269,7 @@ static int mrfld_spi_setup(struct pci_dev *dev, struct pxa2xx_spi_controller *c)
c->dma_filter = lpss_dma_filter;
c->dma_burst_size = 8;
- c->enable_dma = 1;
+ c->enable_dma = pxa2xx_spi_pci_can_dma(dev);
return 0;
}
--
2.39.5
^ permalink raw reply related [flat|nested] 25+ messages in thread* Re: [PATCH v16 5/7] spi: pxa2xx: disable DMA for Apple MacBook8,1
2026-07-20 16:21 ` [PATCH v16 5/7] spi: pxa2xx: disable DMA for Apple MacBook8,1 Shih-Yuan Lee
@ 2026-07-20 19:27 ` Andy Shevchenko
2026-07-21 14:49 ` Shih-Yuan Lee (FourDollars)
2026-07-21 9:00 ` Lukas Wunner
1 sibling, 1 reply; 25+ messages in thread
From: Andy Shevchenko @ 2026-07-20 19:27 UTC (permalink / raw)
To: Shih-Yuan Lee
Cc: Mark Brown, Mika Westerberg, Lukas Wunner, Daniel Mack,
Haojian Zhuang, Robert Jarzmik, linux-arm-kernel, linux-spi,
linux-kernel
On Tue, Jul 21, 2026 at 12:21:14AM +0800, Shih-Yuan Lee wrote:
> On MacBook8,1 (early 2015 12" MacBook), the LPSS SPI controller at
> 00:15.4 suffers from hardware DMA handshake failures and interrupt
> routing bugs, causing keyboard/touchpad transactions to fail when
> DMA is enabled.
Why? The thing like this I noticed on some other HW which required different
DMA settings. Have you tried to investigate the issue more?
> Move the forced PIO mode DMI quirk to spi-pxa2xx-pci.c (the LPSS host
> controller PCI glue driver) to avoid layering violations in client
> drivers (such as applespi).
>
> Add an explicit DMI match table for MacBook8,1 and a module parameter
> spi_pxa2xx_force_pio to allow forcing PIO mode on demand.
This looks like a hack. Please, if you have a hardware, try to dump the errors,
collect the data corruption or timeouts and provide more information. DMA for
SPI on LPSS hardware never was a problem (unlike UART in some cases). I'm almost
100% sure the problem is in DMA configuration / setting bits.
...
> #include <linux/dmaengine.h>
> #include <linux/platform_data/dma-dw.h>
> +#include <linux/dmi.h>
Keep list ordered.
> #include "spi-pxa2xx.h"
...
> +static bool spi_pxa2xx_force_pio;
> +module_param_named(force_pio, spi_pxa2xx_force_pio, bool, 0444);
> +MODULE_PARM_DESC(force_pio, "Force PIO mode (disables DMA) for SPI transfers. ([0] = disabled, 1 = enabled)");
No. There is no room for module parameters like this.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH v16 5/7] spi: pxa2xx: disable DMA for Apple MacBook8,1
2026-07-20 19:27 ` Andy Shevchenko
@ 2026-07-21 14:49 ` Shih-Yuan Lee (FourDollars)
2026-07-21 20:31 ` Andy Shevchenko
0 siblings, 1 reply; 25+ messages in thread
From: Shih-Yuan Lee (FourDollars) @ 2026-07-21 14:49 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Mark Brown, Mika Westerberg, Lukas Wunner, Daniel Mack,
Haojian Zhuang, Robert Jarzmik, linux-arm-kernel, linux-spi,
linux-kernel
On Tue, Jul 21, 2026 at 3:27 AM Andy Shevchenko
<andriy.shevchenko@intel.com> wrote:
>
> On Tue, Jul 21, 2026 at 12:21:14AM +0800, Shih-Yuan Lee wrote:
> > On MacBook8,1 (early 2015 12" MacBook), the LPSS SPI controller at
> > 00:15.4 suffers from hardware DMA handshake failures and interrupt
> > routing bugs, causing keyboard/touchpad transactions to fail when
> > DMA is enabled.
>
> Why? The thing like this I noticed on some other HW which required different
> DMA settings. Have you tried to investigate the issue more?
>
> > Move the forced PIO mode DMI quirk to spi-pxa2xx-pci.c (the LPSS host
> > controller PCI glue driver) to avoid layering violations in client
> > drivers (such as applespi).
> >
> > Add an explicit DMI match table for MacBook8,1 and a module parameter
> > spi_pxa2xx_force_pio to allow forcing PIO mode on demand.
>
> This looks like a hack. Please, if you have a hardware, try to dump the errors,
> collect the data corruption or timeouts and provide more information. DMA for
> SPI on LPSS hardware never was a problem (unlike UART in some cases). I'm almost
> 100% sure the problem is in DMA configuration / setting bits.
>
> ...
>
> > #include <linux/dmaengine.h>
> > #include <linux/platform_data/dma-dw.h>
> > +#include <linux/dmi.h>
>
> Keep list ordered.
>
> > #include "spi-pxa2xx.h"
>
> ...
>
> > +static bool spi_pxa2xx_force_pio;
> > +module_param_named(force_pio, spi_pxa2xx_force_pio, bool, 0444);
> > +MODULE_PARM_DESC(force_pio, "Force PIO mode (disables DMA) for SPI transfers. ([0] = disabled, 1 = enabled)");
>
> No. There is no room for module parameters like this.
Hi Andy,
Thank you for the review and feedback.
Regarding your question about why DMA fails on this hardware, I have
just sent a detailed reply to Lukas in this thread outlining our
physical verification findings. In short, I confirmed that the
DMA controller's physical interrupt line is not functioning on this
motherboard, and macOS and Windows 10 also completely bypass the DMA
controller. Please refer to that email for the DMAR/IOMMU and
cross-OS analysis details.
Regarding your other comments:
1. Header Sorting:
I will fix the alphabetical ordering of the include headers in the
next revision.
2. The force_pio Module Parameter:
The original spi-pxa2xx driver is designed to hardcode DMA usage if
DMA channels are available. I introduced the force_pio module
parameter for two reasons:
• It serves as a diagnostic tool for users on similar hardware to
easily test and verify if their issues are related to DMA.
• It allows developers to easily test and debug the PIO code path on
DMA-capable LPSS hardware to prevent regressions.
That being said, if module parameters of this type are strictly not
preferred, I am completely fine with removing force_pio and keeping
only the DMI-based quirk for the MacBook8,1. Please let me know your
preference.
Thanks,
Shih-Yuan
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH v16 5/7] spi: pxa2xx: disable DMA for Apple MacBook8,1
2026-07-21 14:49 ` Shih-Yuan Lee (FourDollars)
@ 2026-07-21 20:31 ` Andy Shevchenko
0 siblings, 0 replies; 25+ messages in thread
From: Andy Shevchenko @ 2026-07-21 20:31 UTC (permalink / raw)
To: Shih-Yuan Lee (FourDollars)
Cc: Mark Brown, Mika Westerberg, Lukas Wunner, Daniel Mack,
Haojian Zhuang, Robert Jarzmik, linux-arm-kernel, linux-spi,
linux-kernel
On Tue, Jul 21, 2026 at 10:49:17PM +0800, Shih-Yuan Lee (FourDollars) wrote:
> On Tue, Jul 21, 2026 at 3:27 AM Andy Shevchenko
> <andriy.shevchenko@intel.com> wrote:
> > On Tue, Jul 21, 2026 at 12:21:14AM +0800, Shih-Yuan Lee wrote:
...
> Thank you for the review and feedback.
>
> Regarding your question about why DMA fails on this hardware, I have
> just sent a detailed reply to Lukas in this thread outlining our
> physical verification findings. In short, I confirmed that the
> DMA controller's physical interrupt line is not functioning on this
> motherboard,
It might be wrongly described in ACPI tables, but in HW it works.
> and macOS and Windows 10 also completely bypass the DMA
> controller. Please refer to that email for the DMAR/IOMMU and
> cross-OS analysis details.
>
> Regarding your other comments:
> 2. The force_pio Module Parameter:
> The original spi-pxa2xx driver is designed to hardcode DMA usage if
> DMA channels are available. I introduced the force_pio module
> parameter for two reasons:
> • It serves as a diagnostic tool for users on similar hardware to
> easily test and verify if their issues are related to DMA.
> • It allows developers to easily test and debug the PIO code path on
> DMA-capable LPSS hardware to prevent regressions.
>
> That being said, if module parameters of this type are strictly not
> preferred, I am completely fine with removing force_pio and keeping
> only the DMI-based quirk for the MacBook8,1. Please let me know your
> preference.
Neither is preferred until we will fully understand what's going on there.
Yes, DMI quirk is a last resort, but to come to that we need to try better
options. See my other reply about the DMA case.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH v16 5/7] spi: pxa2xx: disable DMA for Apple MacBook8,1
2026-07-20 16:21 ` [PATCH v16 5/7] spi: pxa2xx: disable DMA for Apple MacBook8,1 Shih-Yuan Lee
2026-07-20 19:27 ` Andy Shevchenko
@ 2026-07-21 9:00 ` Lukas Wunner
2026-07-21 9:26 ` Shih-Yuan Lee (FourDollars)
1 sibling, 1 reply; 25+ messages in thread
From: Lukas Wunner @ 2026-07-21 9:00 UTC (permalink / raw)
To: Shih-Yuan Lee
Cc: Mark Brown, Andy Shevchenko, Mika Westerberg, Daniel Mack,
Haojian Zhuang, Robert Jarzmik, linux-arm-kernel, linux-spi,
linux-kernel
On Tue, Jul 21, 2026 at 12:21:14AM +0800, Shih-Yuan Lee wrote:
> On MacBook8,1 (early 2015 12" MacBook), the LPSS SPI controller at
> 00:15.4 suffers from hardware DMA handshake failures and interrupt
> routing bugs, causing keyboard/touchpad transactions to fail when
> DMA is enabled.
[...]
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=108331
In the bugzilla comments, Leif Liddy writes:
"I needed to modify drivers/dma/dw/pci.c to assign the DMA controller
irq value to 21 (which is what is listed in the ACPI table) for it
to work. The DMA controller was being assigned an irq value of 20
for some reason."
It would seem better to fix up the incorrect interrupt number in a quirk,
rather than disabling DMA wholesale.
Thanks,
Lukas
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [PATCH v16 5/7] spi: pxa2xx: disable DMA for Apple MacBook8,1
2026-07-21 9:00 ` Lukas Wunner
@ 2026-07-21 9:26 ` Shih-Yuan Lee (FourDollars)
2026-07-21 14:34 ` Shih-Yuan Lee (FourDollars)
0 siblings, 1 reply; 25+ messages in thread
From: Shih-Yuan Lee (FourDollars) @ 2026-07-21 9:26 UTC (permalink / raw)
To: Lukas Wunner
Cc: Mark Brown, Andy Shevchenko, Mika Westerberg, Daniel Mack,
Haojian Zhuang, Robert Jarzmik, linux-arm-kernel, linux-spi,
linux-kernel
On Tue, Jul 21, 2026 at 5:18 PM Lukas Wunner <lukas@wunner.de> wrote:
>
> On Tue, Jul 21, 2026 at 12:21:14AM +0800, Shih-Yuan Lee wrote:
> > On MacBook8,1 (early 2015 12" MacBook), the LPSS SPI controller at
> > 00:15.4 suffers from hardware DMA handshake failures and interrupt
> > routing bugs, causing keyboard/touchpad transactions to fail when
> > DMA is enabled.
> [...]
> > Link: https://bugzilla.kernel.org/show_bug.cgi?id=108331
>
> In the bugzilla comments, Leif Liddy writes:
>
> "I needed to modify drivers/dma/dw/pci.c to assign the DMA controller
> irq value to 21 (which is what is listed in the ACPI table) for it
> to work. The DMA controller was being assigned an irq value of 20
> for some reason."
>
> It would seem better to fix up the incorrect interrupt number in a quirk,
> rather than disabling DMA wholesale.
This is a very good catch!
I appreciate the comment. Based on the Bugzilla feedback regarding the
incorrect interrupt assignment, it seems fixing the IRQ value via a
quirk is indeed a better approach than disabling DMA wholesale. While
I am not certain this will resolve the issue entirely, it looks very
promising. I will investigate the IRQ mis-assignment problem further.
Shih-Yuan
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH v16 5/7] spi: pxa2xx: disable DMA for Apple MacBook8,1
2026-07-21 9:26 ` Shih-Yuan Lee (FourDollars)
@ 2026-07-21 14:34 ` Shih-Yuan Lee (FourDollars)
2026-07-21 15:05 ` Mark Brown
0 siblings, 1 reply; 25+ messages in thread
From: Shih-Yuan Lee (FourDollars) @ 2026-07-21 14:34 UTC (permalink / raw)
To: Lukas Wunner
Cc: Mark Brown, Andy Shevchenko, Mika Westerberg, Daniel Mack,
Haojian Zhuang, Robert Jarzmik, linux-arm-kernel, linux-spi,
linux-kernel
On Tue, Jul 21, 2026 at 5:26 PM Shih-Yuan Lee (FourDollars)
<fourdollars@debian.org> wrote:
>
> On Tue, Jul 21, 2026 at 5:18 PM Lukas Wunner <lukas@wunner.de> wrote:
> >
> > On Tue, Jul 21, 2026 at 12:21:14AM +0800, Shih-Yuan Lee wrote:
> > > On MacBook8,1 (early 2015 12" MacBook), the LPSS SPI controller at
> > > 00:15.4 suffers from hardware DMA handshake failures and interrupt
> > > routing bugs, causing keyboard/touchpad transactions to fail when
> > > DMA is enabled.
> > [...]
> > > Link: https://bugzilla.kernel.org/show_bug.cgi?id=108331
> >
> > In the bugzilla comments, Leif Liddy writes:
> >
> > "I needed to modify drivers/dma/dw/pci.c to assign the DMA controller
> > irq value to 21 (which is what is listed in the ACPI table) for it
> > to work. The DMA controller was being assigned an irq value of 20
> > for some reason."
> >
> > It would seem better to fix up the incorrect interrupt number in a quirk,
> > rather than disabling DMA wholesale.
>
> This is a very good catch!
>
> I appreciate the comment. Based on the Bugzilla feedback regarding the
> incorrect interrupt assignment, it seems fixing the IRQ value via a
> quirk is indeed a better approach than disabling DMA wholesale. While
> I am not certain this will resolve the issue entirely, it looks very
> promising. I will investigate the IRQ mis-assignment problem further.
Hi Lukas,
Thank you for the suggestion. I have investigated this direction
thoroughly by implementing the DMI-based IRQ override quirk in
drivers/dma/dw/pci.c to assign both pdev->irq and chip->irq to 21 on
the physical MacBook8,1.
However, I found that fixing up the IRQ to 21 in software is not a
viable solution due to the following findings:
1. DMAR/IOMMU Validation Failure (Error -22)
On modern kernels with Interrupt Remapping (DMAR) enabled, overriding
pdev->irq to 21 causes the dw_dmac_pci driver probe to fail with
-EINVAL (-22) during request_irq(). This is because the
DMAR/IOMMU strictly validates the PCI Requester ID (source ID) against
the GSI mapping defined in the ACPI _PRT table. Forcing a device
mapped to GSI 20 (00:15.0) to register on GSI 21 triggers a
source ID mismatch check, which the kernel rejects.
2. The Mechanism Behind the Historical irqpoll Workaround
In Bugzilla ticket 108331, the reason Leif Liddy's workaround
functioned might be that they booted the system with irqpoll or
irqfixup. Under irqpoll, the kernel polls the DMA status register on
every clock tick/timer interrupt, which completely bypasses the broken
physical interrupt line at the cost of high CPU overhead and power
consumption. Without irqpoll, even if we register the handler
on IRQ 21, the driver never receives physical interrupts because the
hardware line on the motherboard is physically disconnected or masked.
3. Cross-OS Evidence (macOS and Windows 10)
• macOS: Apple's native driver runs the SPI controller in pure PIO mode.
• Windows 10 (Boot Camp): Interestingly, the Intel LPSS DMA
Controller (8086:9ce0) is left completely driverless (no driver
installed) by the official Boot Camp package, and does not register or
use IRQ 20 at all. This forces the Windows SPI driver
(iaLPSS_SPI.sys) to fall back to pure PIO mode as well.
Since both macOS and Windows officially disable DMA to work around
this hardware routing defect, forcing PIO mode in spi-pxa2xx is the
most native, clean, and power-efficient way to support the
MacBook8,1 without introducing probe errors or relying on
high-overhead irqpoll workarounds.
Therefore, disabling DMA wholesale for this platform seems to be the
only correct solution. I will update the commit message of the next
revision to document these physical verification findings.
Thanks,
Shih-Yuan
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [PATCH v16 5/7] spi: pxa2xx: disable DMA for Apple MacBook8,1
2026-07-21 14:34 ` Shih-Yuan Lee (FourDollars)
@ 2026-07-21 15:05 ` Mark Brown
2026-07-21 15:26 ` Shih-Yuan Lee (FourDollars)
0 siblings, 1 reply; 25+ messages in thread
From: Mark Brown @ 2026-07-21 15:05 UTC (permalink / raw)
To: Shih-Yuan Lee (FourDollars)
Cc: Lukas Wunner, Andy Shevchenko, Mika Westerberg, Daniel Mack,
Haojian Zhuang, Robert Jarzmik, linux-arm-kernel, linux-spi,
linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1644 bytes --]
On Tue, Jul 21, 2026 at 10:34:20PM +0800, Shih-Yuan Lee (FourDollars) wrote:
> On Tue, Jul 21, 2026 at 5:26 PM Shih-Yuan Lee (FourDollars)
> > On Tue, Jul 21, 2026 at 5:18 PM Lukas Wunner <lukas@wunner.de> wrote:
> > > It would seem better to fix up the incorrect interrupt number in a quirk,
> > > rather than disabling DMA wholesale.
> > I appreciate the comment. Based on the Bugzilla feedback regarding the
> > incorrect interrupt assignment, it seems fixing the IRQ value via a
> > quirk is indeed a better approach than disabling DMA wholesale. While
> > I am not certain this will resolve the issue entirely, it looks very
> > promising. I will investigate the IRQ mis-assignment problem further.
> 1. DMAR/IOMMU Validation Failure (Error -22)
> On modern kernels with Interrupt Remapping (DMAR) enabled, overriding
> pdev->irq to 21 causes the dw_dmac_pci driver probe to fail with
> -EINVAL (-22) during request_irq(). This is because the
> DMAR/IOMMU strictly validates the PCI Requester ID (source ID) against
> the GSI mapping defined in the ACPI _PRT table. Forcing a device
> mapped to GSI 20 (00:15.0) to register on GSI 21 triggers a
> source ID mismatch check, which the kernel rejects.
That really seems like something we ought to be able to do, though I
think the idiom here is to patch the ACPI tables so they are correct
rather than quirk things in C code. ICBW about the preferred approach
there.
BTW, if you're using a LLM to assist with analysis please don't just
paste the output into mail. Instead make sure you understand what the
LLM is saying and write up the salient bits.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH v16 5/7] spi: pxa2xx: disable DMA for Apple MacBook8,1
2026-07-21 15:05 ` Mark Brown
@ 2026-07-21 15:26 ` Shih-Yuan Lee (FourDollars)
2026-07-21 16:09 ` Shih-Yuan Lee (FourDollars)
2026-07-21 20:28 ` Andy Shevchenko
0 siblings, 2 replies; 25+ messages in thread
From: Shih-Yuan Lee (FourDollars) @ 2026-07-21 15:26 UTC (permalink / raw)
To: Mark Brown
Cc: Lukas Wunner, Andy Shevchenko, Mika Westerberg, Daniel Mack,
Haojian Zhuang, Robert Jarzmik, linux-arm-kernel, linux-spi,
linux-kernel
On Tue, Jul 21, 2026 at 11:05 PM Mark Brown <broonie@debian.org> wrote:
>
> On Tue, Jul 21, 2026 at 10:34:20PM +0800, Shih-Yuan Lee (FourDollars) wrote:
> > On Tue, Jul 21, 2026 at 5:26 PM Shih-Yuan Lee (FourDollars)
> > > On Tue, Jul 21, 2026 at 5:18 PM Lukas Wunner <lukas@wunner.de> wrote:
>
> > > > It would seem better to fix up the incorrect interrupt number in a quirk,
> > > > rather than disabling DMA wholesale.
>
> > > I appreciate the comment. Based on the Bugzilla feedback regarding the
> > > incorrect interrupt assignment, it seems fixing the IRQ value via a
> > > quirk is indeed a better approach than disabling DMA wholesale. While
> > > I am not certain this will resolve the issue entirely, it looks very
> > > promising. I will investigate the IRQ mis-assignment problem further.
>
> > 1. DMAR/IOMMU Validation Failure (Error -22)
> > On modern kernels with Interrupt Remapping (DMAR) enabled, overriding
> > pdev->irq to 21 causes the dw_dmac_pci driver probe to fail with
> > -EINVAL (-22) during request_irq(). This is because the
> > DMAR/IOMMU strictly validates the PCI Requester ID (source ID) against
> > the GSI mapping defined in the ACPI _PRT table. Forcing a device
> > mapped to GSI 20 (00:15.0) to register on GSI 21 triggers a
> > source ID mismatch check, which the kernel rejects.
>
> That really seems like something we ought to be able to do, though I
> think the idiom here is to patch the ACPI tables so they are correct
> rather than quirk things in C code. ICBW about the preferred approach
> there.
>
> BTW, if you're using a LLM to assist with analysis please don't just
> paste the output into mail. Instead make sure you understand what the
> LLM is saying and write up the salient bits.
Hi Mark,
You are absolutely correct. The standard idiom for correcting firmware
bugs in ACPI tables is indeed using the Initrd ACPI Table Override
mechanism (compiling a modified DSDT with corrected _PRT routing and
prepending it to the initramfs).
Actually, I was just following Lukas's suggestion to modify
drivers/dma/dw/pci.c to do a quick proof-of-concept test, and I used
an AI assistant to help me write and deploy the driver quirk code.
I have previous experience with the Initrd ACPI Table Override
mechanism, so I can definitely try that on my machine next to see if
we can get DMA working properly by aligning the PCI routing and DMAR
mapping correctly).
Also, I will keep your advice in mind regarding LLM usage, and will
make sure to write up the key points myself rather than pasting raw
output.
Thanks,
Shih-Yuan
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH v16 5/7] spi: pxa2xx: disable DMA for Apple MacBook8,1
2026-07-21 15:26 ` Shih-Yuan Lee (FourDollars)
@ 2026-07-21 16:09 ` Shih-Yuan Lee (FourDollars)
2026-07-21 20:41 ` Andy Shevchenko
2026-07-21 20:28 ` Andy Shevchenko
1 sibling, 1 reply; 25+ messages in thread
From: Shih-Yuan Lee (FourDollars) @ 2026-07-21 16:09 UTC (permalink / raw)
To: Mark Brown
Cc: Lukas Wunner, Andy Shevchenko, Mika Westerberg, Daniel Mack,
Haojian Zhuang, Robert Jarzmik, linux-arm-kernel, linux-spi,
linux-kernel
On Tue, Jul 21, 2026 at 11:26 PM Shih-Yuan Lee (FourDollars)
<fourdollars@debian.org> wrote:
>
> On Tue, Jul 21, 2026 at 11:05 PM Mark Brown <broonie@debian.org> wrote:
> >
> > On Tue, Jul 21, 2026 at 10:34:20PM +0800, Shih-Yuan Lee (FourDollars) wrote:
> > > On Tue, Jul 21, 2026 at 5:26 PM Shih-Yuan Lee (FourDollars)
> > > > On Tue, Jul 21, 2026 at 5:18 PM Lukas Wunner <lukas@wunner.de> wrote:
> >
> > > > > It would seem better to fix up the incorrect interrupt number in a quirk,
> > > > > rather than disabling DMA wholesale.
> >
> > > > I appreciate the comment. Based on the Bugzilla feedback regarding the
> > > > incorrect interrupt assignment, it seems fixing the IRQ value via a
> > > > quirk is indeed a better approach than disabling DMA wholesale. While
> > > > I am not certain this will resolve the issue entirely, it looks very
> > > > promising. I will investigate the IRQ mis-assignment problem further.
> >
> > > 1. DMAR/IOMMU Validation Failure (Error -22)
> > > On modern kernels with Interrupt Remapping (DMAR) enabled, overriding
> > > pdev->irq to 21 causes the dw_dmac_pci driver probe to fail with
> > > -EINVAL (-22) during request_irq(). This is because the
> > > DMAR/IOMMU strictly validates the PCI Requester ID (source ID) against
> > > the GSI mapping defined in the ACPI _PRT table. Forcing a device
> > > mapped to GSI 20 (00:15.0) to register on GSI 21 triggers a
> > > source ID mismatch check, which the kernel rejects.
> >
> > That really seems like something we ought to be able to do, though I
> > think the idiom here is to patch the ACPI tables so they are correct
> > rather than quirk things in C code. ICBW about the preferred approach
> > there.
> >
> > BTW, if you're using a LLM to assist with analysis please don't just
> > paste the output into mail. Instead make sure you understand what the
> > LLM is saying and write up the salient bits.
> Hi Mark,
>
> You are absolutely correct. The standard idiom for correcting firmware
> bugs in ACPI tables is indeed using the Initrd ACPI Table Override
> mechanism (compiling a modified DSDT with corrected _PRT routing and
> prepending it to the initramfs).
>
> Actually, I was just following Lukas's suggestion to modify
> drivers/dma/dw/pci.c to do a quick proof-of-concept test, and I used
> an AI assistant to help me write and deploy the driver quirk code.
>
> I have previous experience with the Initrd ACPI Table Override
> mechanism, so I can definitely try that on my machine next to see if
> we can get DMA working properly by aligning the PCI routing and DMAR
> mapping correctly).
>
> Also, I will keep your advice in mind regarding LLM usage, and will
> make sure to write up the key points myself rather than pasting raw
> output.
Hi Mark,
I just tested the Initrd ACPI Table Override on the machine. Here is
what I found.
I patched the _PRT table in the DSDT to remap device 00:15.0 (Pin 0
and Pin 1) from GSI 20 to GSI 21 to match the SPI controller's
interrupt line, bumped the OEM Revision from 0x00080001 to 0x00080002
so the kernel would accept the override, and prepended it to the
initramfs.
The override was successfully applied:
ACPI: Table Upgrade: override [DSDT-APPLE - MacBook]
ACPI: DSDT ... 007EB5 (v03 APPLE MacBook 00080002 INTL 20251212)
After rebooting, the DMA controller loaded without errors and both
dw:dmac168 and the SPI controller 0000:00:15.4 now correctly share IRQ
21:
21: 0 0 0 0 IR-IO-APIC 21-fasteoi dw:dmac168, 0000:00:15.4
However, SPI transfers still timed out with -ETIMEDOUT (-110) and the
IRQ 21 counter remained at zero — no interrupts were actually received
from the DMA hardware, despite the corrected ACPI routing.
This confirms the root cause is not a software IRQ routing issue but
rather that the DMA controller's interrupt line is physically
non-functional on this motherboard. macOS also does not use DMA for
this device, which is consistent with that conclusion.
It is also worth noting that Apple may have intentionally mapped the
DMA controller to GSI 20 — an otherwise unused interrupt — precisely
because the interrupt line is not physically connected. On macOS and
Windows, no DMA driver is ever loaded for this device, so the bogus
GSI 20 entry is harmless. It effectively acts as a silent signal to
the OS that interrupt-driven DMA should not be used on this platform.
Since the DMA interrupt line is physically unconnected, no completion
interrupt ever fires, causing all SPI transfers to time out with
-ETIMEDOUT (-110) and ultimately deadlocking the applespi driver.
Therefore, forcing PIO mode via a DMI quirk in spi-pxa2xx-pci remains
the only viable out-of-the-box solution for this platform.
Thanks,
Shih-Yuan
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH v16 5/7] spi: pxa2xx: disable DMA for Apple MacBook8,1
2026-07-21 16:09 ` Shih-Yuan Lee (FourDollars)
@ 2026-07-21 20:41 ` Andy Shevchenko
0 siblings, 0 replies; 25+ messages in thread
From: Andy Shevchenko @ 2026-07-21 20:41 UTC (permalink / raw)
To: Shih-Yuan Lee (FourDollars)
Cc: Mark Brown, Lukas Wunner, Mika Westerberg, Daniel Mack,
Haojian Zhuang, Robert Jarzmik, linux-arm-kernel, linux-spi,
linux-kernel
On Wed, Jul 22, 2026 at 12:09:44AM +0800, Shih-Yuan Lee (FourDollars) wrote:
> On Tue, Jul 21, 2026 at 11:26 PM Shih-Yuan Lee (FourDollars)
> <fourdollars@debian.org> wrote:
> I just tested the Initrd ACPI Table Override on the machine. Here is
> what I found.
>
> I patched the _PRT table in the DSDT to remap device 00:15.0 (Pin 0
> and Pin 1) from GSI 20 to GSI 21 to match the SPI controller's
> interrupt line,
I'm lost here. Why SPI controller and DMA controller has to share an interrupt
line?
> umped the OEM Revision from 0x00080001 to 0x00080002
> so the kernel would accept the override, and prepended it to the
> initramfs.
>
> The override was successfully applied:
>
> ACPI: Table Upgrade: override [DSDT-APPLE - MacBook]
> ACPI: DSDT ... 007EB5 (v03 APPLE MacBook 00080002 INTL 20251212)
>
> After rebooting, the DMA controller loaded without errors and both
> dw:dmac168 and the SPI controller 0000:00:15.4 now correctly share IRQ
> 21:
>
> 21: 0 0 0 0 IR-IO-APIC 21-fasteoi dw:dmac168, 0000:00:15.4
>
> However, SPI transfers still timed out with -ETIMEDOUT (-110) and the
> IRQ 21 counter remained at zero — no interrupts were actually received
> from the DMA hardware, despite the corrected ACPI routing.
>
> This confirms the root cause is not a software IRQ routing issue but
> rather that the DMA controller's interrupt line is physically
> non-functional on this motherboard. macOS also does not use DMA for
> this device, which is consistent with that conclusion.
>
> It is also worth noting that Apple may have intentionally mapped the
> DMA controller to GSI 20 — an otherwise unused interrupt — precisely
> because the interrupt line is not physically connected.
It's impossible. The interrupt line from DMA controller is an IOAPIC RTE that
is programmed by BIOS, there is no "physical wire" in traditional meaning.
In any case this link is done on the SoC level. Apple can't burn that out
of the die. They even can't fuse out that (of my knowledge LPSS is always
present IP, the fuse works against the full controller, not parts like
disabling interrupt message or "line").
> On macOS and
> Windows, no DMA driver is ever loaded for this device, so the bogus
> GSI 20 entry is harmless. It effectively acts as a silent signal to
> the OS that interrupt-driven DMA should not be used on this platform.
Maybe because they didn't get how it's supposed to work.
> Since the DMA interrupt line is physically unconnected, no completion
> interrupt ever fires, causing all SPI transfers to time out with
> -ETIMEDOUT (-110) and ultimately deadlocking the applespi driver.
No, this analysis is wrong. There are up to 3 interrupts that may participate
in the design: DMA controller; SPI controller; and SPI peripheral. The first
two usually use IOAPIC RTEs for the interrupts (and hence represented as
Interrupt() resources in _CRS methods on DSDT, plus CSRT for DMA), and the
last one often is GpioInt() and has nothing to do with DMA at all.
> Therefore, forcing PIO mode via a DMI quirk in spi-pxa2xx-pci remains
> the only viable out-of-the-box solution for this platform.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH v16 5/7] spi: pxa2xx: disable DMA for Apple MacBook8,1
2026-07-21 15:26 ` Shih-Yuan Lee (FourDollars)
2026-07-21 16:09 ` Shih-Yuan Lee (FourDollars)
@ 2026-07-21 20:28 ` Andy Shevchenko
1 sibling, 0 replies; 25+ messages in thread
From: Andy Shevchenko @ 2026-07-21 20:28 UTC (permalink / raw)
To: Shih-Yuan Lee (FourDollars)
Cc: Mark Brown, Lukas Wunner, Mika Westerberg, Daniel Mack,
Haojian Zhuang, Robert Jarzmik, linux-arm-kernel, linux-spi,
linux-kernel
On Tue, Jul 21, 2026 at 11:26:27PM +0800, Shih-Yuan Lee (FourDollars) wrote:
> On Tue, Jul 21, 2026 at 11:05 PM Mark Brown <broonie@debian.org> wrote:
...
> Actually, I was just following Lukas's suggestion to modify
> drivers/dma/dw/pci.c to do a quick proof-of-concept test, and I used
> an AI assistant to help me write and deploy the driver quirk code.
>
> I have previous experience with the Initrd ACPI Table Override
> mechanism, so I can definitely try that on my machine next to see if
> we can get DMA working properly by aligning the PCI routing and DMAR
> mapping correctly).
> output.
For old hardware (before Skylake) LPSS DMA interrupt line is defined in
two places: DSDT (and/or PCI) and CSRT. Changing in one might not help
as CSRT may have something different. Check drivers/dma/acpi-dma.c
acpi_dma_parse_resource_group().
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 25+ messages in thread
* [PATCH v16 6/7] spi: pxa2xx: restore LPSS private register state on S3 resume
2026-07-20 16:21 [PATCH v16 0/7] spi: pxa2xx: Fix PM and interrupt issues on Intel LPSS SPI Shih-Yuan Lee
` (4 preceding siblings ...)
2026-07-20 16:21 ` [PATCH v16 5/7] spi: pxa2xx: disable DMA for Apple MacBook8,1 Shih-Yuan Lee
@ 2026-07-20 16:21 ` Shih-Yuan Lee
2026-07-20 19:59 ` Andy Shevchenko
2026-07-20 16:21 ` [PATCH v16 7/7] spi: pxa2xx: rename local status variable to ret Shih-Yuan Lee
6 siblings, 1 reply; 25+ messages in thread
From: Shih-Yuan Lee @ 2026-07-20 16:21 UTC (permalink / raw)
To: Mark Brown
Cc: Andy Shevchenko, Mika Westerberg, Lukas Wunner, Daniel Mack,
Haojian Zhuang, Robert Jarzmik, linux-arm-kernel, linux-spi,
linux-kernel, Shih-Yuan Lee
Intel LPSS SPI controllers lose all private register state across S3
suspend because the LPSS power domain is fully removed. On resume the
driver only re-enables the SSP clock, leaving the LPSS private registers
in their power-on-reset state, which causes two problems:
1. LPSS_PRIV_RESETS (offset 0x04 within the LPSS private space) stays
zero, keeping the functional block in reset. Any MMIO access while
the block is held in reset causes a PCIe Completion Timeout and a
watchdog-triggered system reset. LPSS_PRIV_RESETS_FUNC and
LPSS_PRIV_RESETS_IDMA must be de-asserted before any other register
access on resume.
2. The LPSS software chip-select control register must not be blindly
restored from its suspend-time snapshot: if CS was asserted at the
moment of suspend, restoring that state corrupts the first
post-resume SPI transaction. Instead, call lpss_ssp_setup() which
unconditionally writes SW_MODE | CS_HIGH (idle/deasserted), matching
the state established at probe time.
To resolve these issues safely:
- Wrap S3 suspend/resume with pm_runtime_resume_and_get() and
pm_runtime_put_noidle() to guarantee active clocks during MMIO
access and preserve PM reference counting.
- Restrict LPSS private register save/restore to LPT, BYT, and BSW
platforms via pxa2xx_spi_need_lpss_restore() (newer platforms are
handled by intel-lpss.c).
- Save only the first 6 LPSS private registers (offsets 0x00..0x14) in
drv_data during suspend, avoiding reserved offsets beyond 0x14.
- On resume, de-assert resets first, restore saved registers, call
lpss_ssp_setup(), and clear drv_data->suspended to prevent unclocked
IRQ access.
- Add error recovery paths for spi_controller_suspend/resume failures.
- On the resume error path, call pm_runtime_set_suspended() before
pm_runtime_put_noidle() to align the PM runtime state with the
already-disabled hardware clock, preventing pxa2xx_spi_runtime_suspend()
from attempting unclocked MMIO via pxa2xx_spi_off().
Link: https://bugzilla.kernel.org/show_bug.cgi?id=108331
Signed-off-by: Shih-Yuan Lee <fourdollars@debian.org>
---
drivers/spi/spi-pxa2xx.c | 105 +++++++++++++++++++++++++++++++++++++--
drivers/spi/spi-pxa2xx.h | 1 +
2 files changed, 102 insertions(+), 4 deletions(-)
diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index 34241a6742eb..851626ead25e 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -72,6 +72,11 @@ struct chip_data {
#define LPSS_CAPS_CS_EN_SHIFT 9
#define LPSS_CAPS_CS_EN_MASK (0xf << LPSS_CAPS_CS_EN_SHIFT)
+/* Offsets from drv_data->lpss_base */
+#define LPSS_PRIV_RESETS 0x04
+#define LPSS_PRIV_RESETS_IDMA BIT(2)
+#define LPSS_PRIV_RESETS_FUNC 0x3
+
#define LPSS_PRIV_CLOCK_GATE 0x38
#define LPSS_PRIV_CLOCK_GATE_CLK_CTL_MASK 0x3
#define LPSS_PRIV_CLOCK_GATE_CLK_CTL_FORCE_ON 0x3
@@ -189,6 +194,18 @@ static bool is_lpss_ssp(const struct driver_data *drv_data)
}
}
+static bool pxa2xx_spi_need_lpss_restore(const struct driver_data *drv_data)
+{
+ switch (drv_data->ssp_type) {
+ case LPSS_LPT_SSP:
+ case LPSS_BYT_SSP:
+ case LPSS_BSW_SSP:
+ return true;
+ default:
+ return false;
+ }
+}
+
static bool is_quark_x1000_ssp(const struct driver_data *drv_data)
{
return drv_data->ssp_type == QUARK_X1000_SSP;
@@ -1532,17 +1549,44 @@ static int pxa2xx_spi_suspend(struct device *dev)
struct ssp_device *ssp = drv_data->ssp;
int status;
+ status = pm_runtime_resume_and_get(dev);
+ if (status < 0)
+ return status;
+
+
status = spi_controller_suspend(drv_data->controller);
if (status)
- return status;
+ goto out_put;
+ /* Disable SSP interrupt generation on hardware level while clock is active */
drv_data->suspended = true;
pxa2xx_spi_off(drv_data);
synchronize_irq(ssp->irq);
+ if (pxa2xx_spi_need_lpss_restore(drv_data)) {
+ unsigned int i;
+
+ /*
+ * Save the first 6 LPSS private registers (offsets 0x00 to 0x14)
+ * while the clock is still enabled. They are lost when the LPSS
+ * power domain is removed across S3 and must be restored on resume.
+ * Use drv_data->lpss_base so the correct per-platform offset
+ * is applied regardless of LPSS IP revision.
+ * Registers beyond 0x14 (except CS control at 0x18) are reserved
+ * or unimplemented on LPT, and accessing them triggers a PCIe
+ * Completion Timeout causing a system halt.
+ */
+ for (i = 0; i < 6; i++)
+ drv_data->lpss_priv_ctx[i] = readl(drv_data->lpss_base + i * 4);
+ }
+
pxa2xx_spi_clk_disable(drv_data);
return 0;
+
+out_put:
+ pm_runtime_put_noidle(dev);
+ return status;
}
static int pxa2xx_spi_resume(struct device *dev)
@@ -1555,9 +1599,47 @@ static int pxa2xx_spi_resume(struct device *dev)
if (!pm_runtime_suspended(dev)) {
status = pxa2xx_spi_clk_enable(drv_data);
if (status)
- return status;
+ goto out_put;
}
+ if (pxa2xx_spi_need_lpss_restore(drv_data)) {
+ unsigned int i;
+
+ /*
+ * The LPSS power domain is removed across S3, taking
+ * all private registers with it. De-assert the
+ * functional block and IDMA resets first; any MMIO
+ * access while the block is held in reset causes a
+ * PCIe Completion Timeout and a watchdog-triggered
+ * system reset.
+ */
+ writel(LPSS_PRIV_RESETS_FUNC | LPSS_PRIV_RESETS_IDMA,
+ drv_data->lpss_base + LPSS_PRIV_RESETS);
+
+ /* Restore the other 5 saved private registers */
+ for (i = 0; i < 6; i++) {
+ if (i == LPSS_PRIV_RESETS / 4)
+ continue;
+ writel(drv_data->lpss_priv_ctx[i],
+ drv_data->lpss_base + i * 4);
+ }
+ }
+
+ if (is_lpss_ssp(drv_data)) {
+ /*
+ * Re-initialise the SW chip-select control register so
+ * CS starts deasserted (SW_MODE | CS_HIGH), regardless
+ * of the state it was in at suspend time. A stale
+ * asserted CS on the first post-resume transaction
+ * corrupts the write-status response from the device.
+ */
+ lpss_ssp_setup(drv_data);
+ }
+
+ /*
+ * Now that resets are de-asserted and registers are restored,
+ * it is safe to handle interrupts.
+ */
drv_data->suspended = false;
/* Start the queue running */
@@ -1566,10 +1648,25 @@ static int pxa2xx_spi_resume(struct device *dev)
drv_data->suspended = true;
synchronize_irq(ssp->irq);
pxa2xx_spi_clk_disable(drv_data);
- return status;
+ goto out_put;
}
- return 0;
+out_put:
+ if (!pm_runtime_suspended(dev)) {
+ if (status)
+ /*
+ * Clock is already disabled on the error path; align
+ * the PM runtime state with hardware reality before
+ * releasing the reference so the PM core does not
+ * later invoke pxa2xx_spi_runtime_suspend() and attempt
+ * unclocked MMIO via pxa2xx_spi_off().
+ */
+ pm_runtime_set_suspended(dev);
+ pm_runtime_put_noidle(dev);
+ }
+
+ return status;
+
}
static int pxa2xx_spi_runtime_suspend(struct device *dev)
diff --git a/drivers/spi/spi-pxa2xx.h b/drivers/spi/spi-pxa2xx.h
index 44f37bf9c519..48169494f74e 100644
--- a/drivers/spi/spi-pxa2xx.h
+++ b/drivers/spi/spi-pxa2xx.h
@@ -71,6 +71,7 @@ struct driver_data {
irqreturn_t (*transfer_handler)(struct driver_data *drv_data);
void __iomem *lpss_base;
+ u32 lpss_priv_ctx[6];
bool suspended;
bool clk_enabled;
--
2.39.5
^ permalink raw reply related [flat|nested] 25+ messages in thread* Re: [PATCH v16 6/7] spi: pxa2xx: restore LPSS private register state on S3 resume
2026-07-20 16:21 ` [PATCH v16 6/7] spi: pxa2xx: restore LPSS private register state on S3 resume Shih-Yuan Lee
@ 2026-07-20 19:59 ` Andy Shevchenko
0 siblings, 0 replies; 25+ messages in thread
From: Andy Shevchenko @ 2026-07-20 19:59 UTC (permalink / raw)
To: Shih-Yuan Lee
Cc: Mark Brown, Mika Westerberg, Lukas Wunner, Daniel Mack,
Haojian Zhuang, Robert Jarzmik, linux-arm-kernel, linux-spi,
linux-kernel
On Tue, Jul 21, 2026 at 12:21:15AM +0800, Shih-Yuan Lee wrote:
Is this series AI-assisted?
> Intel LPSS SPI controllers lose all private register state across S3
> suspend because the LPSS power domain is fully removed. On resume the
> driver only re-enables the SSP clock, leaving the LPSS private registers
> in their power-on-reset state, which causes two problems:
>
> 1. LPSS_PRIV_RESETS (offset 0x04 within the LPSS private space) stays
> zero, keeping the functional block in reset. Any MMIO access while
> the block is held in reset causes a PCIe Completion Timeout and a
> watchdog-triggered system reset. LPSS_PRIV_RESETS_FUNC and
> LPSS_PRIV_RESETS_IDMA must be de-asserted before any other register
> access on resume.
>
> 2. The LPSS software chip-select control register must not be blindly
> restored from its suspend-time snapshot: if CS was asserted at the
> moment of suspend, restoring that state corrupts the first
> post-resume SPI transaction. Instead, call lpss_ssp_setup() which
> unconditionally writes SW_MODE | CS_HIGH (idle/deasserted), matching
> the state established at probe time.
>
> To resolve these issues safely:
> - Wrap S3 suspend/resume with pm_runtime_resume_and_get() and
> pm_runtime_put_noidle() to guarantee active clocks during MMIO
> access and preserve PM reference counting.
> - Restrict LPSS private register save/restore to LPT, BYT, and BSW
^^^^ (1)
> platforms via pxa2xx_spi_need_lpss_restore() (newer platforms are
> handled by intel-lpss.c).
> - Save only the first 6 LPSS private registers (offsets 0x00..0x14) in
> drv_data during suspend, avoiding reserved offsets beyond 0x14.
> - On resume, de-assert resets first, restore saved registers, call
> lpss_ssp_setup(), and clear drv_data->suspended to prevent unclocked
> IRQ access.
> - Add error recovery paths for spi_controller_suspend/resume failures.
> - On the resume error path, call pm_runtime_set_suspended() before
> pm_runtime_put_noidle() to align the PM runtime state with the
> already-disabled hardware clock, preventing pxa2xx_spi_runtime_suspend()
> from attempting unclocked MMIO via pxa2xx_spi_off().
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.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 25+ messages in thread
* [PATCH v16 7/7] spi: pxa2xx: rename local status variable to ret
2026-07-20 16:21 [PATCH v16 0/7] spi: pxa2xx: Fix PM and interrupt issues on Intel LPSS SPI Shih-Yuan Lee
` (5 preceding siblings ...)
2026-07-20 16:21 ` [PATCH v16 6/7] spi: pxa2xx: restore LPSS private register state on S3 resume Shih-Yuan Lee
@ 2026-07-20 16:21 ` Shih-Yuan Lee
2026-07-20 19:56 ` Andy Shevchenko
6 siblings, 1 reply; 25+ messages in thread
From: Shih-Yuan Lee @ 2026-07-20 16:21 UTC (permalink / raw)
To: Mark Brown
Cc: Andy Shevchenko, Mika Westerberg, Lukas Wunner, Daniel Mack,
Haojian Zhuang, Robert Jarzmik, linux-arm-kernel, linux-spi,
linux-kernel, Shih-Yuan Lee
Rename the return value variable name from 'status' to 'ret' in the
pxa2xx_spi_probe(), pxa2xx_spi_suspend(), pxa2xx_spi_resume(), and
pxa2xx_spi_runtime_resume() functions to conform to standard Linux kernel
coding conventions.
Signed-off-by: Shih-Yuan Lee <fourdollars@debian.org>
---
drivers/spi/spi-pxa2xx.c | 66 +++++++++++++++++++---------------------
1 file changed, 32 insertions(+), 34 deletions(-)
diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index 851626ead25e..9379aac82c7a 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -1313,7 +1313,7 @@ int pxa2xx_spi_probe(struct device *dev, struct ssp_device *ssp,
struct spi_controller *controller;
struct driver_data *drv_data;
const struct lpss_config *config;
- int status;
+ int ret;
u32 tmp;
if (platform_info->is_target)
@@ -1372,8 +1372,8 @@ int pxa2xx_spi_probe(struct device *dev, struct ssp_device *ssp,
/* Setup DMA if requested */
if (platform_info->enable_dma) {
- status = pxa2xx_spi_dma_setup(drv_data);
- if (status) {
+ ret = pxa2xx_spi_dma_setup(drv_data);
+ if (ret) {
dev_warn(dev, "no DMA channels available, using PIO\n");
platform_info->enable_dma = false;
} else {
@@ -1387,16 +1387,16 @@ int pxa2xx_spi_probe(struct device *dev, struct ssp_device *ssp,
}
/* Enable SOC clock */
- status = pxa2xx_spi_clk_enable(drv_data);
- if (status)
+ ret = pxa2xx_spi_clk_enable(drv_data);
+ if (ret)
goto out_error_dma_alloc;
drv_data->suspended = false;
- status = request_irq(ssp->irq, ssp_int, IRQF_SHARED, dev_name(dev),
+ ret = request_irq(ssp->irq, ssp_int, IRQF_SHARED, dev_name(dev),
drv_data);
- if (status < 0) {
- status = dev_err_probe(dev, status, "cannot get IRQ %d\n", ssp->irq);
+ if (ret < 0) {
+ ret = dev_err_probe(dev, ret, "cannot get IRQ %d\n", ssp->irq);
goto out_error_clock_enabled;
}
@@ -1477,23 +1477,23 @@ int pxa2xx_spi_probe(struct device *dev, struct ssp_device *ssp,
drv_data->gpiod_ready = devm_gpiod_get_optional(dev,
"ready", GPIOD_OUT_LOW);
if (IS_ERR(drv_data->gpiod_ready)) {
- status = PTR_ERR(drv_data->gpiod_ready);
+ ret = PTR_ERR(drv_data->gpiod_ready);
goto out_error_irq_alloc;
}
}
/* Register with the SPI framework */
dev_set_drvdata(dev, drv_data);
- status = spi_register_controller(controller);
- if (status) {
- dev_err_probe(dev, status, "problem registering SPI controller\n");
+ ret = spi_register_controller(controller);
+ if (ret) {
+ dev_err_probe(dev, ret, "problem registering SPI controller\n");
goto out_error_irq_alloc;
}
if (is_lpss_ssp(drv_data) && !platform_info->enable_dma)
pm_runtime_get_noresume(dev);
- return status;
+ return ret;
out_error_irq_alloc:
free_irq(ssp->irq, drv_data);
@@ -1504,7 +1504,7 @@ int pxa2xx_spi_probe(struct device *dev, struct ssp_device *ssp,
out_error_dma_alloc:
pxa2xx_spi_dma_release(drv_data);
- return status;
+ return ret;
}
EXPORT_SYMBOL_NS_GPL(pxa2xx_spi_probe, "SPI_PXA2xx");
@@ -1547,15 +1547,14 @@ static int pxa2xx_spi_suspend(struct device *dev)
{
struct driver_data *drv_data = dev_get_drvdata(dev);
struct ssp_device *ssp = drv_data->ssp;
- int status;
-
- status = pm_runtime_resume_and_get(dev);
- if (status < 0)
- return status;
+ int ret;
+ ret = pm_runtime_resume_and_get(dev);
+ if (ret < 0)
+ return ret;
- status = spi_controller_suspend(drv_data->controller);
- if (status)
+ ret = spi_controller_suspend(drv_data->controller);
+ if (ret)
goto out_put;
/* Disable SSP interrupt generation on hardware level while clock is active */
@@ -1586,19 +1585,19 @@ static int pxa2xx_spi_suspend(struct device *dev)
out_put:
pm_runtime_put_noidle(dev);
- return status;
+ return ret;
}
static int pxa2xx_spi_resume(struct device *dev)
{
struct driver_data *drv_data = dev_get_drvdata(dev);
struct ssp_device *ssp = drv_data->ssp;
- int status;
+ int ret;
/* Enable the SSP clock */
if (!pm_runtime_suspended(dev)) {
- status = pxa2xx_spi_clk_enable(drv_data);
- if (status)
+ ret = pxa2xx_spi_clk_enable(drv_data);
+ if (ret)
goto out_put;
}
@@ -1643,8 +1642,8 @@ static int pxa2xx_spi_resume(struct device *dev)
drv_data->suspended = false;
/* Start the queue running */
- status = spi_controller_resume(drv_data->controller);
- if (status) {
+ ret = spi_controller_resume(drv_data->controller);
+ if (ret) {
drv_data->suspended = true;
synchronize_irq(ssp->irq);
pxa2xx_spi_clk_disable(drv_data);
@@ -1653,7 +1652,7 @@ static int pxa2xx_spi_resume(struct device *dev)
out_put:
if (!pm_runtime_suspended(dev)) {
- if (status)
+ if (ret)
/*
* Clock is already disabled on the error path; align
* the PM runtime state with hardware reality before
@@ -1665,8 +1664,7 @@ static int pxa2xx_spi_resume(struct device *dev)
pm_runtime_put_noidle(dev);
}
- return status;
-
+ return ret;
}
static int pxa2xx_spi_runtime_suspend(struct device *dev)
@@ -1683,11 +1681,11 @@ static int pxa2xx_spi_runtime_suspend(struct device *dev)
static int pxa2xx_spi_runtime_resume(struct device *dev)
{
struct driver_data *drv_data = dev_get_drvdata(dev);
- int status;
+ int ret;
- status = pxa2xx_spi_clk_enable(drv_data);
- if (status)
- return status;
+ ret = pxa2xx_spi_clk_enable(drv_data);
+ if (ret)
+ return ret;
drv_data->suspended = false;
return 0;
--
2.39.5
^ permalink raw reply related [flat|nested] 25+ messages in thread* Re: [PATCH v16 7/7] spi: pxa2xx: rename local status variable to ret
2026-07-20 16:21 ` [PATCH v16 7/7] spi: pxa2xx: rename local status variable to ret Shih-Yuan Lee
@ 2026-07-20 19:56 ` Andy Shevchenko
0 siblings, 0 replies; 25+ messages in thread
From: Andy Shevchenko @ 2026-07-20 19:56 UTC (permalink / raw)
To: Shih-Yuan Lee
Cc: Mark Brown, Mika Westerberg, Lukas Wunner, Daniel Mack,
Haojian Zhuang, Robert Jarzmik, linux-arm-kernel, linux-spi,
linux-kernel
On Tue, Jul 21, 2026 at 12:21:16AM +0800, Shih-Yuan Lee wrote:
> Rename the return value variable name from 'status' to 'ret' in the
> pxa2xx_spi_probe(), pxa2xx_spi_suspend(), pxa2xx_spi_resume(), and
> pxa2xx_spi_runtime_resume() functions to conform to standard Linux kernel
> coding conventions.
It makes a ping-pong style of changes: Previous patches add more status uses
and moves, and so on. Instead, this patch should go before all that.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 25+ messages in thread