Message-ID: <20251202175836.747593c0@bootlin.com>
Date: Tue, 2 Dec 2025 17:58:36 +0100
From: Herve Codina <herve.codina@...tlin.com>
To: Kalle Niemi <kaleposti@...il.com>, Rob Herring <robh@...nel.org>
Cc: Matti Vaittinen <mazziesaccount@...il.com>, Andrew Lunn
 <andrew@...n.ch>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 "Rafael J. Wysocki" <rafael@...nel.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>, Saravana
 Kannan <saravanak@...gle.com>, 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>, Ulf Hansson <ulf.hansson@...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>, Geert
 Uytterhoeven <geert+renesas@...der.be>, Wolfram Sang <wsa@...nel.org>,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
 imx@...ts.linux.dev, linux-arm-kernel@...ts.infradead.org,
 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 Kalle, Matti,

On Tue, 2 Dec 2025 13:21:16 +0200
Kalle Niemi <kaleposti@...il.com> wrote:

> On 12/2/25 11:26, Herve Codina wrote:
> > Hi Kalle,
> > 
> > On Fri, 28 Nov 2025 10:34:57 +0200
> > Kalle Niemi <kaleposti@...il.com> wrote:
> > 
> > ...  
> >>>>>>>>
> >>>>>>>> Hello,
> >>>>>>>>
> >>>>>>>> Test system testing drivers for ROHM ICs bisected this commit to cause
> >>>>>>>> BD71847 drivers probe to not be called.  
> >>>>>>> This driver (and overlay support) is in linux-next or something out of
> >>>>>>> tree on top of linux-next?
> >>>>>>>
> >>>>>>> Rob  
> >>>>>> Yes the driver is in mainline linux: /drivers/mfd/rohm-bd718x7.c  
> >>>>> I don't see any support to apply overlays in that driver.  
> >>>> Ah. Sorry for the confusion peeps. I asked Kalle to report this without
> >>>> proper consideration. 100% my bad.
> >>>>
> >>>> While the bd718x7 drive indeed is mainline (and tested), the actual
> >>>> 'glue-code' doing the overlay is part of the downstream test
> >>>> infrastructure. So yes, this is not a bug in upstream kernel - this
> >>>> falls in the category of an upstream change causing downstream things to
> >>>> break. So, feel free to say: "Go fix your code" :)
> >>>>
> >>>> Now that this is sorted, if someone is still interested in helping us to
> >>>> get our upstream drivers tested - the downstream piece is just taking
> >>>> the compiled device-tree overlay at runtime (via bin-attribute file),
> >>>> and applying it using the of_overlay_fdt_apply(). The approach is
> >>>> working for our testing purposes when the device is added to I2C/SPI
> >>>> node which is already enabled. However, in case where we have the I2C
> >>>> disabled, and enable it in the same overlay where we add the new device
> >>>> - then the new device does not get probed.
> >>>>
> >>>> I would be really grateful if someone had a pointer for us.  
> >>> Seems to be fw_devlink related. I suppose if you turn it off it works?
> >>> There's info about the dependencies in sysfs or maybe debugfs. I don't
> >>> remember the details, but that should help to tell you why things
> >>> aren't probing.  
> > 
> > Rob reverted patches but I plan to continue my work on it.
> > On my side, I need the reverted patches but I fully understand that, on
> > your side, you need a working system.
> > 
> > In order to move forward and find a solution for my next iteration, can you
> > send your overlay (dtso) used in your working and non working cases?
> > 
> > Best regards,
> > Hervé  
> 
> Hello Hervé,
> 
> I have attached the overlay source file: bd71847_overlay.dts

Thanks a lot for your overlay.

I did an update of the reverted patches and I didn't detect any regression
with the update applied on my use case but I don't have the needed code to
perform tests similar to your use case. Indeed, you apply the overlay using
an out of tree code.

May I ask you to perform a test of this update on your side?

First you can use the last linux-next kernel where reverted patches are present.
The next-20251127 tag is a good candidate. Indeed both patches are present:
  - 76841259ac092 ("of: dynamic: Fix overlayed devices not probing because of fw_devlink")
  - 7d67ddc5f0148 ("Revert "treewide: Fix probing of devices in DT overlays"")

Of course, be sure to have the issue using this kernel with your overlays.

Then can you add the following modification on your faulty kernel:
---- 8< ----
diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c
index 1528d8ad9f26..aea7bb26d9c4 100644
--- a/drivers/of/overlay.c
+++ b/drivers/of/overlay.c
@@ -190,6 +190,20 @@ static void overlay_fw_devlink_refresh(struct overlay_changeset *ovcs)
        for (int i = 0; i < ovcs->count; i++) {
                struct device_node *np = ovcs->fragments[i].target;
 
+               /*
+                * The device related to target node itself could have been
+                * removed and re-added. This happens when the 'status' property
+                * in the target node has been changed by the overlay.
+                *
+                * In that case the parent node needs to be fixed.
+                *
+                * Before fixing the target node itself, fix its parent. To keep
+                * things simple, fix the parent in any case. If nothing needs
+                * to be fixed, fw_devlink_refresh_fwnode() acts as a no-op.
+                */
+               if (np->parent)
+                       fw_devlink_refresh_fwnode(of_fwnode_handle(np->parent));
+
                fw_devlink_refresh_fwnode(of_fwnode_handle(np));
        }
 }
---- 8< ----

My hope is that this modification will fix your issue.
If so, I will add it in my next iteration.

If you cannot perform the test on your side, can you provide me the out of
tree code you use to apply the overlay?

Best regards,
Hervé

Powered by blists - more mailing lists