[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20251211161902.11ef4248@bootlin.com>
Date: Thu, 11 Dec 2025 16:19:02 +0100
From: Herve Codina <herve.codina@...tlin.com>
To: Matti Vaittinen <mazziesaccount@...il.com>, Geert Uytterhoeven
<geert@...ux-m68k.org>, Rob Herring <robh@...nel.org>, "Rafael J. Wysocki"
<rafael@...nel.org>, Ulf Hansson <ulf.hansson@...aro.org>
Cc: Kalle Niemi <kaleposti@...il.com>, linux-arm-kernel@...ts.infradead.org,
Andrew Lunn <andrew@...n.ch>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>, Greg Kroah-Hartman
<gregkh@...uxfoundation.org>, Danilo Krummrich <dakr@...nel.org>, Shawn Guo
<shawnguo@...nel.org>, Sascha Hauer <s.hauer@...gutronix.de>, Pengutronix
Kernel Team <kernel@...gutronix.de>, Fabio Estevam <festevam@...il.com>,
Michael Turquette <mturquette@...libre.com>, Stephen Boyd
<sboyd@...nel.org>, Andi Shyti <andi.shyti@...nel.org>, Wolfram Sang
<wsa+renesas@...g-engineering.com>, Peter Rosin <peda@...ntia.se>, Arnd
Bergmann <arnd@...db.de>, Bjorn Helgaas <bhelgaas@...gle.com>, Charles
Keepax <ckeepax@...nsource.cirrus.com>, Richard Fitzgerald
<rf@...nsource.cirrus.com>, David Rhodes <david.rhodes@...rus.com>, Linus
Walleij <linus.walleij@...aro.org>, Mark Brown <broonie@...nel.org>, Andy
Shevchenko <andriy.shevchenko@...ux.intel.com>, Daniel Scally
<djrscally@...il.com>, Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
Sakari Ailus <sakari.ailus@...ux.intel.com>, Len Brown <lenb@...nel.org>,
Davidlohr Bueso <dave@...olabs.net>, Jonathan Cameron
<jonathan.cameron@...wei.com>, Dave Jiang <dave.jiang@...el.com>, Alison
Schofield <alison.schofield@...el.com>, Vishal Verma
<vishal.l.verma@...el.com>, Ira Weiny <ira.weiny@...el.com>, Dan Williams
<dan.j.williams@...el.com>, Wolfram Sang <wsa@...nel.org>,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
imx@...ts.linux.dev, linux-clk@...r.kernel.org, linux-i2c@...r.kernel.org,
linux-pci@...r.kernel.org, linux-sound@...r.kernel.org,
patches@...nsource.cirrus.com, linux-gpio@...r.kernel.org,
linux-pm@...r.kernel.org, linux-spi@...r.kernel.org,
linux-acpi@...r.kernel.org, linux-cxl@...r.kernel.org, Allan Nielsen
<allan.nielsen@...rochip.com>, Horatiu Vultur
<horatiu.vultur@...rochip.com>, Steen Hegelund
<steen.hegelund@...rochip.com>, Luca Ceresoli <luca.ceresoli@...tlin.com>,
Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Subject: Re: [PATCH v4 01/29] Revert "treewide: Fix probing of devices in DT
overlays"
Hi Matti, Geert, all,
On Thu, 11 Dec 2025 15:52:28 +0200
Matti Vaittinen <mazziesaccount@...il.com> wrote:
> On 11/12/2025 14:20, Herve Codina wrote:
> > Hi Matti,
> >
> > On Thu, 11 Dec 2025 10:34:46 +0200
> > Matti Vaittinen <mazziesaccount@...il.com> wrote:
> >
> /snip
>
> >
> > Do you see the same trace with:
> > - "pinctrl-0 = <&i2c1_pins>;" in your overlay
> > - fragment0 removed from the overlay (i2c1_pins definition removed from
> > the overlay.
> > - i2c1_pins node defined in your base DT.
>
> Just tested. The i2c1 appears and the test-overlay probe gets called,
> when the i2c1_pins is in the base-dt and not in the overlay.
Geert, do you expirement same results?
>
> > In other word, is the issues related to adding a pinctrl sub-node (pinctrl
> > pins definition) in the overlay or is it something else?
>
> Seems to be related to the pinctrl.
>
I don't think that the issue is related to pinctrl itself.
IMHO, I think the issue is related to overlays and fw_devlink.
The distinction between "a new node is going to lead to a device" vs "a new
node is just data and will never been attached to a new device" when an
overlay is applied is broken.
This is broken with the upstream "treewide: Fix probing of devices in DT
overlays" commit I've tried to revert. Indeed, on the LAN966x PCI device
use case devlinks created are not correct with this commit applied.
I am not sure also that devlinks created with a more complex overlay will be
correct. For instance, Matti, with your overlay not sure that a phandle from
the oscillator node referencing the pmic node will lead to a correct
provider/consumer devlink between the pmic device and the oscillator device.
On the other hand, this is broken with "of: dynamic: Fix overlayed devices
not probing because of fw_devlink" works for the LAN966x PCI device use case
an lead to correct devlinks but breaks your use cases.
Does anyone have an idea about how to fix those issues?
Best regards,
Hervé
Powered by blists - more mailing lists