Re: [PATCH v16 5/7] spi: pxa2xx: disable DMA for Apple MacBook8,1

[Shih-Yuan Lee (FourDollars)]

On Tue, Jul 21, 2026 at 5:26 PM Shih-Yuan Lee (FourDollars)
<fourdollars@xxxxxxxxxx> wrote:
>
> On Tue, Jul 21, 2026 at 5:18 PM Lukas Wunner <lukas@xxxxxxxxx> 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