[PATCH v9 4/4] PCI: dwc: Support ECAM mechanism by enabling iATU 'CFG Shift Feature'

Manivannan Sadhasivam mani at kernel.org
Tue Dec 2 03:44:31 PST 2025


On Mon, Dec 01, 2025 at 04:42:42PM +0000, Maciej W. Rozycki wrote:
> On Mon, 1 Dec 2025, Manivannan Sadhasivam wrote:
> 
> > > > So it's definitely nothing specific to the parport driver, but rather a 
> > > > general issue with PCI/e port I/O not working anymore.  I do hope these 
> > > > observations will let you address the issue now.  You might be able to 
> > > > reproduce it with hardware you have available even.
> > > > 
> > > 
> > > Yes, looks like the I/O port access is not working with the CFG Shift feature.
> > > The spec says that both I/O and MEM TLPs should be handled by this feature, so
> > > we are currently unsure why MEM works, but not I/O.
> 
>  As I say, last time I checked (for another reason) documentation was not 
> available to the general public, so I can't help with that.
> 

Sure. I know that the DWC documentation is well secured behind firewalls. So not
asking for help here.

> > > The issue you reported with parport_pc driver is that the driver gets probed,
> > > but it fails to detect the parallel ports on the device. More precisely, it
> > > fails due to the parport_SPP_supported() check in drivers/parport/parport_pc.c.
> > > This function performs some read/write checks to make sure that the port exists,
> > > but most likely the read value doesn't match the written one. And since there is
> > > no log printed in this function, it just failed silently.
> 
>  Whatever the exact transaction conditions are port I/O TLPs seem not to 
> make it through to the requested target device anymore.
> 
>  FWIW the defxx driver issues a command to the device's command register 
> and wants to see a successful completion status in the status register 
> before retrieving the MAC address via the data register.  So it's not a 
> simple case of poking at a register and reading it back, but the end 
> result is the same: the device cannot be talked to.
> 
> > > We will check why I/O access fails with ECAM mode and revert back asap. Since
> > > the merge window is now open, it becomes difficult to revert the CFG shift
> > > feature cleanly. The timing of the report also made it difficult to fix the
> > > issue in v6.18. Hopefully, we can backport the fix once we identify the culprit.
> 
>  No worries, I've been around for long enough (short of 30 years) to know 
> the process.
> 
>  FWIW the original change would've best been reverted for 6.18 as a fatal 
> regression, however port I/O is uncommon enough nowadays we can defer any 
> final decision to 6.19 I suppose.  I'm glad I've tripped over this in the 
> first place as I'm not eager to upgrade all my lab devices all the time, 
> and it was owing to another issue only that I chose this moment to move 
> forward, not so long after the original commit.
> 
> > Can you try the attached patch? It is a reworked version of Krishna's patch. I
> > just moved things around to check potential override issue.
> 
>  No change in behaviour, sorry.  I suppose it's this range of host address 
> decoding:
> 
> fu740-pcie e00000000.pcie:       IO 0x0060080000..0x006008ffff -> 0x0060080000
> 
> aka:
> 
> pci_bus 0000:00: root bus resource [io  0x0000-0xffff] (bus address [0x60080000-0x6008ffff])
> 
> that you're after.  Are you sure your code discovers it correctly?  As I 
> say I can only see IORESOURCE_MEM references and no IORESOURCE_IO ones as 
> would be appropriate for the root bus resource quoted.
> 

The I/O resource is discovered by the driver correctly as seen from the logs:

pci_bus 0000:00: root bus resource [io  0x0000-0xffff] (bus address [0x60080000-0x6008ffff])
pci_bus 0000:00: root bus resource [mem 0x60090000-0x7fffffff]
pci_bus 0000:00: root bus resource [mem 0x2000000000-0x3fffffffff pref]

But we believe that the iATU is not programmed for the I/O port, resulting in
the I/O access not going out to the device.

Krishna found an issue in the previous patch that got shared. So I've attached a
new one. Could you please try and let us know? If it didn't help, please share
the dmesg log that will have some more info.

- Mani

-- 
மணிவண்ணன் சதாசிவம்
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-PCI-qcom-Enable-iATU-mapping-for-memory-IO-regions.patch
Type: text/x-diff
Size: 5931 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20251202/01cbaf27/attachment-0001.bin>


More information about the linux-arm-kernel mailing list