From: Rob Herring <robh@kernel.org>
To: Herve Codina <herve.codina@bootlin.com>
Cc: Andrew Lunn <andrew@lunn.ch>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.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>,
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>,
Davidlohr Bueso <dave@stgolabs.net>,
Dave Jiang <dave.jiang@intel.com>,
Alison Schofield <alison.schofield@intel.com>,
Vishal Verma <vishal.l.verma@intel.com>,
Ira Weiny <ira.weiny@intel.com>,
Dan Williams <dan.j.williams@intel.com>,
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, linux-cxl@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 v3 18/28] of: property: Allow fw_devlink device-tree on x86 when PCI device-tree node creation is enabled
Date: Fri, 27 Jun 2025 11:22:45 -0500 [thread overview]
Message-ID: <20250627162245.GA3513535-robh@kernel.org> (raw)
In-Reply-To: <20250613134817.681832-19-herve.codina@bootlin.com>
On Fri, Jun 13, 2025 at 03:47:58PM +0200, Herve Codina wrote:
> PCI drivers can use a device-tree overlay to describe the hardware
> available on the PCI board. This is the case, for instance, of the
> LAN966x PCI device driver.
>
> Adding some more nodes in the device-tree overlay adds some more
> consumer/supplier relationship between devices instantiated from this
> overlay.
>
> Those fw_node consumer/supplier relationships are handled by fw_devlink
> and are created based on the device-tree parsing done by the
> of_fwnode_add_links() function.
>
> Those consumer/supplier links are needed in order to ensure a correct PM
> runtime management and a correct removal order between devices.
>
> For instance, without those links a supplier can be removed before its
> consumers is removed leading to all kind of issue if this consumer still
> want the use the already removed supplier.
>
> The support for the usage of an overlay from a PCI driver has been added
> on x86 systems in commit 1f340724419ed ("PCI: of: Create device tree PCI
> host bridge node").
>
> In the past, support for fw_devlink on x86 had been tried but this
> support has been removed in commit 4a48b66b3f52 ("of: property: Disable
> fw_devlink DT support for X86"). Indeed, this support was breaking some
> x86 systems such as OLPC system and the regression was reported in [0].
>
> Instead of disabling this support for all x86 system, a first approach
> would be to use a finer grain and disable this support only for the
> possible problematic subset of x86 systems (at least OLPC and CE4100).
>
> This first approach could still leads to issues. Indeed, the list of
> possible problematic system and the way to identify them using Kconfig
> symbols is not well defined and so some system can be missed leading to
> kernel regressions on those missing systems.
>
> Use an other way and enable the support on x86 system only when this
> support is needed by some specific feature. The usage of a device-tree
> overlay by a PCI driver and thus the creation of PCI device-tree nodes
> is a feature that needs it.
>
> Signed-off-by: Herve Codina <herve.codina@bootlin.com>
> Link: https://lore.kernel.org/lkml/3c1f2473-92ad-bfc4-258e-a5a08ad73dd0@web.de/ [0]
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
> drivers/of/property.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/of/property.c b/drivers/of/property.c
> index c1feb631e383..8b5cfee696e2 100644
> --- a/drivers/of/property.c
> +++ b/drivers/of/property.c
> @@ -1605,7 +1605,7 @@ static int of_fwnode_add_links(struct fwnode_handle *fwnode)
> const struct property *p;
> struct device_node *con_np = to_of_node(fwnode);
>
> - if (IS_ENABLED(CONFIG_X86))
> + if (IS_ENABLED(CONFIG_X86) && !IS_ENABLED(CONFIG_PCI_DYNAMIC_OF_NODES))
I really want CONFIG_PCI_DYNAMIC_OF_NODES to go away at some point, not
add more users.
I think this should instead check for specific platforms not with
kconfig symbols but DT properties. For ce4100, you can just check the
root compatible string. For OLPC, there isn't a root compatible (in the
DT I have). You could check for /architecture == OLPC instead. There's
some virtualization guests using DT now too. I would think their DT's
are simple enough to avoid any fw_devlink issues.
Alternatively, we could perhaps make x86 fw_devlink default off and then
enable it only when you create nodes. Maybe it has to be restricted a
sub tree of the DT to avoid any later interactions if devices are
unbound and rebound. Not a fully fleshed out idea...
Rob
next prev parent reply other threads:[~2025-06-27 16:22 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-13 13:47 [PATCH v3 00/28] lan966x pci device: Add support for SFPs Herve Codina
2025-06-13 13:47 ` [PATCH v3 01/28] Revert "treewide: Fix probing of devices in DT overlays" Herve Codina
2025-06-13 13:47 ` [PATCH v3 02/28] driver core: Rename get_dev_from_fwnode() wrapper to get_device_from_fwnode() Herve Codina
2025-06-27 14:18 ` Rob Herring
2025-06-27 14:52 ` Herve Codina
2025-07-02 18:51 ` Danilo Krummrich
2025-07-02 18:17 ` Rafael J. Wysocki
2025-07-03 8:10 ` Herve Codina
2025-06-13 13:47 ` [PATCH v3 03/28] of: dynamic: Fix overlayed devices not probing because of fw_devlink Herve Codina
2025-06-13 13:47 ` [PATCH v3 04/28] driver core: Avoid warning when removing a device while its supplier is unbinding Herve Codina
2025-07-02 18:22 ` Rafael J. Wysocki
2025-07-02 21:02 ` Saravana Kannan
2025-06-13 13:47 ` [PATCH v3 05/28] bus: simple-pm-bus: Populate child nodes at probe Herve Codina
2025-06-16 11:28 ` Andy Shevchenko
2025-06-27 15:52 ` Rob Herring
2025-07-03 7:33 ` Herve Codina
2025-07-04 8:57 ` Herve Codina
2025-07-14 17:44 ` Rob Herring
2025-07-15 7:52 ` Herve Codina
2025-06-13 13:47 ` [PATCH v3 06/28] driver core: fw_devlink: Introduce fw_devlink_set_device() Herve Codina
2025-06-13 21:13 ` Saravana Kannan
2025-06-16 7:04 ` Herve Codina
2025-06-27 14:59 ` Herve Codina
2025-06-16 11:32 ` Andy Shevchenko
2025-06-13 13:47 ` [PATCH v3 07/28] drivers: core: Use fw_devlink_set_device() Herve Codina
2025-06-16 11:39 ` Andy Shevchenko
2025-06-13 13:47 ` [PATCH v3 08/28] pinctrl: cs42l43: " Herve Codina
2025-06-16 11:37 ` Andy Shevchenko
2025-06-13 13:47 ` [PATCH v3 09/28] cxl/test: Use device_set_node() Herve Codina
2025-06-13 15:58 ` Dave Jiang
2025-06-13 13:47 ` [PATCH v3 10/28] cxl/test: Use fw_devlink_set_device() Herve Codina
2025-06-13 15:58 ` Dave Jiang
2025-06-13 13:47 ` [PATCH v3 11/28] PCI: of: " Herve Codina
2025-06-16 11:45 ` Andy Shevchenko
2025-06-13 13:47 ` [PATCH v3 12/28] driver core: fw_devlink: Tag the fwnode dev member as private Herve Codina
2025-06-14 15:07 ` kernel test robot
2025-06-16 11:38 ` Andy Shevchenko
2025-06-13 13:47 ` [PATCH v3 13/28] PCI: of: Set fwnode device of newly created PCI device nodes Herve Codina
2025-06-13 13:47 ` [PATCH v3 14/28] PCI: of: Remove fwnode_dev_initialized() call for a PCI root bridge node Herve Codina
2025-06-13 13:47 ` [PATCH v3 15/28] i2c: core: Introduce i2c_get_adapter_physdev() Herve Codina
2025-07-22 14:04 ` Andi Shyti
2025-06-13 13:47 ` [PATCH v3 16/28] i2c: mux: Set adapter physical device Herve Codina
2025-06-13 13:47 ` [PATCH v3 17/28] i2c: mux: Create missing devlink between mux and " Herve Codina
2025-06-13 13:47 ` [PATCH v3 18/28] of: property: Allow fw_devlink device-tree on x86 when PCI device-tree node creation is enabled Herve Codina
2025-06-27 16:22 ` Rob Herring [this message]
2025-06-27 16:33 ` Andy Shevchenko
2025-06-27 17:49 ` Rob Herring
2025-07-03 6:37 ` Herve Codina
2025-06-13 13:47 ` [PATCH v3 19/28] clk: lan966x: Add MCHP_LAN966X_PCI dependency Herve Codina
2025-06-21 21:08 ` Stephen Boyd
2025-06-13 13:48 ` [PATCH v3 20/28] i2c: busses: at91: " Herve Codina
2025-06-13 13:48 ` [PATCH v3 21/28] misc: lan966x_pci: Fix dtso nodes ordering Herve Codina
2025-06-13 13:48 ` [PATCH v3 22/28] misc: lan966x_pci: Split dtso in dtsi/dtso Herve Codina
2025-06-13 13:48 ` [PATCH v3 23/28] misc: lan966x_pci: Rename lan966x_pci.dtso to lan966x_evb_lan9662_nic.dtso Herve Codina
2025-06-13 13:48 ` [PATCH v3 24/28] PCI: Add Microchip LAN9662 PCI Device ID Herve Codina
2025-06-13 21:27 ` Bjorn Helgaas
2025-06-13 13:48 ` [PATCH v3 25/28] misc: lan966x_pci: Introduce board specific data Herve Codina
2025-06-13 13:48 ` [PATCH v3 26/28] misc: lan966x_pci: Add dtsi/dtso nodes in order to support SFPs Herve Codina
2025-06-13 13:48 ` [PATCH v3 27/28] misc: lan966x_pci: Sort the drivers list in Kconfig help Herve Codina
2025-06-13 13:48 ` [PATCH v3 28/28] misc: lan966x_pci: Add drivers needed to support SFPs " Herve Codina
2025-06-27 15:58 ` [PATCH v3 00/28] lan966x pci device: Add support for SFPs Rob Herring
2025-07-03 8:46 ` 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=20250627162245.GA3513535-robh@kernel.org \
--to=robh@kernel.org \
--cc=alison.schofield@intel.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=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--cc=dave@stgolabs.net \
--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=herve.codina@bootlin.com \
--cc=horatiu.vultur@microchip.com \
--cc=imx@lists.linux.dev \
--cc=ira.weiny@intel.com \
--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-cxl@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=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=vishal.l.verma@intel.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.