Re: [PATCH v4 01/29] Revert "treewide: Fix probing of devices in DT overlays"

[Matti Vaittinen]

Hi Dee Ho peeps,

I tried to create a minimal piece of code/dts to demonstrate the issue 
seem in the ROHM automated testing.

On 10/12/2025 14:21, Herve Codina wrote:
> Hi Geert, Kalle, Rob,
>
> On Thu, 4 Dec 2025 11:49:13 +0100
> Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote:

//snip

> When a new node is added, a new device is created. Indeed, because the
> driver is an MFD driver, it is a bus driver and handled by of_platform bus.

We do also have an MFD device - but it is not a platform device but an 
I2C device - thus it should be probed by the I2C bus (if I'm not 
mistaken). So, I guess this is not bus-specific problem.
https://elixir.bootlin.com/linux/v6.18/source/drivers/mfd/rohm-bd718x7.c#L206


> My new node is considered by devlink as a node that will have a device ready
> to work (driver attached and device probed). A link is created between this
> node and the consumers of this node (i.e. the SPI controller). devlink is
> waiting for this provider to be ready before allowing the its consumer to probe.
> This node (simple pinmux description) will never lead to a device and devlink
> will never see this "provider" ready.

I believe Kalle did see the same "probe-not-called" -problem, even when 
disabling the fw_devlink from the kernel commandline. (It's worth 
mentioning that I am not sure if Kalle tried if probe was called with 
"previously working" kernels when fw_devlink is disabled).

> Did a test with a Renesas RZ/N1D (r9a06g032) based board and built a similar
> overlay involving I2C controller pinmux, I2C controller and an EEPROM.
>
> Here, also the overlay didn't work but the issue is different.
>
> The pinmux definition for pinctrl (i.e. pinctrl subnodes) are looked when
> the pinctrl driver probes. Adding a new node later is not handled by the
> pinctrl driver.
> Applying the overlay leads to a simple:
>    [   16.934168] rzn1-pinctrl 40067000.pinctrl: unable to find group for node /soc/pinctrl@40067000/pins_i2c2
>
> Indeed, the 'pins_i2c2' has been added by the overlay and was not present
> when the pinctrl probed.
>
> Tried without adding a new pinmux node (pinctrl subnode) from the overlay
> and used nodes already existing in the base DT.
>
> On my Marvell Armada 3720 board, it works with or without my patches.
> No regression detected due to my patches.
>
> On my RZ/N1D board, it works also with or without my patches.
> Here also, no regression detected.
>
> Also, on my Marvell Armada 3720 board, I can plug my LAN966x PCI board.
> The LAN966x PCI driver used an overlay to describe the LAN966x PCI board.
>
> With the upstream patch not reverted, i.e. 1a50d9403fb9 ("treewide: Fix
> probing of devices in DT overlays")" applied, devlinks created for the
> LAN966x PCI board internal devices are incorrect and lead to crashes when
> the LAN966x PCI driver is removed due to wrong provider/consumer dependencies.
>
> When this patch is reverted and replaced by "of: dynamic: Fix overlayed
> devices not probing because of fw_devlink", devlinks created for the LAN966x
> PCI board internal devices are corrects and crashes are no more present on
> removal.
>
> Kalle, Geert, can you perform a test on your hardware with my patches
> applied and moving your pinmux definition from the overlay to the base
> device-tree?

I got a bit lost regarding which patches to test :)

> The kernel you can use is for instance the kernel at the next-20251127 tag.
> Needed patches for test are present in this kernel:
>      - 76841259ac092 ("of: dynamic: Fix overlayed devices not probing because of fw_devlink")
>      - 7d67ddc5f0148 ("Revert "treewide: Fix probing of devices in DT overlays"")

I did a minimal overlay test which can be ran on beaglebone black. I 
assume the same can be done on any board where you have 
(i2c/spi/xxx)-controller node with status="disabled". Doing this on BBB 
requires recompiling the beaglebone black (base)device-tree with -@ 
though, so that the overlay target nodes are found. I'll attach the 
files for interested.

overlay-test.c:
Is a 'device-driver' for device added in overlay. (simply a probe() with 
print, extracted from the bd71847 driver).

overlay-test.dts:
Is a minimal device-tree overlay describing the 'test device' matching 
above overlay-test driver. When this is overlaid using next-20251121 
(contains the 7d67ddc5f0148b3a03594a45bba5547e92640c89), probe in 
overlay-test.c is not called. When 
7d67ddc5f0148b3a03594a45bba5547e92640c89 is reverted, the probe is called.

mva_overlay.c:
Is simplified 'glue-code' for adding an overlay to running kernel by 
feeding the compiled overlay to the bin_attribute - for example using:

dd if=/overlay-test.dtbo of=/sys/kernel/mva_overlay/overlay_add bs=4M

am335x-boneblack.dtb.dts.tmp and tps65217.dtsi:
are (intermediate) beaglebone-black device-trees which can be recompiled 
to a 'base device-tree' using:

dtc -O dtb -o am335x-boneblack.dtb -b 0 -@ am335x-boneblack.dtb.dts.tmp
 - but I suggest you to use the dts from your kernel build. I provided 
this just for the sake of the completeness.

Makefile:
Off-tree build targets to build the above DTSes and modules. Requires 
KERNEL_DIR and CC to be correctly set.


My findings:
The pinctrl node indeed plays a role. When the "pinctrl-0 = 
<&i2c1_pins>;" (and fragment0) was removed from the dts, the 
'overlay-test' was probed with the "next-20251121".

With the pinctrl node, I see:
[  104.098958] probe of 4802a000.i2c returned -517 (EPROBE_DEFER I 
suppose) after 50 usecs
- and the 'overlay-test' probe is not called.

Yours,
	-- Matti

---
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland

~~ When things go utterly wrong vim users can always type :help! ~~

Attachment: overlay-test.tgz
Description: application/compressed-tar