On 8 May 2025, at 5:00 PM, Robin Murphy [off-list ref] wrote:

On 2025-05-08 3:15 am, Baolu Lu wrote:

quoted

quoted

On 5/8/25 01:07, Aditya Garg wrote:
Keyboard and touchpad stopped working on several Apple Macbooks from the year 2017 using kernel 6.12.xx . Until now I could only find this discussion affirming the bug on Debian and Fedora:https://github.com/ Dunedan/mbp-2016-linux/issues/202

On siduction I also tried the more recent kernels 6.14.5 and mainline 6.15-rc4 (from Ubuntu) and the issue persisted with my testdevice MacBookPro14,1 -- see the relevant output:

kernel: platform pxa2xx-spi.3: Adding to iommu group 20
kernel: input: Apple SPI Keyboard as /devices/pci0000:00/0000:00:1e.3/ pxa2xx-spi.3/spi_master/spi2/spi-APP000D:00/ input/input0
kernel: DMAR: DRHD: handling fault status reg 3
kernel: DMAR: [DMA Read NO_PASID] Request device [00:1e.3] fault addr 0xffffa000 [fault reason 0x06] PTE Read access is not set
kernel: DMAR: DRHD: handling fault status reg 3
kernel: DMAR: [DMA Read NO_PASID] Request device [00:1e.3] fault addr 0xffffa000 [fault reason 0x06] PTE Read access is not set
kernel: applespispi-APP000D:00: Error writing to device: 01 0e 00 00
kernel: DMAR: DRHD: handling fault status reg 3
kernel: DMAR: [DMA Read NO_PASID] Request device [00:1e.3] fault addr 0xffffa000 [fault reason 0x06] PTE Read access is not set
kernel: DMAR: DRHD: handling fault status reg 3
kernel: applespispi-APP000D:00: Error writing to device: 01 0e 00 00

It appears that all DMA faults are related to a fixed address,
0xffffa000. Is this address something special?

Maybe it's retrying the same buffer a few times before finally giving up? The address does look like a plausible iommu-dma IOVA, so I can imagine at least two possibilities where a change in the IOMMU driver might have an impact:

- It's the right address in the right context but incorrectly mapped as DMA_FROM_DEVICE, where that previously had implicit read permission as well but is now write-only (can the Intel 2nd-stage format do that like Arm does? I forget...)

- It's the right address in the wrong context, because the DMA mapping was done with the wrong device, which was previously in the same IOMMU group as 00:1e.3, but now we assign groups differently. I don't know if lpss_spi_setup() is relevant to this particular hardware setup, but "dma_dev = pci_get_slot(dev->bus, PCI_DEVFN(PCI_SLOT(dev->devfn), 0));" there certainly catches my attention, at least.

The DMA mapping tracepoints should be able to shed light on how that address is mapped prior to the fault.

A full dmesg with debug log level should be nice to have imo.

Jörg can you do that for both 6.11 and 6.12?