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

[Maciej W. Rozycki]

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

  Maciej
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dmesg-debug.log.xz
Type: application/x-xz
Size: 8572 bytes
Desc: 
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20251129/37067ad1/attachment.xz>