Re: [REGRESSION] applespi from 6.12 onwards

[Baolu Lu <baolu.lu@linux.intel.com>]

On 5/8/25 19:29, Robin Murphy wrote:
> On 2025-05-08 3:15 am, Baolu Lu wrote:
>> 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...)

Intel 2nd-stage page table format allows write-only permission. But
commit eea53c581688 ("iommu/vt-d: Remove WO permissions on second-level
paging entries") has already removed it, and v6.12 kernel contains this
commit.

By the way, we are about to restore the write-only permission on 2nd-
stage page table,

https://lore.kernel.org/all/0-v1-c26553717e90+65f-iommu_vtd_ss_wo_jgg@nvidia.com/

... if the device driver provides only DMA_FROM_DEVICE and the iommu
driver uses 2nd-stage page table for its dma translation.

The iommu driver currently treats DMA_FROM_DEVICE as a hint rather than
a mandatory requirement. If we want to enforce write-only permission in
the future, we should allocate a domain allocation flag so that the
iommu driver could have the opportunity to select the appropriate page
table format.

> 
> - 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.

Yes. DMA mapping trace messages would shed more lights.

Thanks,
baolu