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

[Andy Shevchenko]

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@xxxxxxxxxx> 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