Re: [REGRESSION] applespi from 6.12 onwards

Re: [REGRESSION] applespi from 6.12 onwards

[Aditya Garg]

> 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: applespi spi-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: applespi spi-APP000D:00: Error writing to device: 01 0e 00 00
> 
> Many thanks,
> 
> Jörg Berkel

Ccing Lukas and IOMMU devs

Re: [REGRESSION] applespi from 6.12 onwards

[Baolu Lu]

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?

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.

Thanks,
baolu

Re: [REGRESSION] applespi from 6.12 onwards

[Dmitry Torokhov]

On Thu, May 08, 2025 at 10:15:31AM +0800, 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?
> 
> 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.

When sending a command to the peripheral device applespi expects it to
acknowledge successful transfer with

	static u8 status_ok[] = { 0xac, 0x27, 0x68, 0xd5 };

but we are getting "01 0e 00 00" instead.

See applespi_check_write_status() in drivers/input/Keyboard/applespi.c

Thanks.

-- 
Dmitry

Re: [REGRESSION] applespi from 6.12 onwards

[Aditya Garg]

>> It appears that all DMA faults are related to a fixed address,
>> 0xffffa000. Is this address something special?
>>
>> 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.
> 
> When sending a command to the peripheral device applespi expects it to
> acknowledge successful transfer with
> 
> 	static u8 status_ok[] = { 0xac, 0x27, 0x68, 0xd5 };
> 
> but we are getting "01 0e 00 00" instead.
> 
> See applespi_check_write_status() in drivers/input/Keyboard/applespi.c
> 
> Thanks.
> 

Since its working with `iommu.passthrough=1`, probably disable iommu for this hardware (if possible)?

Although there must be some other fix since it was working without passthrough before.

Re: [REGRESSION] applespi from 6.12 onwards

[Robin Murphy]

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

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

Re: [REGRESSION] applespi from 6.12 onwards

[Aditya Garg]

> On 8 May 2025, at 5:00 PM, Robin Murphy <robin.murphy@arm.com> 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...)
> 
> - 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?

Re: [REGRESSION] applespi from 6.12 onwards

[Berkel Jörg]

[-- Attachment #1: Type: text/plain, Size: 2986 bytes --]

Am 08.05.25 um 14:54 schrieb Aditya Garg:
> 
> 
>> On 8 May 2025, at 5:00 PM, Robin Murphy <robin.murphy@arm.com> 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...)
>>
>> - 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?

you'll find attached the two kernel-logfiles created using 
"systemd.log_level=debug systemd.log_target=kmsg log_buf_len=15M"

Thanks,
Jörg

[-- Attachment #2: dmesg-debug-mbp14,1.tgz --]
[-- Type: application/x-compressed-tar, Size: 181568 bytes --]

Re: [REGRESSION] applespi from 6.12 onwards

[Aditya Garg]

Hi Jörg

Can you test the kernel here to see if this fixes your issue:

https://github.com/t2linux/T2-Debian-and-Ubuntu-Kernel/actions/runs/14944200356

Alternatively you can try compiling your own kernel with this patch:

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

________________________________________
From: Berkel Jörg <joerg.berkel@bfh.ch>
Sent: 09 May 2025 20:53
To: Aditya Garg; Robin Murphy
Cc: Baolu Lu; linux-input@vger.kernel.org; dmitry.torokhov@gmail.com; stable@vger.kernel.org; regressions@lists.linux.dev; linux-spi@vger.kernel.org; lukas@wunner.de; David Woodhouse; iommu@lists.linux.dev; Joerg Roedel; Will Deacon
Subject: Re: [REGRESSION] applespi from 6.12 onwards

Am 08.05.25 um 14:54 schrieb Aditya Garg:
>
>
>> On 8 May 2025, at 5:00 PM, Robin Murphy <robin.murphy@arm.com> 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...)
>>
>> - 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?

you'll find attached the two kernel-logfiles created using
"systemd.log_level=debug systemd.log_target=kmsg log_buf_len=15M"

Thanks,
Jörg

Re: [REGRESSION] applespi from 6.12 onwards

[kobarity]

[-- Attachment #1: Type: text/plain, Size: 1132 bytes --]


Hi

I'm also experiencing this problem on my MacBookPro14,3.

Aditya Garg wrote:
> 
> Hi Jörg
> 
> Can you test the kernel here to see if this fixes your issue:
> 
> https://github.com/t2linux/T2-Debian-and-Ubuntu-Kernel/actions/runs/14944200356
> 
> Alternatively you can try compiling your own kernel with this patch:
> 
> https://lore.kernel.org/all/0-v1-c26553717e90+65f-iommu_vtd_ss_wo_jgg@nvidia.com/

As far as I have tried, this patch did not solve the problem.

By bisecting, I found that this problem was introduced by commit
2031c469f816 ("iommu/vt-d: Add support for static identity domain").
In fact, since this commit, it will panic at startup.  This panic was
fixed by commit 6e02a277f1db ("iommu/vt-d: Fix incorrect
pci_for_each_dma_alias() for non-PCI devices").  So I applied commit
6e02a277f1db on commit 2031c469f816 and confirmed that the keyboard
and touchpad is not working.

I also found that I can workaround this problem by reverting only the
intel_iommu_attach_device() change in commit 2031c469f816 as in the
attached patch, but I'm not sure if this is a reasonable fix.


[-- Attachment #2: workaround.patch --]
[-- Type: application/octet-stream, Size: 601 bytes --]

diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index cb0b993bebb4..14da33490fa1 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -3484,9 +3484,11 @@ int paging_domain_compatible(struct iommu_domain *domain, struct device *dev)
 static int intel_iommu_attach_device(struct iommu_domain *domain,
 				     struct device *dev)
 {
+	struct device_domain_info *info = dev_iommu_priv_get(dev);
 	int ret;
 
-	device_block_translation(dev);
+	if (info->domain)
+		device_block_translation(dev);
 
 	ret = paging_domain_compatible(domain, dev);
 	if (ret)

Re: [REGRESSION] applespi from 6.12 onwards

[Baolu Lu]

On 5/11/25 21:31, kobarity wrote:
> 
> Hi
> 
> I'm also experiencing this problem on my MacBookPro14,3.
> 
> Aditya Garg wrote:
>>
>> Hi Jörg
>>
>> Can you test the kernel here to see if this fixes your issue:
>>
>> https://github.com/t2linux/T2-Debian-and-Ubuntu-Kernel/actions/runs/14944200356
>>
>> Alternatively you can try compiling your own kernel with this patch:
>>
>> https://lore.kernel.org/all/0-v1-c26553717e90+65f-iommu_vtd_ss_wo_jgg@nvidia.com/
> 
> As far as I have tried, this patch did not solve the problem.
> 
> By bisecting, I found that this problem was introduced by commit
> 2031c469f816 ("iommu/vt-d: Add support for static identity domain").
> In fact, since this commit, it will panic at startup.  This panic was
> fixed by commit 6e02a277f1db ("iommu/vt-d: Fix incorrect
> pci_for_each_dma_alias() for non-PCI devices").  So I applied commit
> 6e02a277f1db on commit 2031c469f816 and confirmed that the keyboard
> and touchpad is not working.

Have you tried to apply commit 64f792981e35 ("iommu/vt-d: Remove device
comparison in context_setup_pass_through_cb")?

> 
> I also found that I can workaround this problem by reverting only the
> intel_iommu_attach_device() change in commit 2031c469f816 as in the
> attached patch, but I'm not sure if this is a reasonable fix.
> 

Thanks,
baolu

Re: [REGRESSION] applespi from 6.12 onwards

[kobarity]

Baolu Lu wrote:
> On 5/11/25 21:31, kobarity wrote:
> > 
> > Hi
> > 
> > I'm also experiencing this problem on my MacBookPro14,3.
> > 
> > Aditya Garg wrote:
> >> 
> >> Hi Jörg
> >> 
> >> Can you test the kernel here to see if this fixes your issue:
> >> 
> >> https://github.com/t2linux/T2-Debian-and-Ubuntu-Kernel/actions/runs/14944200356
> >> 
> >> Alternatively you can try compiling your own kernel with this patch:
> >> 
> >> https://lore.kernel.org/all/0-v1-c26553717e90+65f-iommu_vtd_ss_wo_jgg@nvidia.com/
> > 
> > As far as I have tried, this patch did not solve the problem.
> > 
> > By bisecting, I found that this problem was introduced by commit
> > 2031c469f816 ("iommu/vt-d: Add support for static identity domain").
> > In fact, since this commit, it will panic at startup.  This panic was
> > fixed by commit 6e02a277f1db ("iommu/vt-d: Fix incorrect
> > pci_for_each_dma_alias() for non-PCI devices").  So I applied commit
> > 6e02a277f1db on commit 2031c469f816 and confirmed that the keyboard
> > and touchpad is not working.
> 
> Have you tried to apply commit 64f792981e35 ("iommu/vt-d: Remove device
> comparison in context_setup_pass_through_cb")?

Yes, I tried it on yesterday's master branch, including commit
64f792981e35.

- Keyboard/Touchpad NOT working:
  - No patches
  - With patch in https://lore.kernel.org/all/0-v1-c26553717e90+65f-iommu_vtd_ss_wo_jgg@nvidia.com/
- Keyboard/Touchpad working:
  - With my workaround patch

Re: [REGRESSION] applespi from 6.12 onwards

[Baolu Lu]

[-- Attachment #1: Type: text/plain, Size: 3251 bytes --]

On 5/12/25 20:16, kobarity wrote:
> Baolu Lu wrote:
>> On 5/11/25 21:31, kobarity wrote:
>>>
>>> Hi
>>>
>>> I'm also experiencing this problem on my MacBookPro14,3.
>>>
>>> Aditya Garg wrote:
>>>>
>>>> Hi Jörg
>>>>
>>>> Can you test the kernel here to see if this fixes your issue:
>>>>
>>>> https://github.com/t2linux/T2-Debian-and-Ubuntu-Kernel/actions/runs/14944200356
>>>>
>>>> Alternatively you can try compiling your own kernel with this patch:
>>>>
>>>> https://lore.kernel.org/all/0-v1-c26553717e90+65f-iommu_vtd_ss_wo_jgg@nvidia.com/
>>>
>>> As far as I have tried, this patch did not solve the problem.
>>>
>>> By bisecting, I found that this problem was introduced by commit
>>> 2031c469f816 ("iommu/vt-d: Add support for static identity domain").
>>> In fact, since this commit, it will panic at startup.  This panic was
>>> fixed by commit 6e02a277f1db ("iommu/vt-d: Fix incorrect
>>> pci_for_each_dma_alias() for non-PCI devices").  So I applied commit
>>> 6e02a277f1db on commit 2031c469f816 and confirmed that the keyboard
>>> and touchpad is not working.
>>
>> Have you tried to apply commit 64f792981e35 ("iommu/vt-d: Remove device
>> comparison in context_setup_pass_through_cb")?
> 
> Yes, I tried it on yesterday's master branch, including commit
> 64f792981e35.
> 
> - Keyboard/Touchpad NOT working:
>    - No patches
>    - With patch in https://lore.kernel.org/all/0-v1-c26553717e90+65f-iommu_vtd_ss_wo_jgg@nvidia.com/
> - Keyboard/Touchpad working:
>    - With my workaround patch

Okay, thanks! Can you please try below change? I also attached a diff
file in the attachment for your convenience.

diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index 49530d5d8c85..9a86ead8377d 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -1832,6 +1832,8 @@ static int dmar_domain_attach_device(struct 
dmar_domain *domain,
         if (ret)
                 goto out_block_translation;

+       info->domain_attached = true;
+
         return 0;

  out_block_translation:
@@ -3206,6 +3208,10 @@ void device_block_translation(struct device *dev)
         struct intel_iommu *iommu = info->iommu;
         unsigned long flags;

+       /* Device in DMA blocking state. Noting to do. */
+       if (!info->domain_attached)
+               return;
+
         if (info->domain)
                 cache_tag_unassign_domain(info->domain, dev, 
IOMMU_NO_PASID);

@@ -4302,6 +4308,9 @@ static int identity_domain_attach_dev(struct 
iommu_domain *domain, struct device
         else
                 ret = device_setup_pass_through(dev);

+       if (!ret)
+               info->domain_attached = true;
+
         return ret;
  }

diff --git a/drivers/iommu/intel/iommu.h b/drivers/iommu/intel/iommu.h
index cbfb8bb4c94a..3ddbcc603de2 100644
--- a/drivers/iommu/intel/iommu.h
+++ b/drivers/iommu/intel/iommu.h
@@ -774,6 +774,7 @@ struct device_domain_info {
         u8 ats_supported:1;
         u8 ats_enabled:1;
         u8 dtlb_extra_inval:1;  /* Quirk for devices need extra flush */
+       u8 domain_attached:1;   /* Device has domain attached */
         u8 ats_qdep;
         unsigned int iopf_refcount;
         struct device *dev; /* it's NULL for PCIe-to-PCI bridge */

Thanks,
baolu

[-- Attachment #2: diff.patch --]
[-- Type: text/x-patch, Size: 1422 bytes --]

diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index 49530d5d8c85..9a86ead8377d 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -1832,6 +1832,8 @@ static int dmar_domain_attach_device(struct dmar_domain *domain,
 	if (ret)
 		goto out_block_translation;
 
+	info->domain_attached = true;
+
 	return 0;
 
 out_block_translation:
@@ -3206,6 +3208,10 @@ void device_block_translation(struct device *dev)
 	struct intel_iommu *iommu = info->iommu;
 	unsigned long flags;
 
+	/* Device in DMA blocking state. Noting to do. */
+	if (!info->domain_attached)
+		return;
+
 	if (info->domain)
 		cache_tag_unassign_domain(info->domain, dev, IOMMU_NO_PASID);
 
@@ -4302,6 +4308,9 @@ static int identity_domain_attach_dev(struct iommu_domain *domain, struct device
 	else
 		ret = device_setup_pass_through(dev);
 
+	if (!ret)
+		info->domain_attached = true;
+
 	return ret;
 }
 
diff --git a/drivers/iommu/intel/iommu.h b/drivers/iommu/intel/iommu.h
index cbfb8bb4c94a..3ddbcc603de2 100644
--- a/drivers/iommu/intel/iommu.h
+++ b/drivers/iommu/intel/iommu.h
@@ -774,6 +774,7 @@ struct device_domain_info {
 	u8 ats_supported:1;
 	u8 ats_enabled:1;
 	u8 dtlb_extra_inval:1;	/* Quirk for devices need extra flush */
+	u8 domain_attached:1;	/* Device has domain attached */
 	u8 ats_qdep;
 	unsigned int iopf_refcount;
 	struct device *dev; /* it's NULL for PCIe-to-PCI bridge */

Re: [REGRESSION] applespi from 6.12 onwards

[kobarity]

Baolu Lu wrote:
> On 5/12/25 20:16, kobarity wrote:
> > Baolu Lu wrote:
> >> On 5/11/25 21:31, kobarity wrote:
> >>> 
> >>> Hi
> >>> 
> >>> I'm also experiencing this problem on my MacBookPro14,3.
> >>> 
> >>> Aditya Garg wrote:
> >>>> 
> >>>> Hi Jörg
> >>>> 
> >>>> Can you test the kernel here to see if this fixes your issue:
> >>>> 
> >>>> https://github.com/t2linux/T2-Debian-and-Ubuntu-Kernel/actions/runs/14944200356
> >>>> 
> >>>> Alternatively you can try compiling your own kernel with this patch:
> >>>> 
> >>>> https://lore.kernel.org/all/0-v1-c26553717e90+65f-iommu_vtd_ss_wo_jgg@nvidia.com/
> >>> 
> >>> As far as I have tried, this patch did not solve the problem.
> >>> 
> >>> By bisecting, I found that this problem was introduced by commit
> >>> 2031c469f816 ("iommu/vt-d: Add support for static identity domain").
> >>> In fact, since this commit, it will panic at startup.  This panic was
> >>> fixed by commit 6e02a277f1db ("iommu/vt-d: Fix incorrect
> >>> pci_for_each_dma_alias() for non-PCI devices").  So I applied commit
> >>> 6e02a277f1db on commit 2031c469f816 and confirmed that the keyboard
> >>> and touchpad is not working.
> >> 
> >> Have you tried to apply commit 64f792981e35 ("iommu/vt-d: Remove device
> >> comparison in context_setup_pass_through_cb")?
> > 
> > Yes, I tried it on yesterday's master branch, including commit
> > 64f792981e35.
> > 
> > - Keyboard/Touchpad NOT working:
> >    - No patches
> >    - With patch in https://lore.kernel.org/all/0-v1-c26553717e90+65f-iommu_vtd_ss_wo_jgg@nvidia.com/
> > - Keyboard/Touchpad working:
> >    - With my workaround patch
> 
> Okay, thanks! Can you please try below change? I also attached a diff
> file in the attachment for your convenience.

Thanks!  The keyboard and touchpad now work with this patch.  I tested
it with the same master branch as before (commit 3ce9925823c7).

Re: [REGRESSION] applespi from 6.12 onwards

[Baolu Lu]

On 5/13/25 20:08, kobarity wrote:
> Baolu Lu wrote:
>> On 5/12/25 20:16, kobarity wrote:
>>> Baolu Lu wrote:
>>>> On 5/11/25 21:31, kobarity wrote:
>>>>>
>>>>> Hi
>>>>>
>>>>> I'm also experiencing this problem on my MacBookPro14,3.
>>>>>
>>>>> Aditya Garg wrote:
>>>>>>
>>>>>> Hi Jörg
>>>>>>
>>>>>> Can you test the kernel here to see if this fixes your issue:
>>>>>>
>>>>>> https://github.com/t2linux/T2-Debian-and-Ubuntu-Kernel/actions/runs/14944200356
>>>>>>
>>>>>> Alternatively you can try compiling your own kernel with this patch:
>>>>>>
>>>>>> https://lore.kernel.org/all/0-v1-c26553717e90+65f-iommu_vtd_ss_wo_jgg@nvidia.com/
>>>>>
>>>>> As far as I have tried, this patch did not solve the problem.
>>>>>
>>>>> By bisecting, I found that this problem was introduced by commit
>>>>> 2031c469f816 ("iommu/vt-d: Add support for static identity domain").
>>>>> In fact, since this commit, it will panic at startup.  This panic was
>>>>> fixed by commit 6e02a277f1db ("iommu/vt-d: Fix incorrect
>>>>> pci_for_each_dma_alias() for non-PCI devices").  So I applied commit
>>>>> 6e02a277f1db on commit 2031c469f816 and confirmed that the keyboard
>>>>> and touchpad is not working.
>>>>
>>>> Have you tried to apply commit 64f792981e35 ("iommu/vt-d: Remove device
>>>> comparison in context_setup_pass_through_cb")?
>>>
>>> Yes, I tried it on yesterday's master branch, including commit
>>> 64f792981e35.
>>>
>>> - Keyboard/Touchpad NOT working:
>>>     - No patches
>>>     - With patch in https://lore.kernel.org/all/0-v1-c26553717e90+65f-iommu_vtd_ss_wo_jgg@nvidia.com/
>>> - Keyboard/Touchpad working:
>>>     - With my workaround patch
>>
>> Okay, thanks! Can you please try below change? I also attached a diff
>> file in the attachment for your convenience.
> 
> Thanks!  The keyboard and touchpad now work with this patch.  I tested
> it with the same master branch as before (commit 3ce9925823c7).
> 

Okay, thanks! Let me post a formal fix patch for this.

Thanks,
baolu

Re: [REGRESSION] applespi from 6.12 onwards

[Baolu Lu]

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