netdev - Re: [PATCH v2 18/19] mfd: Add support for LAN966x PCI device

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] [thread-next>] [day] [month] [year] [list]

Date: Mon, 24 Jun 2024 10:20:03 +0200
From: Herve Codina <herve.codina@...tlin.com>
To: Andy Shevchenko <andy.shevchenko@...il.com>
Cc: Simon Horman <horms@...nel.org>, Sai Krishna Gajula
 <saikrishnag@...vell.com>, Thomas Gleixner <tglx@...utronix.de>, Rob
 Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor
 Dooley <conor+dt@...nel.org>, "David S. Miller" <davem@...emloft.net>, Eric
 Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo
 Abeni <pabeni@...hat.com>, Lee Jones <lee@...nel.org>, Arnd Bergmann
 <arnd@...db.de>, Horatiu Vultur <horatiu.vultur@...rochip.com>,
 UNGLinuxDriver@...rochip.com, Andrew Lunn <andrew@...n.ch>, Heiner Kallweit
 <hkallweit1@...il.com>, Russell King <linux@...linux.org.uk>, Saravana
 Kannan <saravanak@...gle.com>, Bjorn Helgaas <bhelgaas@...gle.com>, Philipp
 Zabel <p.zabel@...gutronix.de>, Lars Povlsen <lars.povlsen@...rochip.com>,
 Steen Hegelund <Steen.Hegelund@...rochip.com>, Daniel Machon
 <daniel.machon@...rochip.com>, Alexandre Belloni
 <alexandre.belloni@...tlin.com>, linux-kernel@...r.kernel.org,
 devicetree@...r.kernel.org, netdev@...r.kernel.org,
 linux-pci@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, Allan
 Nielsen <allan.nielsen@...rochip.com>, Luca Ceresoli
 <luca.ceresoli@...tlin.com>, Thomas Petazzoni
 <thomas.petazzoni@...tlin.com>
Subject: Re: [PATCH v2 18/19] mfd: Add support for LAN966x PCI device

On Fri, 21 Jun 2024 17:45:05 +0200
Andy Shevchenko <andy.shevchenko@...il.com> wrote:

> On Thu, Jun 20, 2024 at 7:19 PM Herve Codina <herve.codina@...tlin.com> wrote:
> > On Thu, 20 Jun 2024 18:43:09 +0200
> > Herve Codina <herve.codina@...tlin.com> wrote:  
> > > On Thu, 20 Jun 2024 18:07:16 +0200
> > > Andy Shevchenko <andy.shevchenko@...il.com> wrote:  
> > > > On Thu, Jun 20, 2024 at 5:56 PM Herve Codina <herve.codina@...tlin.com> wrote:  
> > > > > On Wed, 5 Jun 2024 23:24:43 +0300
> > > > > Andy Shevchenko <andy.shevchenko@...il.com> wrote:  
> > > > > > Mon, May 27, 2024 at 06:14:45PM +0200, Herve Codina kirjoitti:  
> 
> ...
> 
> > > > > > > +   if (!dev->of_node) {
> > > > > > > +           dev_err(dev, "Missing of_node for device\n");
> > > > > > > +           return -EINVAL;
> > > > > > > +   }  
> > > > > >
> > > > > > Why do you need this? The code you have in _create_intr_ctrl() will take care
> > > > > > already for this case.  
> > > > >
> > > > > The code in _create_intr_ctrl checks for fwnode and not an of_node.
> > > > >
> > > > > The check here is to ensure that an of_node is available as it will be use
> > > > > for DT overlay loading.  
> > > >
> > > > So, what exactly do you want to check? fwnode check covers this.
> > > >  
> > > > > I will keep the check here and use dev_of_node() instead of dev->of_node.  
> > > >
> > > > It needs to be well justified as from a coding point of view this is a
> > > > duplication.  
> >
> > On DT based system, if a fwnode is set it is an of_node.
> > On ACPI, if a fwnode is set is is an acpi_node.
> >
> > The core PCI, when it successfully creates the DT node for a device
> > (CONFIG_PCI_DYNAMIC_OF_NODES) set the of_node of this device.
> > So we can have a device with:
> >  - fwnode from ACPI
> >  - of_node from core PCI creation  
> 
> Does PCI device creation not set fwnode?

No and IMHO it is correct.
This device has the fwnode that point to an ACPI node: The description used
for device creation.

The of_node set is created based on PCI known information.
This of_node, at PCI level is not used to create the PCI device but is created
based on an already existing PCI device.

> 
> > This driver needs the of_node to load the overlay.
> > Even if the core PCI cannot create a DT node for the PCI device right
> > now, I don't expect this LAN855x PCI driver updated when the core PCI
> > is able to create this PCI device DT node.  
> 
> If it's really needed, I think the correct call here is is_of_node()
> to show exactly why it's not a duplication. It also needs a comment on
> top of this call.

is_of_node() will not returns the expected result.
It will return false as the fwnode->ops of the device is not related to 
of_node ops but ACPI node ops :(

What do you thing it I keep the of_node test using dev_of_node() and add the
following comment:
	--- 8< ---
	/*
	 * On ACPI system, fwnode can point to the ACPI node.
	 * This driver needs an of_node to be used as the device-tree overlay
	 * target. This of_node should be set by the PCI core if it succeeds in
	 * creating it (CONFIG_PCI_DYNAMIC_OF_NODES feature).
	 * Check here for the validity of the of_node.
	 */
	if (!dev_of_node(dev)) {
		dev_err(dev, "Missing of_node for device\n");
		return -EINVAL;
	}
	--- 8< ---

Let me know if this can be ok.

Hervé