Message-ID: <syg7vpbt3w53s24hgl7b6w64odmif5bq557lwlvzlbvgkukwcn@66jtzzc3vtiu>
Date: Mon, 1 Dec 2025 20:08:12 +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 05:21:50PM +0530, Manivannan Sadhasivam wrote:
> On Sat, Nov 29, 2025 at 06:04:24AM +0000, Maciej W. Rozycki wrote:
> > On Sat, 29 Nov 2025, Krishna Chaitanya Chundru wrote:
> > 
> > > > > Hi Maciej, Can you try attached patch and let me know if that is helping
> > > > > you
> > > > > or not. - Krishna Chaitanya.
> > > >   No change, it's still broken, sorry.
> > > HI Maciej,
> > > For the previous patch can you apply this diff and share me dmesg o/p
> > 
> >  Your patch came though garbled, likely due to:
> > 
> > Content-Type: text/plain; charset=UTF-8; format=flowed
> > 
> > Please refer Documentation/process/email-clients.rst and reconfigure your 
> > e-mail client if possible.
> > 
> >  Regardless, I've fixed it up by hand and the only difference in the log, 
> > except for usual noise which I removed, is this:
> > 
> > --- dmesg-bad.log	2025-11-28 03:47:29.582049781 +0100
> > +++ dmesg-debug.log	2025-11-29 05:41:23.384645926 +0100
> > @@ -164,6 +164,8 @@
> >  fu740-pcie e00000000.pcie: ECAM at [mem 0xdf0000000-0xdffffffff] for [bus 00-ff]
> >  fu740-pcie e00000000.pcie: Using 256 MSI vectors
> >  fu740-pcie e00000000.pcie: iATU: unroll T, 8 ob, 8 ib, align 4K, limit 4096G
> > +fu740-pcie e00000000.pcie: Current iATU OB index 2
> > +fu740-pcie e00000000.pcie: Current iATU OB index 4
> >  fu740-pcie e00000000.pcie: cap_exp at 70
> >  fu740-pcie e00000000.pcie: PCIe Gen.1 x8 link up
> >  fu740-pcie e00000000.pcie: changing speed back to original
> > 
> > I've attached a full copy of the debug log too.  I hope this helps you 
> > narrow the issue down or otherwise let me know what to try next.
> > 
> >  NB I note that code you've been poking at only refers resources of the 
> > IORESOURCE_MEM type.  What about IORESOURCE_IO, which seems more relevant 
> > here?
> > 
> >  Also as a quick check I've now reconfigured the defxx driver for PCI port 
> > I/O (which is a one-liner; the mapping used to be selectable by hand, but 
> > distributions got it wrong for systems w/o PCI port I/O, so I switched the 
> > driver to an automatic choice a few years ago, but the logic remains):
> > 
> > # cat /proc/ioports
> > 00000000-0000ffff : pcie@...000000
> >   00001000-00002fff : PCI Bus 0000:01
> >     00001000-00002fff : PCI Bus 0000:02
> >       00001000-00002fff : PCI Bus 0000:05
> >         00001000-00002fff : PCI Bus 0000:06
> >           00001000-00001fff : PCI Bus 0000:07
> >           00001000-00001007 : 0000:07:00.0
> >           00001000-00001002 : parport0
> >           00001003-00001007 : parport0
> >           00001008-0000100b : 0000:07:00.0
> >           00001008-0000100a : parport0
> >           00002000-00002fff : PCI Bus 0000:08
> >           00002000-00002fff : PCI Bus 0000:09
> >           00002000-000020ff : 0000:09:01.0
> >           00002100-0000217f : 0000:09:02.0
> >           00002100-0000217f : defxx
> > # 
> > 
> > and:
> > 
> > defxx 0000:09:02.0: assign IRQ: got 40
> > defxx: v1.12 2021/03/10  Lawrence V. Stefani and others
> > defxx 0000:09:02.0: enabling device (0000 -> 0003)
> > defxx 0000:09:02.0: enabling bus mastering
> > 0000:09:02.0: DEFPA at I/O addr = 0x2100, IRQ = 40, Hardware addr = 00-60-6d-xx-xx-xx
> > 0000:09:02.0: registered as fddi0
> > 
> > (as at commit 4660e50cf818) and likewise it has stopped working here from 
> > commit 0da48c5b2fa7 onwards:
> > 
> > defxx 0000:09:02.0: assign IRQ: got 40
> > defxx: v1.12 2021/03/10  Lawrence V. Stefani and others
> > defxx 0000:09:02.0: enabling device (0000 -> 0003)
> > defxx 0000:09:02.0: enabling bus mastering
> > 0000:09:02.0: Could not read adapter factory MAC address!
> > 
> > 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.
> 
> 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.
> 
> 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.
> 

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.

- Mani

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

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

Powered by blists - more mailing lists