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 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! ~~