Re: clarification: PCI device not getting enumerated

["Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>]

[-- Attachment #1: Type: text/plain, Size: 6614 bytes --]

On Wed, 18 Mar 2026, Ratheesh Kannoth wrote:

> On 2026-03-18 at 02:36:40, Bjorn Helgaas (helgaas@kernel.org) wrote:
> > On Tue, Mar 17, 2026 at 03:49:07PM +0530, Ratheesh Kannoth wrote:
> > > Hi,
> > >
> > > Below commit breaks PCI enumeration of a marvell PCI endpoint (177d:a0e2).
> > > I am not familiar with PCI code, could you please help in debugging/fixing this ?
> > >
> > > Before the commit, the kernel set PCI_REASSIGN_ALL_BUS. So pcibios_assign_all_busses() was true,
> > > and in pci_scan_bridge_extend() the kernel took the “reassign” path and used EA
> > > (and pci_ea_fixed_busnrs()) to assign bus numbers.
> > >
> > > commit 7246a4520b4bf1494d7d030166a11b5226f6d508
> > > Author: Vidya Sagar <vidyas@nvidia.com>
> > > Date:   Wed May 8 23:11:38 2024 +0530
> > >
> > >     PCI: Use preserve_config in place of pci_flags
> > >
> > >     Use preserve_config in place of checking for PCI_PROBE_ONLY flag to enable
> > >     support for "linux,pci-probe-only" on a per host bridge basis.
> > >
> > >     This also obviates the use of adding PCI_REASSIGN_ALL_BUS flag if
> > >     !PCI_PROBE_ONLY, as pci_assign_unassigned_root_bus_resources() takes care
> > >     of reassigning the resources that are not already claimed.
> >
> > This commit appeared in v6.11.  Apparently on v6.6, 0002:1b:00.0 is
> > detected, and in the v6.12 dmesg below, we don't enumerate it.
> >
> > It looks like 7246a4520b4b can still be reverted cleanly from
> > v7.0-rc1.  Can you collect the complete dmesg logs from v7.0-rc1
> > (where I assume we won't see 0002:1b:00.0) and from v7.0-rc1 with
> > 7246a4520b4b reverted (where I assume we *will* see it) and output of
> > "sudo lspci -vv"?  Use the same kernel config and DT for both, of
> > course.
> Please find dmesg, lspci -vv and device tree output for v7.0-rc1 and v7.0-rc1 with patch reverted
> at bottom of this email. Used same kernel config and DT for both.
> 
> >
> > I don't understand some of the v6.12 dmesg log:
> >
> >   3.187193] pci-host-generic 878000000000.pci: Memory resource size exceeds max for 32 bits
> >   3.313087] pci 0000:00:01.0: PCI bridge to [bus 01] (subtractive decode)
> >   3.319878] pci 0000:00:01.0:   bridge window [mem 0x00000000-0x000fffff]
> >   3.723673] pci 0000:01:00.0: [177d:a075] type 00 class 0x088000 PCIe Endpoint
> >   3.730924] pci 0000:01:00.0: BAR 0 [mem 0x87e0fc000000-0x87e0fc03ffff 64bit]: from Enhanced Allocation, properties 0x0
> >   3.741710] pci 0000:01:00.0: BAR 4 [mem 0x87e0fcf00000-0x87e0fcffffff 64bit]: from Enhanced Allocation, properties 0x0
> >
> >   3.448655] pci 0000:00:0c.0: PCI bridge to [bus 02] (subtractive decode)
> >   3.455454] pci 0000:00:0c.0:   bridge window [mem 0x00000000-0x000fffff]
> >   4.425308] pci 0000:02:00.0: [177d:a075] type 00 class 0x088000 PCIe Endpoint
> >   4.432561] pci 0000:02:00.0: BAR 0 [mem 0x87e0f9000000-0x87e0f903ffff 64bit]: from Enhanced Allocation, properties 0x0
> >
> >   5.744082] pci-host-generic 878020000000.pci: Memory resource size exceeds max for 32 bits
> >   5.799532] pci 0002:00:00.0: PCI bridge to [bus fa] (subtractive decode)
> >   5.806322] pci 0002:00:00.0:   bridge window [mem 0x00000000-0x000fffff]
> >   5.820632] pci 0002:00:01.0: PCI bridge to [bus fb] (subtractive decode)
> >   5.827423] pci 0002:00:01.0:   bridge window [mem 0x00000000-0x000fffff]
> >
> > - The "Memory resource size exceeds max for 32 bits" warnings are
> >   interesting.  Is this a DT error?
>
> I dont see any errors as such. Could you guide me how to locate this issue, or suggest any command to check
> the same.

I'm sorry I only noticed this thread now.

Take a look for "root bus resource" lines in your log. When the size of 
those exceeds 4G, the warning is printed if the mem resource does not have 
IORESOURCE_PREFETCH set (which implies 64-bit window in the old way things 
were spec'ed). That resource printout includes "pref" when the flag is 
present.

For such resource, I think having IORESOURCE_PREFETCH and 
IORESOURCE_MEM_64 would be appropriate. And also for any resource that is 
expected to require >4G address even if size itself is small enough. 
Unfortunately things have not been very consistent when it comes to root 
bus resources.

The resource bits are given in DT along with the address range (but I'm 
not an DT expert by any means so I state something stupid when it comes 
to DTs, take it with a grain of salt :-)):

# pci feild (phys.hi)

npt000ss bbbbbbbb dddddfff rrrrrrrr

n: Relocateable Flag. (0 means relocation, 1 means impossible)
p: Prefetch Flag. (0 means impossible 1 means possible)
t: Aliased Flag.
ss: space code
  00: compositional space
  01: I/O space
  10: 32bit memory space
  11: 64bit memory space

I think your ranges have 0x03... which would seem to say they were 64-bit 
but that flag did not get set (or got cleared) for some reason as there's 
not "64-bit" in the root bus resource printouts.

I suspect the warning goes away if you change 0x03... to 0x43... but you 
also need to pay attention that pci_parse_request_of_pci_ranges() requires 
also one non-prefetchable resource within each set of root bus resources 
so or it will trigger another warning if you change them all.

I'm not sure if it resolves the primary issue.

> > - There should only be one subtractive decode bridge per segment, but
> >   there are many here.
> >
> > - Most of the bridge windows look uninitialized ([mem
> >   0x00000000-0x000fffff]), and we don't seem to reassign them, so BARs
> >   of the downstream devices shouldn't be reachable.
> >
> > - Interesting to see so much "Enhanced Allocation"; that's very
> >   unusual.
> >
> > - I guess your DT must have "linux,pci-probe-only"; seems like that
> No.
> 
> +++ fdt dump from uboot +++
> 
> crb106-pcie> fdt print /soc/pci@878020000000
> pci@878020000000 {
>         compatible = "pci-host-ecam-generic";
>         device_type = "pci";
>         msi-map = <0x00000000 0x00000037 0x00020000 0x00010000>;
>         bus-range = <0x00000000 0x000000ff>;
>         #size-cells = <0x00000002>;
>         #address-cells = <0x00000003>;
>         dma-coherent;
>         linux,pci-domain = <0x00000002>;
>         reg = <0x00008780 0x20000000 0x00000000 0x10000000>;
>         iommu-map = <0x00000000 0x00000039 0x00020000 0x00010000>;
>         ranges = <0x03000000 0x00008400 0x00000000 0x00008400 0x00000000 0x000001f5 0x00000000 0x03000000 0x00000009 0xfc000000 0x00000009 0xfc000000 0x00000000 0x03040000>;


-- 
 i.