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

[Shih-Yuan Lee (FourDollars)]

On Tue, Jul 21, 2026 at 11:26 PM Shih-Yuan Lee (FourDollars)
<fourdollars@xxxxxxxxxx> wrote:
>
> On Tue, Jul 21, 2026 at 11:05 PM Mark Brown <broonie@xxxxxxxxxx> 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@xxxxxxxxx> 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