Force SPI PIO on MacBook8,1 so the built-in keyboard works

[jeissonneira]

Summary

On MacBook8,1 (12-inch Early 2015) the installer already loads applespi and the PXA SPI modules. That is not enough. The GSPI controller (00:15.4) does transfers through the companion DesignWare DMA engine (00:15.0), and on this board those DMA transfers never complete. applespi times out with -110, IRQ 21 stays at zero, and the built-in keyboard and trackpad never work. #1954.

Force the controller into PIO and it probes immediately. dw_dmac_pci is builtin, so the switch is a kernel parameter:

initcall_blacklist=dw_pci_driver_init

Deep/S3 then wedges the same SPI device until reboot, so sleep defaults to s2idle.

Same shape as the ASUS Panther Lake backlight leaf: detect the machine, write a Limine drop-in. No new package. No vendored C.

Changes

• install/hardware/apple/fix-spi-keyboard.sh — on MacBook8,1 only, write /etc/limine-entry-tool.d/macbook81-spi-pio.conf. Other SPI MacBooks are unchanged.
• Migration 1788318101.sh for existing installs. Idempotent. Rebuilds the UKI. No-ops on anything that is not MacBook8,1.
• test/shell.d/macbook81-spi-pio-test.sh
• Manual note: USB keyboard for the installer itself; glass keys after the first reboot.

Tested

MacBook8,1 (A1534, Early 2015), Core M-5Y31, Omarchy 4.0.2, kernel 7.1.9-arch1-2. Keyboard and trackpad work at LUKS, at the login screen, and after lid close.

The same PIO cmdline is what matthiasjg documented on #1954; the original reporter and two other MacBook8,1s confirmed it.

Speakers, camera, and Bluetooth stay out of this PR.

Fixes #1954

[Jackwwg83]

Independent confirmation on a second MacBook8,1, plus some register-level measurements of why the DMA path is dead — in case they help the review or the upstream quirk.

Setup: MacBook8,1 (A1534), Omarchy 4.0.0.alpha, kernel 7.1.9-arch1-2, limine UKI, LUKS root. Applied initcall_blacklist=dw_pci_driver_init (via /etc/default/limine, before seeing this PR).

Result after cold boot: pxa2xx_spi_pci 0000:00:15.4: no DMA channels available, using PIO → applespi … modeswitch done. at t=1.4 s; keyboard and trackpad registered; touchpad_dimensions=-5087x-182+10666+6271; 0 timeouts; idle IRQ 21 rate 0/s, CPU 97% idle. Internal keyboard works at the LUKS prompt. The same switch at runtime (unbind dw_dmac_pci → rebind pxa2xx_spi_pci) flips the machine between "-110 every 200 ms, no touchpad" and "works" deterministically, in both directions.

What the failure looks like at the register level (driver bound, applespi retrying, read from a small probe module):

• SSCR1 = 0x00701dc0 → TSRE|RSRE|TRAIL set, TIE|RIE clear (DMA mode). SSSR = 0x0000f024 → TFS=1, TFL=0, BSY=0. The controller is asserting its TX DMA request and nothing ever moves — the DesignWare engine never services the request at all, rather than starting a transfer that doesn't finish.
• The SSP and its IRQ path are fine: with the driver unbound, driving SSCR0/SSCR1/SSDR by hand clocks data out (FIFO drains, RX fills), and setting TIE asserts PCI INTx (STATUS bit 3). A sniffer request_irq()'d on GSI 16–23 caught that interrupt on GSI 21 (100k+ hits in 2 s). So IRQ routing, IOMMU, interrupt remapping, PWM_LPSS etc. are not involved. intel_iommu=off was also tested: no effect.
• One more firmware inconsistency worth knowing: ACPI _PRT gives the DMA engine (00:15.0, INTB) GSI 20, but the PCH routing register D21IR = 0x5554 routes INTB → PIRQF = GSI 21. Linux waits for dw_dmac completions on IRQ 20; this board would deliver them on 21. So even if DMA moved data, its completion interrupt could never reach the driver here.

Upstream is converging on the same answer: fourdollars' series "spi: pxa2xx: MacBook8,1 quirk, runtime PM, and LPSS S3 resume state fixes" (v14, 2026-07-18) adds the DMI quirk in-kernel. Until that reaches Arch's linux, the initcall blacklist in this PR is the right shape. +1 on mem_sleep_default=s2idle too — this box defaults to [deep].