Message-ID: <20251202182834.65d7f0a1@bootlin.com>
Date: Tue, 2 Dec 2025 18:28:34 +0100
From: Herve Codina <herve.codina@...tlin.com>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: Kalle Niemi <kaleposti@...il.com>, Rob Herring <robh@...nel.org>, 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 Geert,

On Tue, 2 Dec 2025 17:35:35 +0100
Geert Uytterhoeven <geert@...ux-m68k.org> wrote:

> Hi Hervé,
> 
> On Tue, 2 Dec 2025 at 10:26, Herve Codina <herve.codina@...tlin.com> wrote:
> > On Fri, 28 Nov 2025 10:34:57 +0200
> > Kalle Niemi <kaleposti@...il.com> wrote:  
> > > >>>>>> 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?  
> 
> Hmm, I must have missed when Rob applied (part of) this series, as I
> do an overlay test (using the out-of-tree configfs) on top of every
> (bi-weekly) renesas-drivers release, and saw no issues during the last
> few months.
> 
> So I applied this series and tested loading my SPI EEPROM overlay.
> And it indeed breaks, with the culprit being this particular patch.
> 
> Interestingly, quoting from this patch:
> 
>    "While the commit fixed fw_devlink overlay handling for one case, it
>     broke it for another case. So revert it and redo the fix in a separate
>     patch."
> 
> Where is the separate patch that redid the fix? I assume it is "[PATCH
> v4 03/29] of: dynamic: Fix overlayed devices not probing because
> of fw_devlink"?  Unfortunately that doesn't fix the issue for me.
> 
> Quoting more from this patch:
> 
>    "Closes: https://lore.kernel.org/lkml/CAMuHMdXEnSD4rRJ-o90x4OprUacN_rJgyo8x6=9F9rZ+-KzjOg@mail.gmail.com/"
> 
> Strange that it claims to fix the issue reported there, as the failure
> mode I am seeing is exactly the same as documented in that report?
> 
> Do you know what is wrong? The overlay I am using is referenced in
> the bug report linked above.

The first patch "Fix probing of devices in DT overlays" didn't fix all cases
and so Saravana reverted this patch and proposed "of: dynamic: Fix overlayed
devices not probing because of fw_devlink".

This second patch was needed to fix my use case even if more modification were
needed to have my use case fully fixed (other patches in my series).

Rob applied those first patches from my series and some systems were broken.
The breakage has been reported my Kalle and Matti and led to a revert of culprit
patches.

I tried to understand what was wrong. I am pretty convinced that modification
done in "of: dynamic: Fix overlayed devices not probing because of fw_devlink"
are really better than modification available in "treewide: Fix probing of
devices in DT overlays".

I proposed an update [0] and I will be glad if you can also test this update 
on your side and give me your feedback.

[0] https://lore.kernel.org/lkml/20251202175836.747593c0@bootlin.com/

Best regards,
Hervé

Powered by blists - more mailing lists