All of lore.kernel.org
 help / color / mirror / Atom feed
From: Herve Codina <herve.codina@bootlin.com>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Andrew Lunn <andrew@lunn.ch>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Danilo Krummrich <dakr@kernel.org>,
	Shawn Guo <shawnguo@kernel.org>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	Pengutronix Kernel Team <kernel@pengutronix.de>,
	Fabio Estevam <festevam@gmail.com>,
	Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@kernel.org>,
	Andi Shyti <andi.shyti@kernel.org>,
	Wolfram Sang <wsa+renesas@sang-engineering.com>,
	Peter Rosin <peda@axentia.se>,
	Derek Kiernan <derek.kiernan@amd.com>,
	Dragan Cvetic <dragan.cvetic@amd.com>,
	Arnd Bergmann <arnd@arndb.de>, Rob Herring <robh@kernel.org>,
	Saravana Kannan <saravanak@google.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Mark Brown <broonie@kernel.org>, Len Brown <lenb@kernel.org>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Daniel Scally <djrscally@gmail.com>,
	Heikki Krogerus <heikki.krogerus@linux.intel.com>,
	Sakari Ailus <sakari.ailus@linux.intel.com>,
	Wolfram Sang <wsa@kernel.org>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	linux-kernel@vger.kernel.org, imx@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org, linux-clk@vger.kernel.org,
	linux-i2c@vger.kernel.org, devicetree@vger.kernel.org,
	linux-pci@vger.kernel.org, linux-spi@vger.kernel.org,
	linux-acpi@vger.kernel.org,
	Allan Nielsen <allan.nielsen@microchip.com>,
	Horatiu Vultur <horatiu.vultur@microchip.com>,
	Steen Hegelund <steen.hegelund@microchip.com>,
	Luca Ceresoli <luca.ceresoli@bootlin.com>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Subject: Re: [PATCH v2 05/26] bus: simple-pm-bus: Populate child nodes at probe
Date: Mon, 19 May 2025 14:46:02 +0200	[thread overview]
Message-ID: <20250519144602.0399c9c5@bootlin.com> (raw)
In-Reply-To: <CAJZ5v0iL9-JzTzE7pYTJGuB1BbrE6L12K2FKNpQ8dhX9GureJw@mail.gmail.com>

Hi Rafael,

On Fri, 16 May 2025 21:22:20 +0200
"Rafael J. Wysocki" <rafael@kernel.org> wrote:

> On Wed, May 7, 2025 at 9:13 AM Herve Codina <herve.codina@bootlin.com> wrote:
> >
> > The simple-pm-bus drivers handles several simple bus. When it is used  
> 
> s/drivers/driver/ (I think)
> s/simple bus/simple busses/

Will be fixed.

> 
> > with busses other than a compatible "simple-pm-bus", it don't populate  
> 
> s/it don't/it doesn't/

Will be fixed.

> 
> > its child devices during its probe.
> >
> > This confuses fw_devlink and results in wrong or missing devlinks.  
> 
> Well, fair enough, but doesn't it do that for a reason?

I think devlink is confused just because "simple-bus" or similar handled
by this driver didn't follow the devlink rule: "Child nodes should be
created during parent probe".

Suppose the following:
   foo@0 {
	compatible = "vendor,foo"

	bar@0 {
		compatible = "simple-bus";

		baz@100 {
			compatible = "vendor,baz"
		};
	};
   };

The foo driver probe() calls from of_platform_default_populate() to create
the bar device.

The bar is create and thanks to its compatible string, the simple-bus
probe() is called. Without my modification, the baz device was not created
during the simple-bus probe().

of_platform_default_populate() called from foo probe() creates the baz
device thanks to the recursive of_platform_bus_create() call.

This leads the baz device created outside the bar probe() call.
This "out of bus probe()" device creation confuses devlink.

> 
> > Once a driver is bound to a device and the probe() has been called,
> > device_links_driver_bound() is called.
> >
> > This function performs operation based on the following assumption:
> >     If a child firmware node of the bound device is not added as a
> >     device, it will never be added.
> >
> > Among operations done on fw_devlinks of those "never be added" devices,
> > device_links_driver_bound() changes their supplier.
> >
> > With devices attached to a simple-bus compatible device, this change
> > leads to wrong devlinks where supplier of devices points to the device
> > parent (i.e. simple-bus compatible device) instead of the device itself
> > (i.e. simple-bus child).
> >
> > When the device attached to the simple-bus is removed, because devlinks
> > are not correct, its consumers are not removed first.
> >
> > In order to have correct devlinks created, make the simple-pm-bus driver
> > compliant with the devlink assumption and create its child devices
> > during its probe.
> >
> > Signed-off-by: Herve Codina <herve.codina@bootlin.com>
> > ---
> >  drivers/bus/simple-pm-bus.c | 23 ++++++++++++++---------
> >  1 file changed, 14 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/bus/simple-pm-bus.c b/drivers/bus/simple-pm-bus.c
> > index d8e029e7e53f..93c6ba605d7a 100644
> > --- a/drivers/bus/simple-pm-bus.c
> > +++ b/drivers/bus/simple-pm-bus.c
> > @@ -42,14 +42,14 @@ static int simple_pm_bus_probe(struct platform_device *pdev)
> >         match = of_match_device(dev->driver->of_match_table, dev);
> >         /*
> >          * These are transparent bus devices (not simple-pm-bus matches) that
> > -        * have their child nodes populated automatically.  So, don't need to
> > -        * do anything more. We only match with the device if this driver is
> > -        * the most specific match because we don't want to incorrectly bind to
> > -        * a device that has a more specific driver.
> > +        * have their child nodes populated automatically. So, don't need to
> > +        * do anything more except populate child nodes.  
> 
> The above part of the comment has become hard to grasp after the
> change.  In particular, why populate child notes if they are populated
> automatically?

What do you thing about:
	/*
	 * These are transparent bus devices (not simple-pm-bus matches) that
	 * have their child nodes be populated automatically. So, don't need to
	 * do anything more except populate child nodes. We only match with the
	 * device if this driver is the most specific match because we don't
	 * want to incorrectly bind to a device that has a more specific driver.
	 */

> 
> > + We only match with the
> > +        * device if this driver is the most specific match because we don't
> > +        * want to incorrectly bind to a device that has a more specific driver.
> >          */
> >         if (match && match->data) {
> >                 if (of_property_match_string(np, "compatible", match->compatible) == 0)
> > -                       return 0;
> > +                       goto populate;  
> 
> Doesn't this interfere with anything, like the automatic population of
> child nodes mentioned in the comment?

I don't think so.

Device population is protected against multiple calls with OF_POPULATED_BUS
flag:
  https://elixir.bootlin.com/linux/v6.15-rc6/source/drivers/of/platform.c#L349

> 
> >                 else
> >                         return -ENODEV;
> >         }
> > @@ -64,13 +64,14 @@ static int simple_pm_bus_probe(struct platform_device *pdev)
> >
> >         dev_set_drvdata(&pdev->dev, bus);
> >
> > -       dev_dbg(&pdev->dev, "%s\n", __func__);
> > -
> >         pm_runtime_enable(&pdev->dev);
> >
> > +populate:
> >         if (np)
> >                 of_platform_populate(np, NULL, lookup, &pdev->dev);
> >
> > +       dev_dbg(&pdev->dev, "%s\n", __func__);  
> 
> So how to distinguish between devices that only have child nodes
> populated and the ones that have drvdata set?

Hum, I don't see your point.
Can you clarify ?

> 
> > +
> >         return 0;
> >  }
> >
> > @@ -78,12 +79,16 @@ static void simple_pm_bus_remove(struct platform_device *pdev)
> >  {
> >         const void *data = of_device_get_match_data(&pdev->dev);
> >
> > -       if (pdev->driver_override || data)
> > +       if (pdev->driver_override)
> >                 return;
> >
> >         dev_dbg(&pdev->dev, "%s\n", __func__);
> >
> > -       pm_runtime_disable(&pdev->dev);
> > +       if (pdev->dev.of_node)
> > +               of_platform_depopulate(&pdev->dev);
> > +
> > +       if (!data)
> > +               pm_runtime_disable(&pdev->dev);
> >  }
> >
> >  static int simple_pm_bus_runtime_suspend(struct device *dev)
> > --  

Thanks for your feedback.

Best regards,
Hervé

  reply	other threads:[~2025-05-19 12:46 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-07  7:12 [PATCH v2 00/26] lan966x pci device: Add support for SFPs Herve Codina
2025-05-07  7:12 ` [PATCH v2 01/26] Revert "treewide: Fix probing of devices in DT overlays" Herve Codina
2025-05-07 11:28   ` Mark Brown
2025-05-07  7:12 ` [PATCH v2 02/26] driver core: Rename get_dev_from_fwnode() wrapper to get_device_from_fwnode() Herve Codina
2025-05-07  7:12 ` [PATCH v2 03/26] of: dynamic: Fix overlayed devices not probing because of fw_devlink Herve Codina
2025-05-07  7:12 ` [PATCH v2 04/26] driver core: Avoid warning when removing a device while its supplier is unbinding Herve Codina
2025-05-07 15:15   ` Andy Shevchenko
2025-05-19 11:35     ` Herve Codina
2025-05-07  7:12 ` [PATCH v2 05/26] bus: simple-pm-bus: Populate child nodes at probe Herve Codina
2025-05-08 14:27   ` Andy Shevchenko
2025-05-19 11:58     ` Herve Codina
2025-05-19 12:06       ` Andy Shevchenko
2025-05-19 14:24         ` Herve Codina
2025-05-16 19:22   ` Rafael J. Wysocki
2025-05-19 12:46     ` Herve Codina [this message]
2025-05-07  7:12 ` [PATCH v2 06/26] driver core: fw_devlink: Introduce fw_devlink_set_device() Herve Codina
2025-05-07 15:02   ` Andy Shevchenko
2025-05-19 14:27     ` Herve Codina
2025-05-07  7:12 ` [PATCH v2 07/26] drivers: core: Use fw_devlink_set_device() Herve Codina
2025-05-07  7:12 ` [PATCH v2 08/26] pinctrl: cs42l43: " Herve Codina
2025-05-07 15:06   ` Andy Shevchenko
2025-05-07  7:12 ` [PATCH v2 09/26] cxl/test: Use device_set_node() Herve Codina
2025-05-07 15:10   ` Andy Shevchenko
2025-05-08 11:47     ` Jonathan Cameron
2025-05-07  7:12 ` [PATCH v2 10/26] cxl/test: Use fw_devlink_set_device() Herve Codina
2025-05-07  7:12 ` [PATCH v2 11/26] PCI: of: " Herve Codina
2025-05-07  7:12 ` [PATCH v2 12/26] PCI: of: Set fwnode device of newly created PCI device nodes Herve Codina
2025-05-08 18:31   ` Andy Shevchenko
2025-05-08 18:35     ` Geert Uytterhoeven
2025-05-07  7:12 ` [PATCH v2 13/26] PCI: of: Remove fwnode_dev_initialized() call for a PCI root bridge node Herve Codina
2025-05-07  7:12 ` [PATCH v2 14/26] i2c: core: Introduce i2c_get_adapter_physdev() Herve Codina
2025-05-07  7:12 ` [PATCH v2 15/26] i2c: mux: Set adapter physical device Herve Codina
2025-05-07  7:12 ` [PATCH v2 16/26] i2c: mux: Create missing devlink between mux and " Herve Codina
2025-05-08 19:15   ` Andy Shevchenko
2025-05-19 14:39     ` Herve Codina
2025-05-07  7:12 ` [PATCH v2 17/26] of: property: Allow fw_devlink device-tree on x86 when PCI device-tree node creation is enabled Herve Codina
2025-05-08 19:19   ` Andy Shevchenko
2025-05-07  7:13 ` [PATCH v2 18/26] clk: lan966x: Add MCHP_LAN966X_PCI dependency Herve Codina
2025-05-07  7:13 ` [PATCH v2 19/26] i2c: busses: at91: " Herve Codina
2025-05-12 22:32   ` Andi Shyti
2025-05-07  7:13 ` [PATCH v2 20/26] misc: lan966x_pci: Fix dtso nodes ordering Herve Codina
2025-05-07  7:13 ` [PATCH v2 21/26] misc: lan966x_pci: Split dtso in dtsi/dtso Herve Codina
2025-05-07 22:14   ` Andrew Lunn
2025-05-07  7:13 ` [PATCH v2 22/26] misc: lan966x_pci: Rename lan966x_pci.dtso to lan966x_evb_lan9662_nic.dtso Herve Codina
2025-05-07 22:14   ` Andrew Lunn
2025-05-07  7:13 ` [PATCH v2 23/26] misc: lan966x_pci: Introduce board specific data Herve Codina
2025-05-07 22:24   ` Andrew Lunn
2025-05-08  7:13     ` Geert Uytterhoeven
2025-05-29 13:19       ` Rob Herring
2025-05-19 14:44     ` Herve Codina
2025-05-08 19:21   ` Andy Shevchenko
2025-05-19 15:00     ` Herve Codina
2025-05-19 15:44       ` Andy Shevchenko
2025-05-07  7:13 ` [PATCH v2 24/26] misc: lan966x_pci: Add dtsi/dtso nodes in order to support SFPs Herve Codina
2025-05-07  7:13 ` [PATCH v2 25/26] misc: lan966x_pci: Sort the drivers list in Kconfig help Herve Codina
2025-05-07  7:13 ` [PATCH v2 26/26] misc: lan966x_pci: Add drivers needed to support SFPs " Herve Codina

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250519144602.0399c9c5@bootlin.com \
    --to=herve.codina@bootlin.com \
    --cc=allan.nielsen@microchip.com \
    --cc=andi.shyti@kernel.org \
    --cc=andrew@lunn.ch \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=arnd@arndb.de \
    --cc=bhelgaas@google.com \
    --cc=broonie@kernel.org \
    --cc=dakr@kernel.org \
    --cc=derek.kiernan@amd.com \
    --cc=devicetree@vger.kernel.org \
    --cc=djrscally@gmail.com \
    --cc=dragan.cvetic@amd.com \
    --cc=festevam@gmail.com \
    --cc=geert+renesas@glider.be \
    --cc=gregkh@linuxfoundation.org \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=horatiu.vultur@microchip.com \
    --cc=imx@lists.linux.dev \
    --cc=kernel@pengutronix.de \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=luca.ceresoli@bootlin.com \
    --cc=mturquette@baylibre.com \
    --cc=peda@axentia.se \
    --cc=rafael@kernel.org \
    --cc=robh@kernel.org \
    --cc=s.hauer@pengutronix.de \
    --cc=sakari.ailus@linux.intel.com \
    --cc=saravanak@google.com \
    --cc=sboyd@kernel.org \
    --cc=shawnguo@kernel.org \
    --cc=steen.hegelund@microchip.com \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=wsa+renesas@sang-engineering.com \
    --cc=wsa@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.