Re: [PATCH v2 01/21] arm64: dts: qcom: sm8250: Add PCIe bridge node

[Bjorn Helgaas <helgaas@kernel.org>]

On Tue, Jan 28, 2025 at 07:15:14PM +0530, Manivannan Sadhasivam wrote:
> On Tue, Jan 21, 2025 at 05:11:31PM -0600, Bjorn Helgaas wrote:
> ...

> > Let me back up; I don't think we're understanding each other.  This
> > DT:
> > 
> >   pcie@0 {
> >     bus-range = <0x01 0xff>;
> > 
> >     &pcieport0 {
> >       wifi@0 {
> > 	reg = <0x10000 0x0 0x0 0x0 0x0>;
> > 
> > says that wifi@0 is at 01:00.0, which is only true if the pcie@0
> > secondary bus number is 01.  The power-up default is 00, so it's
> > only 01 if either firmware or Linux has programmed it that way.
> > 
> > I claim this DT assumes the pcie@0 secondary bus number is
> > programmed either by firmware or Linux.  This makes me a bit
> > nervous because AFAIK there's nothing that guarantees Linux would
> > choose bus 01.
> 
> Why do you think so? PCI devices are scanned in a depth-first
> manner, so the bus number should match the DT order. Like, while
> scanning the bus under pcie@0, it should use 01 as the secondary bus
> number as it is going to be the first bus after the root bus. I
> don't know how linux or any other OS would end up using a different
> bus number.

In this case of the first bridge on the root bus, it's very likely
that the secondary bus will be 01.

If there are more bridges, it's dangerous to make assumptions about
their secondary bus numbers because those bus numbers depend on what
hierarchies have already been enumerated and any additional space
assigned in anticipation of hotplug.

I don't know of any spec that requires the OS to assign bus numbers in
a certain way, and it feels kind of subtle if this kind of DT
description is only reliable for things below the first bridge on a
root bus.

Bjorn