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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ps5jjiqv5mw2g3exzvfcfsa4bcda7hois2h6riarwb2d2son4u@2onu4bibw2hb>
Date: Tue, 2 Dec 2025 17:14:31 +0530
From: Manivannan Sadhasivam <mani@...nel.org>
To: "Maciej W. Rozycki" <macro@...am.me.uk>
Cc: Krishna Chaitanya Chundru <krishna.chundru@....qualcomm.com>, 
	Jingoo Han <jingoohan1@...il.com>, Lorenzo Pieralisi <lpieralisi@...nel.org>, 
	Krzysztof Wilczyński <kwilczynski@...nel.org>, Rob Herring <robh@...nel.org>, 
	Bjorn Helgaas <bhelgaas@...gle.com>, Krzysztof Kozlowski <krzk@...nel.org>, 
	Alim Akhtar <alim.akhtar@...sung.com>, Jonathan Chocron <jonnyc@...zon.com>, linux-pci@...r.kernel.org, 
	linux-arm-kernel@...ts.infradead.org, linux-samsung-soc@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH v9 4/4] PCI: dwc: Support ECAM mechanism by enabling iATU
 'CFG Shift Feature'

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

-- 
மணிவண்ணன் சதாசிவம்

View attachment "0001-PCI-qcom-Enable-iATU-mapping-for-memory-IO-regions.patch" of type "text/x-diff" (5932 bytes)