On Thu, Feb 20, 2025 at 09:25:14AM +0100, Herve Codina wrote:
> On Wed, 19 Feb 2025 11:39:12 -0600
> Bjorn Helgaas <helgaas@xxxxxxxxxx> wrote:
> > On Tue, Feb 04, 2025 at 08:35:00AM +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").
> > >
> > > In order to have device-tree nodes related to PCI devices attached on
> > > their PCI root bus (the PCI bus handled by the PCI host bridge), a PCI
> > > root bus device-tree node is needed. This root bus node will be used as
> > > the parent node of the first level devices scanned on the bus. On
> > > device-tree based systems, this PCI root bus device tree node is set to
> > > the node of the related PCI host bridge. The PCI host bridge node is
> > > available in the device-tree used to describe the hardware passed at
> > > boot.
> > >
> > > On non device-tree based system (such as ACPI), a device-tree node for
> > > the PCI host bridge or for the root bus does not exist. Indeed, the PCI
> > > host bridge is not described in a device-tree used at boot simply
> > > because no device-tree are passed at boot.
> > >
> > > The device-tree PCI host bridge node creation needs to be done at
> > > runtime. This is done in the same way as for the creation of the PCI
> > > device nodes. I.e. node and properties are created based on computed
> > > information done by the PCI core. Also, as is done on device-tree based
> > > systems, this PCI host bridge node is used for the PCI root bus.
> >
> > This is a detailed low-level description of what this patch does. Can
> > we include a high level outline of what the benefit is and why we want
> > this patch?
> >
> > Based on 185686beb464 ("misc: Add support for LAN966x PCI device"), I
> > assume the purpose is to deal with some kind of non-standard PCI
> > topology, e.g., a single B/D/F function contains several different
> > pieces of functionality to be driven by several different drivers, and
> > we build a device tree description of those pieces and then bind those
> > drivers to the functionality using platform_device interfaces?
>
> What do you think if I add the following at the end of the commit log?
>
> With this done, hardware available in complex PCI device can be
> described by a device-tree overlay loaded by the PCI device driver
> on non device-tree based systems. For instance, the LAN966x PCI device
> introduced by commit 185686beb464 ("misc: Add support for LAN966x
> PCI device") can be available on x86 systems.
This isn't just about complexity of the device. There are NICs that
are much more complex.
IIUC this is really about devices that don't follow the standard
"one PCI function <--> one driver" model, so I think it's important to
include something about the case of a single function that includes
several unrelated bits of functionality that require different
drivers.
"LAN966x" might mean something to people who know that this thing has
a half dozen separate things inside it, but the name by itself doesn't
suggest that, so I don't think it's really helpful to the general
audience.
Bjorn
