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] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.21.2512011617250.49654@angie.orcam.me.uk>
Date: Mon, 1 Dec 2025 16:42:42 +0000 (GMT)
From: "Maciej W. Rozycki" <macro@...am.me.uk>
To: Manivannan Sadhasivam <mani@...nel.org>
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, 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.

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

  Maciej