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

On 5/8/25 01:07, Aditya Garg wrote:

quoted

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.

Also what does below message mean from a SPI driver's perspective?

"applespispi-APP000D:00: Error writing to device: 01 0e 00 00"

I am asking this because the IOMMU fault messages are about DMA Reads
(device raised memory read), while above message complains failing to
write to device.

AFAICS it's a "write" at the SPI level, i.e. the SPI controller is 
sending data *to* the SPI device (the keyboard), so at the PCI/platform 
level the controller itself is fetching that data *from* memory.

Thanks,
Robin.