Message-ID: <h7pgm3lqolm53sb4wrcpcurk4ghz4tulqnr7vgd7rzxy4hscue@jcn5tepevlwl>
Date: Mon, 1 Dec 2025 17:21:33 +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 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.

Sorry for the inconvenience!

- Mani

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

Powered by blists - more mailing lists