On Wed, Nov 06, 2024 at 03:53:53PM +0100, Herve Codina wrote:
> On Tue, 5 Nov 2024 12:59:01 -0600
> Bjorn Helgaas <helgaas@xxxxxxxxxx> wrote:
> > On Mon, Nov 04, 2024 at 06:20:00PM +0100, Herve Codina wrote:
> > > PCI devices device-tree nodes can be already created. This was
> > > introduced by commit 407d1a51921e ("PCI: Create device tree node for
> > > bridge").
> ...
> > > Indeed, this component is not described
> > > in a device-tree used at boot.
> >
> > But maybe I'm on the wrong track, because obviously PCI host
> > controllers *are* described in DTs used at boot.
>
> They are described in a device-tree used at boot on device-tree based
> systems.
> On x86, we are on ACPI based system -> No DT used at boot -> PCI host
> controller not described in DT.
Right, I was thinking of the devicetree-based systems, where the host
controller must be described in DT.
> > > + name = kasprintf(GFP_KERNEL, "pci-root@%x,%x", pci_domain_nr(bus),
> > > + bus->number);
> >
> > Should this be "pci%d@%x,%x" to match the typical descriptions of PCI
> > host bridges in DT?
>
> What do you think I should use for the %d you proposed.
Based on the .dts files, I think the %d is just an index to
distinguish multiple PCI host bridges. Maybe that's not relevant
here, I dunno.
> Also I supposed your "@%x,%x" is still pci_domain_nr(bus), bus->number.
Yes. I think we're basically constructing a DT node to correspond to
an ACPI PNP0A03 device. ACPI does support updating the root bus
number via _CRS/_PRS/_SRS, but Linux doesn't have support for that, so
the root bus number is basically constant. The pci_domain_nr(bus)
should be coming from _SEG, and that's definitely constant.
Bjorn
