linux-kernel - Re: [PATCH v7 5/5] PCI: of: Create device-tree PCI host bridge node

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250221181938.GA352971@bhelgaas>
Date: Fri, 21 Feb 2025 12:19:38 -0600
From: Bjorn Helgaas <helgaas@...nel.org>
To: Herve Codina <herve.codina@...tlin.com>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"Rafael J. Wysocki" <rafael@...nel.org>,
	Danilo Krummrich <dakr@...nel.org>, Rob Herring <robh@...nel.org>,
	Saravana Kannan <saravanak@...gle.com>,
	Bjorn Helgaas <bhelgaas@...gle.com>, Lizhi Hou <lizhi.hou@....com>,
	linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
	linux-pci@...r.kernel.org,
	Allan Nielsen <allan.nielsen@...rochip.com>,
	Horatiu Vultur <horatiu.vultur@...rochip.com>,
	Steen Hegelund <steen.hegelund@...rochip.com>,
	Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Subject: Re: [PATCH v7 5/5] PCI: of: Create device-tree PCI host bridge node

On Fri, Feb 21, 2025 at 09:34:27AM +0100, Herve Codina wrote:
> Hi Bjorn,
> 
> On Thu, 20 Feb 2025 18:07:53 -0600
> Bjorn Helgaas <helgaas@...nel.org> wrote:
> 
> > 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@...nel.org> 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.
> 
> Yes.
> 
> > 
> > "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.
> > 
> 
> Does this one at the end of the commit log sound better?
> 
>     With this done, hardware available in a PCI device that doesn't follow
>     the PCI model consisting in one PCI function handled by one driver can
>     be described by a device-tree overlay loaded by the PCI device driver
>     on non device-tree based systems. Those PCI devices provide a single PCI
>     function that includes several functionalities that require different
>     driver. The device-tree overlay describes in that case the internal
>     devices and their relationships. It allows to load drivers needed by
>     those different devices in order to have functionalities handled.

Yep, thanks.