| Message ID | 20230207014207.1678715-1-saravanak@google.com |
|---|---|
| Headers | show |
| Series | fw_devlink improvements | expand |
On Tue, Feb 7, 2023 at 2:42 AM Saravana Kannan <saravanak@google.com> wrote: > The OF_POPULATED flag was set to let fw_devlink know that the device > tree node will not have a struct device created for it. This information > is used by fw_devlink to avoid deferring the probe of consumers of this > device tree node. > > Let's use fwnode_dev_initialized() instead because it achieves the same > effect without using OF specific flags. This allows more generic code to > be written in driver core. > > Signed-off-by: Saravana Kannan <saravanak@google.com> > Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> You've missed my earlier: Acked-by: Geert Uytterhoeven <geert+renesas@glider.be> Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
On Tue, Feb 7, 2023 at 7:28 AM Doug Anderson <dianders@chromium.org> wrote: > > Hi, > > On Mon, Feb 6, 2023 at 5:42 PM Saravana Kannan <saravanak@google.com> wrote: > > > > Naresh, Tony, Abel, Geert, Dmitry, Maxim(s), Miquel, Luca, Doug, Martin, > > Jean-Philippe, > > > > Can I get your Tested-by's for this v3 series please? > > > > Vladimir, > > > > Ccing you because DSA's and fw_devlink have known/existing problems > > (still in my TODOs to fix). But I want to make sure this series doesn't > > cause additional problems for DSA. > > > > All, > > > > This patch series improves fw_devlink in the following ways: > > > > 1. It no longer cares about a fwnode having a "compatible" property. It > > figures this out more dynamically. The only expectation is that > > fwnodes that are converted to devices actually get probed by a driver > > for the dependencies to be enforced correctly. > > > > 2. Finer grained dependency tracking. fw_devlink will now create device > > links from the consumer to the actual resource's device (if it has one, > > Eg: gpio_device) instead of the parent supplier device. This improves > > things like async suspend/resume ordering, potentially remove the need > > for frameworks to create device links, more parallelized async probing, > > and better sync_state() tracking. > > > > 3. Handle hardware/software quirks where a child firmware node gets > > populated as a device before its parent firmware node AND actually > > supplies a non-optional resource to the parent firmware node's > > device. > > > > 4. Way more robust at cycle handling (see patch for the insane cases). > > > > 5. Stops depending on OF_POPULATED to figure out some corner cases. > > > > 6. Simplifies the work that needs to be done by the firmware specific > > code. > > > > The v3 series has gone through my usual testing on my end and looks good > > to me. > > > > Thanks, > > Saravana > > > > [1] - https://lore.kernel.org/lkml/20220810060040.321697-1-saravanak@google.com/ > > [2] - https://lore.kernel.org/lkml/CAGETcx-JUV1nj8wBJrTPfyvM7=Mre5j_vkVmZojeiumUGG6QZQ@mail.gmail.com/ > > > > v1 -> v2: > > - Fixed Patch 1 to handle a corner case discussed in [2]. > > - New patch 10 to handle "fsl,imx8mq-gpc" being initialized by 2 drivers. > > - New patch 11 to add fw_devlink support for SCMI devices. > > > > v2 -> v3: > > - Addressed most of Andy's comments in v2 > > - Added Colin and Sudeep's Tested-by for the series (except the imx and > > renesas patches) > > - Added Sudeep's Acked-by for the scmi patch. > > - Added Geert's Reviewed-by for the renesas patch. > > - Fixed gpiolib crash reported by Naresh. > > - Patch 6: Fix __fwnode_links_move_consumers() to preserve fwnode link flags. > > - New Patch 12 to fix nvmem-cells issue reported by Maxim(s)/Miquel. > > - Deleted some stale function doc in Patch 8 > > > > Cc: Abel Vesa <abel.vesa@linaro.org> > > Cc: Alexander Stein <alexander.stein@ew.tq-group.com> > > Cc: Tony Lindgren <tony@atomide.com> > > Cc: Sudeep Holla <sudeep.holla@arm.com> > > Cc: Geert Uytterhoeven <geert@linux-m68k.org> > > Cc: John Stultz <jstultz@google.com> > > Cc: Doug Anderson <dianders@chromium.org> > > Cc: Guenter Roeck <linux@roeck-us.net> > > Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> > > Cc: Maxim Kiselev <bigunclemax@gmail.com> > > Cc: Maxim Kochetkov <fido_max@inbox.ru> > > Cc: Miquel Raynal <miquel.raynal@bootlin.com> > > Cc: Luca Weiss <luca.weiss@fairphone.com> > > Cc: Colin Foster <colin.foster@in-advantage.com> > > Cc: Martin Kepplinger <martin.kepplinger@puri.sm> > > Cc: Jean-Philippe Brucker <jpb@kernel.org> > > Cc: Vladimir Oltean <vladimir.oltean@nxp.com> > > > > Saravana Kannan (12): > > driver core: fw_devlink: Don't purge child fwnode's consumer links > > driver core: fw_devlink: Improve check for fwnode with no > > device/driver > > soc: renesas: Move away from using OF_POPULATED for fw_devlink > > gpiolib: Clear the gpio_device's fwnode initialized flag before adding > > driver core: fw_devlink: Add DL_FLAG_CYCLE support to device links > > driver core: fw_devlink: Allow marking a fwnode link as being part of > > a cycle > > driver core: fw_devlink: Consolidate device link flag computation > > driver core: fw_devlink: Make cycle detection more robust > > of: property: Simplify of_link_to_phandle() > > irqchip/irq-imx-gpcv2: Mark fwnode device as not initialized > > firmware: arm_scmi: Set fwnode for the scmi_device > > mtd: mtdpart: Don't create platform device that'll never probe > > I tested the whole series together on several devices. I tried to test > on a wide variety since previous versions had broken due to all the > dependency cycles in the display and some of these devices used > different components in their display pipeline. I didn't do massive > testing but did confirm that basic devices came up, including display. > > Devices tested with your v3 applied atop v6.2-rc7-11-g05ecb680708a: > > * sc7180-trogdor-lazor (with ps8640 bridge), which had failed to bring > up the display on v2. > > * sc7180-trogdor-lazor (with sn65dsi86 bridge) > > * sc7180-trogdor-pazquel (with sn65dsi86 bridge) > > * sc7180-trogdor-homestar (with ps8640 bridge) > > * sc7180-trogdor-wormdingler > > * sc7280-herobrine-villager > > Tested-by: Douglas Anderson <dianders@chromium.org> Thanks a lot for all this testing and helping me debug the ps8640 issue Doug! -Saravana
Hi Saravana, On Tue, Feb 7, 2023 at 2:42 AM Saravana Kannan <saravanak@google.com> wrote: > The driver core now: > - Has the parent device of a supplier pick up the consumers if the > supplier never has a device created for it. > - Ignores a supplier if the supplier has no parent device and will never > be probed by a driver > > And already prevents creating a device link with the consumer as a > supplier of a parent. > > So, we no longer need to find the "compatible" node of the supplier or > do any other checks in of_link_to_phandle(). We simply need to make sure > that the supplier is available in DT. > > Signed-off-by: Saravana Kannan <saravanak@google.com> Thanks for your patch! This patch introduces a regression when dynamically loading DT overlays. Unfortunately this happens when using the out-of-tree OF configfs, which is not supported upstream. Still, there may be (obscure) in-tree users. When loading a DT overlay[1] to enable an SPI controller, and instantiate a connected SPI EEPROM: $ overlay add 25lc040 OF: overlay: WARNING: memory leak will occur if overlay removed, property: /keys/status OF: overlay: WARNING: memory leak will occur if overlay removed, property: /soc/spi@e6e90000/pinctrl-0 OF: overlay: WARNING: memory leak will occur if overlay removed, property: /soc/spi@e6e90000/pinctrl-names OF: overlay: WARNING: memory leak will occur if overlay removed, property: /soc/spi@e6e90000/cs-gpios OF: overlay: WARNING: memory leak will occur if overlay removed, property: /soc/spi@e6e90000/status OF: overlay: WARNING: memory leak will occur if overlay removed, property: /__symbols__/msiof0_pins The SPI controller and the SPI EEPROM are no longer instantiated. # cat /sys/kernel/debug/devices_deferred e6e90000.spi platform: wait for supplier msiof0 Let's remove the overlay again: $ overlay rm 25lc040 input: keys as /devices/platform/keys/input/input1 And retry: $ overlay add 25lc040 OF: overlay: WARNING: memory leak will occur if overlay removed, property: /keys/status OF: overlay: WARNING: memory leak will occur if overlay removed, property: /soc/spi@e6e90000/pinctrl-0 OF: overlay: WARNING: memory leak will occur if overlay removed, property: /soc/spi@e6e90000/pinctrl-names OF: overlay: WARNING: memory leak will occur if overlay removed, property: /soc/spi@e6e90000/cs-gpios OF: overlay: WARNING: memory leak will occur if overlay removed, property: /soc/spi@e6e90000/status OF: overlay: WARNING: memory leak will occur if overlay removed, property: /__symbols__/msiof0_pins spi_sh_msiof e6e90000.spi: DMA available spi_sh_msiof e6e90000.spi: registered master spi0 spi spi0.0: setup mode 0, 8 bits/w, 100000 Hz max --> 0 at25 spi0.0: 512 Byte at25 eeprom, pagesize 16 spi_sh_msiof e6e90000.spi: registered child spi0.0 Now it succeeds, and the SPI EEPROM is available, and works. Without this patch, or with this patch reverted after applying the full series: $ overlay add 25lc040 OF: overlay: WARNING: memory leak will occur if overlay removed, property: /keys/status OF: overlay: WARNING: memory leak will occur if overlay removed, property: /soc/spi@e6e90000/pinctrl-0 OF: overlay: WARNING: memory leak will occur if overlay removed, property: /soc/spi@e6e90000/pinctrl-names OF: overlay: WARNING: memory leak will occur if overlay removed, property: /soc/spi@e6e90000/cs-gpios OF: overlay: WARNING: memory leak will occur if overlay removed, property: /soc/spi@e6e90000/status OF: overlay: WARNING: memory leak will occur if overlay removed, property: /__symbols__/msiof0_pins OF: Not linking spi@e6e90000 to interrupt-controller@f1010000 - No struct device spi_sh_msiof e6e90000.spi: DMA available spi_sh_msiof e6e90000.spi: registered master spi0 spi spi0.0: setup mode 0, 8 bits/w, 100000 Hz max --> 0 at25 spi0.0: 444 bps (2 bytes in 9 ticks) at25 spi0.0: 512 Byte at25 eeprom, pagesize 16 spi_sh_msiof e6e90000.spi: registered child spi0.0 The SPI EEPROM is available on the first try after boot. All output is with #define DEBUG in drivers/of/property.c, and with CONFIG_SPI_DEBUG=y. Note that your patch has no impact on drivers/of/unittest.c, as that checks only internal DT structures, not actual device instantiation. Thanks! ;-) [1] https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git/diff/arch/arm64/boot/dts/renesas/r8a77990-ebisu-cn41-msiof0-25lc040.dtso?h=topic/renesas-overlays&id=86d0cf6fa7f191145380485c22f684873c5cce26 Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
On Tue, Feb 7, 2023 at 1:36 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > Hi Saravana, > > On Tue, Feb 7, 2023 at 2:42 AM Saravana Kannan <saravanak@google.com> wrote: > > Naresh, Tony, Abel, Geert, Dmitry, Maxim(s), Miquel, Luca, Doug, Martin, > > Jean-Philippe, > > > > Can I get your Tested-by's for this v3 series please? > > I have tested this on a variety of Renesas arm32/arm64 platforms, > and on several RISC-V platforms. > Apart from the regression related to dynamic overlays caused by > "[PATCH v3 09/12] of: property: Simplify of_link_to_phandle()" > (which you may decide to ignore for now ;-) > Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Thanks a lot for the extensive testing Geert! I'll take a look at that issue with the out of tree code separately. -Saravana -Saravana
On Tue, Feb 7, 2023 at 12:57 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > Hi Saravana, > > On Tue, Feb 7, 2023 at 2:42 AM Saravana Kannan <saravanak@google.com> wrote: > > The driver core now: > > - Has the parent device of a supplier pick up the consumers if the > > supplier never has a device created for it. > > - Ignores a supplier if the supplier has no parent device and will never > > be probed by a driver > > > > And already prevents creating a device link with the consumer as a > > supplier of a parent. > > > > So, we no longer need to find the "compatible" node of the supplier or > > do any other checks in of_link_to_phandle(). We simply need to make sure > > that the supplier is available in DT. > > > > Signed-off-by: Saravana Kannan <saravanak@google.com> > > Thanks for your patch! > > This patch introduces a regression when dynamically loading DT overlays. > Unfortunately this happens when using the out-of-tree OF configfs, > which is not supported upstream. Still, there may be (obscure) > in-tree users. > > When loading a DT overlay[1] to enable an SPI controller, and > instantiate a connected SPI EEPROM: > > $ overlay add 25lc040 > OF: overlay: WARNING: memory leak will occur if overlay removed, > property: /keys/status > OF: overlay: WARNING: memory leak will occur if overlay removed, > property: /soc/spi@e6e90000/pinctrl-0 > OF: overlay: WARNING: memory leak will occur if overlay removed, > property: /soc/spi@e6e90000/pinctrl-names > OF: overlay: WARNING: memory leak will occur if overlay removed, > property: /soc/spi@e6e90000/cs-gpios > OF: overlay: WARNING: memory leak will occur if overlay removed, > property: /soc/spi@e6e90000/status > OF: overlay: WARNING: memory leak will occur if overlay removed, > property: /__symbols__/msiof0_pins > > The SPI controller and the SPI EEPROM are no longer instantiated. > > # cat /sys/kernel/debug/devices_deferred > e6e90000.spi platform: wait for supplier msiof0 > > Let's remove the overlay again: > > $ overlay rm 25lc040 > input: keys as /devices/platform/keys/input/input1 > > And retry: > > $ overlay add 25lc040 > OF: overlay: WARNING: memory leak will occur if overlay removed, > property: /keys/status > OF: overlay: WARNING: memory leak will occur if overlay removed, > property: /soc/spi@e6e90000/pinctrl-0 > OF: overlay: WARNING: memory leak will occur if overlay removed, > property: /soc/spi@e6e90000/pinctrl-names > OF: overlay: WARNING: memory leak will occur if overlay removed, > property: /soc/spi@e6e90000/cs-gpios > OF: overlay: WARNING: memory leak will occur if overlay removed, > property: /soc/spi@e6e90000/status > OF: overlay: WARNING: memory leak will occur if overlay removed, > property: /__symbols__/msiof0_pins > spi_sh_msiof e6e90000.spi: DMA available > spi_sh_msiof e6e90000.spi: registered master spi0 > spi spi0.0: setup mode 0, 8 bits/w, 100000 Hz max --> 0 > at25 spi0.0: 512 Byte at25 eeprom, pagesize 16 > spi_sh_msiof e6e90000.spi: registered child spi0.0 > > Now it succeeds, and the SPI EEPROM is available, and works. > > Without this patch, or with this patch reverted after applying the > full series: > > $ overlay add 25lc040 > OF: overlay: WARNING: memory leak will occur if overlay removed, > property: /keys/status > OF: overlay: WARNING: memory leak will occur if overlay removed, > property: /soc/spi@e6e90000/pinctrl-0 > OF: overlay: WARNING: memory leak will occur if overlay removed, > property: /soc/spi@e6e90000/pinctrl-names > OF: overlay: WARNING: memory leak will occur if overlay removed, > property: /soc/spi@e6e90000/cs-gpios > OF: overlay: WARNING: memory leak will occur if overlay removed, > property: /soc/spi@e6e90000/status > OF: overlay: WARNING: memory leak will occur if overlay removed, > property: /__symbols__/msiof0_pins > OF: Not linking spi@e6e90000 to interrupt-controller@f1010000 - No > struct device > spi_sh_msiof e6e90000.spi: DMA available > spi_sh_msiof e6e90000.spi: registered master spi0 > spi spi0.0: setup mode 0, 8 bits/w, 100000 Hz max --> 0 > at25 spi0.0: 444 bps (2 bytes in 9 ticks) > at25 spi0.0: 512 Byte at25 eeprom, pagesize 16 > spi_sh_msiof e6e90000.spi: registered child spi0.0 > > The SPI EEPROM is available on the first try after boot. Sigh... I spent way too long trying to figure out if I caused a memory leak. I should have scrolled down further! Doesn't look like that part is related to anything I did. There are some flags set to avoid re-parsing fwnodes multiple times. My guess is that the issue you are seeing has to do with how many of the in memory structs are reused vs not when an overlay is applied/removed and some of these flags might not be getting cleared and this is having a bigger impact with this patch (because the fwnode links are no longer anchored on "compatible" nodes). With/without this patch (let's keep the series) can you look at how the following things change between each step you do above (add, remove, retry): 1) List of directories under /sys/class/devlink 2) Enable the debug logs inside __fwnode_link_add(), __fwnode_link_del(), device_link_add() My guess is that the final solution would entail clearing FWNODE_FLAG_LINKS_ADDED for some fwnodes. Thanks, Saravana
Hi Saravana, On Wed, Feb 8, 2023 at 3:08 AM Saravana Kannan <saravanak@google.com> wrote: > On Tue, Feb 7, 2023 at 12:57 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > On Tue, Feb 7, 2023 at 2:42 AM Saravana Kannan <saravanak@google.com> wrote: > > > The driver core now: > > > - Has the parent device of a supplier pick up the consumers if the > > > supplier never has a device created for it. > > > - Ignores a supplier if the supplier has no parent device and will never > > > be probed by a driver > > > > > > And already prevents creating a device link with the consumer as a > > > supplier of a parent. > > > > > > So, we no longer need to find the "compatible" node of the supplier or > > > do any other checks in of_link_to_phandle(). We simply need to make sure > > > that the supplier is available in DT. > > > > > > Signed-off-by: Saravana Kannan <saravanak@google.com> > > > > Thanks for your patch! > > > > This patch introduces a regression when dynamically loading DT overlays. > > Unfortunately this happens when using the out-of-tree OF configfs, > > which is not supported upstream. Still, there may be (obscure) > > in-tree users. > > > > When loading a DT overlay[1] to enable an SPI controller, and > > instantiate a connected SPI EEPROM: > > > > $ overlay add 25lc040 > > OF: overlay: WARNING: memory leak will occur if overlay removed, > > property: /keys/status > > OF: overlay: WARNING: memory leak will occur if overlay removed, > > property: /soc/spi@e6e90000/pinctrl-0 > > OF: overlay: WARNING: memory leak will occur if overlay removed, > > property: /soc/spi@e6e90000/pinctrl-names > > OF: overlay: WARNING: memory leak will occur if overlay removed, > > property: /soc/spi@e6e90000/cs-gpios > > OF: overlay: WARNING: memory leak will occur if overlay removed, > > property: /soc/spi@e6e90000/status > > OF: overlay: WARNING: memory leak will occur if overlay removed, > > property: /__symbols__/msiof0_pins > > > > The SPI controller and the SPI EEPROM are no longer instantiated. > > > > # cat /sys/kernel/debug/devices_deferred > > e6e90000.spi platform: wait for supplier msiof0 > > > > Let's remove the overlay again: > > > > $ overlay rm 25lc040 > > input: keys as /devices/platform/keys/input/input1 > > > > And retry: > > > > $ overlay add 25lc040 > > OF: overlay: WARNING: memory leak will occur if overlay removed, > > property: /keys/status > > OF: overlay: WARNING: memory leak will occur if overlay removed, > > property: /soc/spi@e6e90000/pinctrl-0 > > OF: overlay: WARNING: memory leak will occur if overlay removed, > > property: /soc/spi@e6e90000/pinctrl-names > > OF: overlay: WARNING: memory leak will occur if overlay removed, > > property: /soc/spi@e6e90000/cs-gpios > > OF: overlay: WARNING: memory leak will occur if overlay removed, > > property: /soc/spi@e6e90000/status > > OF: overlay: WARNING: memory leak will occur if overlay removed, > > property: /__symbols__/msiof0_pins > > spi_sh_msiof e6e90000.spi: DMA available > > spi_sh_msiof e6e90000.spi: registered master spi0 > > spi spi0.0: setup mode 0, 8 bits/w, 100000 Hz max --> 0 > > at25 spi0.0: 512 Byte at25 eeprom, pagesize 16 > > spi_sh_msiof e6e90000.spi: registered child spi0.0 > > > > Now it succeeds, and the SPI EEPROM is available, and works. > > > > Without this patch, or with this patch reverted after applying the > > full series: > > > > $ overlay add 25lc040 > > OF: overlay: WARNING: memory leak will occur if overlay removed, > > property: /keys/status > > OF: overlay: WARNING: memory leak will occur if overlay removed, > > property: /soc/spi@e6e90000/pinctrl-0 > > OF: overlay: WARNING: memory leak will occur if overlay removed, > > property: /soc/spi@e6e90000/pinctrl-names > > OF: overlay: WARNING: memory leak will occur if overlay removed, > > property: /soc/spi@e6e90000/cs-gpios > > OF: overlay: WARNING: memory leak will occur if overlay removed, > > property: /soc/spi@e6e90000/status > > OF: overlay: WARNING: memory leak will occur if overlay removed, > > property: /__symbols__/msiof0_pins > > OF: Not linking spi@e6e90000 to interrupt-controller@f1010000 - No > > struct device > > spi_sh_msiof e6e90000.spi: DMA available > > spi_sh_msiof e6e90000.spi: registered master spi0 > > spi spi0.0: setup mode 0, 8 bits/w, 100000 Hz max --> 0 > > at25 spi0.0: 444 bps (2 bytes in 9 ticks) > > at25 spi0.0: 512 Byte at25 eeprom, pagesize 16 > > spi_sh_msiof e6e90000.spi: registered child spi0.0 > > > > The SPI EEPROM is available on the first try after boot. > > Sigh... I spent way too long trying to figure out if I caused a memory > leak. I should have scrolled down further! Doesn't look like that part > is related to anything I did. Please ignore the memory leak messages. They are known issues in the upstream DT overlay code, and not related to your series. > There are some flags set to avoid re-parsing fwnodes multiple times. > My guess is that the issue you are seeing has to do with how many of > the in memory structs are reused vs not when an overlay is > applied/removed and some of these flags might not be getting cleared > and this is having a bigger impact with this patch (because the fwnode > links are no longer anchored on "compatible" nodes). > > With/without this patch (let's keep the series) can you look at how > the following things change between each step you do above (add, > remove, retry): > 1) List of directories under /sys/class/devlink > 2) Enable the debug logs inside __fwnode_link_add(), > __fwnode_link_del(), device_link_add() Thanks, I'll give that a try, later... Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
On Tue, Feb 7, 2023 at 6:08 PM Saravana Kannan <saravanak@google.com> wrote: > > On Tue, Feb 7, 2023 at 12:57 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > > > Hi Saravana, > > > > On Tue, Feb 7, 2023 at 2:42 AM Saravana Kannan <saravanak@google.com> wrote: > > > The driver core now: > > > - Has the parent device of a supplier pick up the consumers if the > > > supplier never has a device created for it. > > > - Ignores a supplier if the supplier has no parent device and will never > > > be probed by a driver > > > > > > And already prevents creating a device link with the consumer as a > > > supplier of a parent. > > > > > > So, we no longer need to find the "compatible" node of the supplier or > > > do any other checks in of_link_to_phandle(). We simply need to make sure > > > that the supplier is available in DT. > > > > > > Signed-off-by: Saravana Kannan <saravanak@google.com> > > > > Thanks for your patch! > > > > This patch introduces a regression when dynamically loading DT overlays. > > Unfortunately this happens when using the out-of-tree OF configfs, > > which is not supported upstream. Still, there may be (obscure) > > in-tree users. > > > > When loading a DT overlay[1] to enable an SPI controller, and > > instantiate a connected SPI EEPROM: > > > > $ overlay add 25lc040 > > OF: overlay: WARNING: memory leak will occur if overlay removed, > > property: /keys/status > > OF: overlay: WARNING: memory leak will occur if overlay removed, > > property: /soc/spi@e6e90000/pinctrl-0 > > OF: overlay: WARNING: memory leak will occur if overlay removed, > > property: /soc/spi@e6e90000/pinctrl-names > > OF: overlay: WARNING: memory leak will occur if overlay removed, > > property: /soc/spi@e6e90000/cs-gpios > > OF: overlay: WARNING: memory leak will occur if overlay removed, > > property: /soc/spi@e6e90000/status > > OF: overlay: WARNING: memory leak will occur if overlay removed, > > property: /__symbols__/msiof0_pins > > > > The SPI controller and the SPI EEPROM are no longer instantiated. > > > > # cat /sys/kernel/debug/devices_deferred > > e6e90000.spi platform: wait for supplier msiof0 > > > > Let's remove the overlay again: > > > > $ overlay rm 25lc040 > > input: keys as /devices/platform/keys/input/input1 > > > > And retry: > > > > $ overlay add 25lc040 > > OF: overlay: WARNING: memory leak will occur if overlay removed, > > property: /keys/status > > OF: overlay: WARNING: memory leak will occur if overlay removed, > > property: /soc/spi@e6e90000/pinctrl-0 > > OF: overlay: WARNING: memory leak will occur if overlay removed, > > property: /soc/spi@e6e90000/pinctrl-names > > OF: overlay: WARNING: memory leak will occur if overlay removed, > > property: /soc/spi@e6e90000/cs-gpios > > OF: overlay: WARNING: memory leak will occur if overlay removed, > > property: /soc/spi@e6e90000/status > > OF: overlay: WARNING: memory leak will occur if overlay removed, > > property: /__symbols__/msiof0_pins > > spi_sh_msiof e6e90000.spi: DMA available > > spi_sh_msiof e6e90000.spi: registered master spi0 > > spi spi0.0: setup mode 0, 8 bits/w, 100000 Hz max --> 0 > > at25 spi0.0: 512 Byte at25 eeprom, pagesize 16 > > spi_sh_msiof e6e90000.spi: registered child spi0.0 > > > > Now it succeeds, and the SPI EEPROM is available, and works. > > > > Without this patch, or with this patch reverted after applying the > > full series: > > > > $ overlay add 25lc040 > > OF: overlay: WARNING: memory leak will occur if overlay removed, > > property: /keys/status > > OF: overlay: WARNING: memory leak will occur if overlay removed, > > property: /soc/spi@e6e90000/pinctrl-0 > > OF: overlay: WARNING: memory leak will occur if overlay removed, > > property: /soc/spi@e6e90000/pinctrl-names > > OF: overlay: WARNING: memory leak will occur if overlay removed, > > property: /soc/spi@e6e90000/cs-gpios > > OF: overlay: WARNING: memory leak will occur if overlay removed, > > property: /soc/spi@e6e90000/status > > OF: overlay: WARNING: memory leak will occur if overlay removed, > > property: /__symbols__/msiof0_pins > > OF: Not linking spi@e6e90000 to interrupt-controller@f1010000 - No > > struct device > > spi_sh_msiof e6e90000.spi: DMA available > > spi_sh_msiof e6e90000.spi: registered master spi0 > > spi spi0.0: setup mode 0, 8 bits/w, 100000 Hz max --> 0 > > at25 spi0.0: 444 bps (2 bytes in 9 ticks) > > at25 spi0.0: 512 Byte at25 eeprom, pagesize 16 > > spi_sh_msiof e6e90000.spi: registered child spi0.0 > > > > The SPI EEPROM is available on the first try after boot. > > Sigh... I spent way too long trying to figure out if I caused a memory > leak. I should have scrolled down further! Doesn't look like that part > is related to anything I did. > > There are some flags set to avoid re-parsing fwnodes multiple times. > My guess is that the issue you are seeing has to do with how many of > the in memory structs are reused vs not when an overlay is > applied/removed and some of these flags might not be getting cleared > and this is having a bigger impact with this patch (because the fwnode > links are no longer anchored on "compatible" nodes). > > With/without this patch (let's keep the series) can you look at how > the following things change between each step you do above (add, > remove, retry): > 1) List of directories under /sys/class/devlink > 2) Enable the debug logs inside __fwnode_link_add(), > __fwnode_link_del(), device_link_add() > > My guess is that the final solution would entail clearing > FWNODE_FLAG_LINKS_ADDED for some fwnodes. You replied just as I was about to hit send. So sending this anyway... Ok, I took a closer look and I think it's a bit of a mess. The fact that it even worked for you without this patch is a bit of a coincidence. Let's just take platform devices that are created by driver/of/platform.c as an example. The main problem is that when you add/remove properties to a DT node of an existing platform device, nothing is really done about it at the device level. We don't even unbind and rebind the driver so the driver could make use of the new properties. We don't remove and add back the device so whoever might use the new property will use it. And if you are adding a new node, it'll only trigger any platform device level impact if it's a new node of a "simple-bus" (or similar bus) device. Problem 1: So if you add a new child node to an existing probed device that adds its children explicitly (as in, the parent is not a "simple-bus" like device), nothing will happen. The newly added child device node will get converted into a platform device, not will the parent device notice it. So in your case of adding msiof0_pins, it's just that when the consumer gets the pins, the driver doesn't get involved much and it's the pinctrl framework that reads the DT and figures it out. With this patch, the fwnode links point to the actual resource and the actual parent device inherits them if they don't get converted to a struct device. But since we are adding this msiof0_pins after the parent device has probed, the fwnode link isn't inherited by the parent pinctrl device. Problem 2: So if you add a property to an already bound device, nothing is done by the driver. In your overlay example, if you move the status="okay" line to be the first property you change in the msiof0 spi device, you'll probably see that fw_devlink is no longer the one blocking the probe. This is because the platform device will get added as soon as the status flips from disabled to enabled and at that point fw_devlink will think it has no suppliers and won't do any probe deferring. And then as the new properties get added nothing will happen at the device or fw_devlink level. If the msiof0's spi driver fails immediately with NOT -EPROBE_DEFER when platform device is added because it couldn't find any pinctrl property, then msiof0 will never probe (unless you remove and add the driver). If it had failed with -EPROBE_DEFER, then it might probe again if something else triggers a deferred probe attempt. Clearly, things working/not working based on the order of properties in DT is not a good implementation. Problem 3: What if you enable a previously disabled supplier. There's no way to handle that from a fw_devlink level without re-parsing the entire device tree because existing devices might be consumers now. Anyway, long story short, it's sorta worked due to coincidence and it's quite messy to get it to work correctly. Another way to get this to work is to: 1) unload pinctrl driver, unload spi driver. 2) apply overlay 3) reload pinctrl driver, reload spi driver. This is assuming unloading those 2 drivers doesn't crash your system. In terms of difficult + inefficiency of solving the problems, the easiest/efficient to hardest/inefficient would be problem 1, 2 and then 3. I'll think about them, but it's broken anyway without the series/patch. The only real guarantee as of today is that we aren't leaking any memory or corrupting anything. -Saravana
On Tue, Feb 07, 2023 at 09:57:14PM +0100, Geert Uytterhoeven wrote: > Hi Saravana, > > On Tue, Feb 7, 2023 at 2:42 AM Saravana Kannan <saravanak@google.com> wrote: > > The driver core now: > > - Has the parent device of a supplier pick up the consumers if the > > supplier never has a device created for it. > > - Ignores a supplier if the supplier has no parent device and will never > > be probed by a driver > > > > And already prevents creating a device link with the consumer as a > > supplier of a parent. > > > > So, we no longer need to find the "compatible" node of the supplier or > > do any other checks in of_link_to_phandle(). We simply need to make sure > > that the supplier is available in DT. > > > > Signed-off-by: Saravana Kannan <saravanak@google.com> > > Thanks for your patch! > > This patch introduces a regression when dynamically loading DT overlays. > Unfortunately this happens when using the out-of-tree OF configfs, > which is not supported upstream. Still, there may be (obscure) > in-tree users. As we can't do anything about out-of-tree code, why does this matter? thanks, greg k-h
Hi Greg, On Wed, Feb 8, 2023 at 8:33 AM Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > On Tue, Feb 07, 2023 at 09:57:14PM +0100, Geert Uytterhoeven wrote: > > On Tue, Feb 7, 2023 at 2:42 AM Saravana Kannan <saravanak@google.com> wrote: > > > The driver core now: > > > - Has the parent device of a supplier pick up the consumers if the > > > supplier never has a device created for it. > > > - Ignores a supplier if the supplier has no parent device and will never > > > be probed by a driver > > > > > > And already prevents creating a device link with the consumer as a > > > supplier of a parent. > > > > > > So, we no longer need to find the "compatible" node of the supplier or > > > do any other checks in of_link_to_phandle(). We simply need to make sure > > > that the supplier is available in DT. > > > > > > Signed-off-by: Saravana Kannan <saravanak@google.com> > > > > Thanks for your patch! > > > > This patch introduces a regression when dynamically loading DT overlays. > > Unfortunately this happens when using the out-of-tree OF configfs, > > which is not supported upstream. Still, there may be (obscure) > > in-tree users. > > As we can't do anything about out-of-tree code, why does this matter? Because the actual DT overlay mechanism is upstream. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
Hi Saravana, On Wed, Feb 8, 2023 at 8:32 AM Saravana Kannan <saravanak@google.com> wrote: > On Tue, Feb 7, 2023 at 6:08 PM Saravana Kannan <saravanak@google.com> wrote: > > On Tue, Feb 7, 2023 at 12:57 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > > On Tue, Feb 7, 2023 at 2:42 AM Saravana Kannan <saravanak@google.com> wrote: > > > > The driver core now: > > > > - Has the parent device of a supplier pick up the consumers if the > > > > supplier never has a device created for it. > > > > - Ignores a supplier if the supplier has no parent device and will never > > > > be probed by a driver > > > > > > > > And already prevents creating a device link with the consumer as a > > > > supplier of a parent. > > > > > > > > So, we no longer need to find the "compatible" node of the supplier or > > > > do any other checks in of_link_to_phandle(). We simply need to make sure > > > > that the supplier is available in DT. > > > > > > > > Signed-off-by: Saravana Kannan <saravanak@google.com> > > > > > > Thanks for your patch! > > > > > > This patch introduces a regression when dynamically loading DT overlays. > > > Unfortunately this happens when using the out-of-tree OF configfs, > > > which is not supported upstream. Still, there may be (obscure) > > > in-tree users. > > > > > > When loading a DT overlay[1] to enable an SPI controller, and > > > instantiate a connected SPI EEPROM: [...] > > > The SPI controller and the SPI EEPROM are no longer instantiated. > > Sigh... I spent way too long trying to figure out if I caused a memory > > leak. I should have scrolled down further! Doesn't look like that part > > is related to anything I did. > > > > There are some flags set to avoid re-parsing fwnodes multiple times. > > My guess is that the issue you are seeing has to do with how many of > > the in memory structs are reused vs not when an overlay is > > applied/removed and some of these flags might not be getting cleared > > and this is having a bigger impact with this patch (because the fwnode > > links are no longer anchored on "compatible" nodes). > > > > With/without this patch (let's keep the series) can you look at how > > the following things change between each step you do above (add, > > remove, retry): > > 1) List of directories under /sys/class/devlink > > 2) Enable the debug logs inside __fwnode_link_add(), > > __fwnode_link_del(), device_link_add() > > > > My guess is that the final solution would entail clearing > > FWNODE_FLAG_LINKS_ADDED for some fwnodes. > > You replied just as I was about to hit send. So sending this anyway... > > Ok, I took a closer look and I think it's a bit of a mess. The fact > that it even worked for you without this patch is a bit of a > coincidence. > > Let's just take platform devices that are created by > driver/of/platform.c as an example. > > The main problem is that when you add/remove properties to a DT node > of an existing platform device, nothing is really done about it at the > device level. We don't even unbind and rebind the driver so the driver > could make use of the new properties. We don't remove and add back the > device so whoever might use the new property will use it. And if you > are adding a new node, it'll only trigger any platform device level > impact if it's a new node of a "simple-bus" (or similar bus) device. > > Problem 1: > So if you add a new child node to an existing probed device that adds > its children explicitly (as in, the parent is not a "simple-bus" like > device), nothing will happen. The newly added child device node will > get converted into a platform device, not will the parent device > notice it. So in your case of adding msiof0_pins, it's just that when > the consumer gets the pins, the driver doesn't get involved much and > it's the pinctrl framework that reads the DT and figures it out. > > With this patch, the fwnode links point to the actual resource and the > actual parent device inherits them if they don't get converted to a > struct device. But since we are adding this msiof0_pins after the > parent device has probed, the fwnode link isn't inherited by the > parent pinctrl device. > > Problem 2: > So if you add a property to an already bound device, nothing is done > by the driver. In your overlay example, if you move the status="okay" > line to be the first property you change in the msiof0 spi device, > you'll probably see that fw_devlink is no longer the one blocking the > probe. This is because the platform device will get added as soon as > the status flips from disabled to enabled and at that point fw_devlink > will think it has no suppliers and won't do any probe deferring. And > then as the new properties get added nothing will happen at the device > or fw_devlink level. If the msiof0's spi driver fails immediately with > NOT -EPROBE_DEFER when platform device is added because it couldn't > find any pinctrl property, then msiof0 will never probe (unless you > remove and add the driver). If it had failed with -EPROBE_DEFER, then > it might probe again if something else triggers a deferred probe > attempt. Clearly, things working/not working based on the order of > properties in DT is not a good implementation. > > Problem 3: > What if you enable a previously disabled supplier. There's no way to > handle that from a fw_devlink level without re-parsing the entire > device tree because existing devices might be consumers now. > > Anyway, long story short, it's sorta worked due to coincidence and > it's quite messy to get it to work correctly. Several subsystems register notifiers to be informed of the events above. E.g. drivers/spi/spi.c: if (IS_ENABLED(CONFIG_OF_DYNAMIC)) WARN_ON(of_reconfig_notifier_register(&spi_of_notifier)); if (IS_ENABLED(CONFIG_ACPI)) WARN_ON(acpi_reconfig_notifier_register(&spi_acpi_notifier)); So my issue might be triggered using ACPI, too. > Another way to get this to work is to: > 1) unload pinctrl driver, unload spi driver. > 2) apply overlay > 3) reload pinctrl driver, reload spi driver. > > This is assuming unloading those 2 drivers doesn't crash your system. Unloading the pinctrl driver is not an option. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
On Tue, Feb 7, 2023 at 11:57 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > Hi Saravana, > > On Wed, Feb 8, 2023 at 8:32 AM Saravana Kannan <saravanak@google.com> wrote: > > On Tue, Feb 7, 2023 at 6:08 PM Saravana Kannan <saravanak@google.com> wrote: > > > On Tue, Feb 7, 2023 at 12:57 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > > > On Tue, Feb 7, 2023 at 2:42 AM Saravana Kannan <saravanak@google.com> wrote: > > > > > The driver core now: > > > > > - Has the parent device of a supplier pick up the consumers if the > > > > > supplier never has a device created for it. > > > > > - Ignores a supplier if the supplier has no parent device and will never > > > > > be probed by a driver > > > > > > > > > > And already prevents creating a device link with the consumer as a > > > > > supplier of a parent. > > > > > > > > > > So, we no longer need to find the "compatible" node of the supplier or > > > > > do any other checks in of_link_to_phandle(). We simply need to make sure > > > > > that the supplier is available in DT. > > > > > > > > > > Signed-off-by: Saravana Kannan <saravanak@google.com> > > > > > > > > Thanks for your patch! > > > > > > > > This patch introduces a regression when dynamically loading DT overlays. > > > > Unfortunately this happens when using the out-of-tree OF configfs, > > > > which is not supported upstream. Still, there may be (obscure) > > > > in-tree users. > > > > > > > > When loading a DT overlay[1] to enable an SPI controller, and > > > > instantiate a connected SPI EEPROM: > > [...] > > > > > The SPI controller and the SPI EEPROM are no longer instantiated. > > > > Sigh... I spent way too long trying to figure out if I caused a memory > > > leak. I should have scrolled down further! Doesn't look like that part > > > is related to anything I did. > > > > > > There are some flags set to avoid re-parsing fwnodes multiple times. > > > My guess is that the issue you are seeing has to do with how many of > > > the in memory structs are reused vs not when an overlay is > > > applied/removed and some of these flags might not be getting cleared > > > and this is having a bigger impact with this patch (because the fwnode > > > links are no longer anchored on "compatible" nodes). > > > > > > With/without this patch (let's keep the series) can you look at how > > > the following things change between each step you do above (add, > > > remove, retry): > > > 1) List of directories under /sys/class/devlink > > > 2) Enable the debug logs inside __fwnode_link_add(), > > > __fwnode_link_del(), device_link_add() > > > > > > My guess is that the final solution would entail clearing > > > FWNODE_FLAG_LINKS_ADDED for some fwnodes. > > > > You replied just as I was about to hit send. So sending this anyway... > > > > Ok, I took a closer look and I think it's a bit of a mess. The fact > > that it even worked for you without this patch is a bit of a > > coincidence. > > > > Let's just take platform devices that are created by > > driver/of/platform.c as an example. > > > > The main problem is that when you add/remove properties to a DT node > > of an existing platform device, nothing is really done about it at the > > device level. We don't even unbind and rebind the driver so the driver > > could make use of the new properties. We don't remove and add back the > > device so whoever might use the new property will use it. And if you > > are adding a new node, it'll only trigger any platform device level > > impact if it's a new node of a "simple-bus" (or similar bus) device. > > > > Problem 1: > > So if you add a new child node to an existing probed device that adds > > its children explicitly (as in, the parent is not a "simple-bus" like > > device), nothing will happen. The newly added child device node will > > get converted into a platform device, not will the parent device > > notice it. So in your case of adding msiof0_pins, it's just that when > > the consumer gets the pins, the driver doesn't get involved much and > > it's the pinctrl framework that reads the DT and figures it out. > > > > With this patch, the fwnode links point to the actual resource and the > > actual parent device inherits them if they don't get converted to a > > struct device. But since we are adding this msiof0_pins after the > > parent device has probed, the fwnode link isn't inherited by the > > parent pinctrl device. > > > > Problem 2: > > So if you add a property to an already bound device, nothing is done > > by the driver. In your overlay example, if you move the status="okay" > > line to be the first property you change in the msiof0 spi device, > > you'll probably see that fw_devlink is no longer the one blocking the > > probe. This is because the platform device will get added as soon as > > the status flips from disabled to enabled and at that point fw_devlink > > will think it has no suppliers and won't do any probe deferring. And > > then as the new properties get added nothing will happen at the device > > or fw_devlink level. If the msiof0's spi driver fails immediately with > > NOT -EPROBE_DEFER when platform device is added because it couldn't > > find any pinctrl property, then msiof0 will never probe (unless you > > remove and add the driver). If it had failed with -EPROBE_DEFER, then > > it might probe again if something else triggers a deferred probe > > attempt. Clearly, things working/not working based on the order of > > properties in DT is not a good implementation. > > > > Problem 3: > > What if you enable a previously disabled supplier. There's no way to > > handle that from a fw_devlink level without re-parsing the entire > > device tree because existing devices might be consumers now. > > > > Anyway, long story short, it's sorta worked due to coincidence and > > it's quite messy to get it to work correctly. > > Several subsystems register notifiers to be informed of the events > above. E.g. drivers/spi/spi.c: > > if (IS_ENABLED(CONFIG_OF_DYNAMIC)) > WARN_ON(of_reconfig_notifier_register(&spi_of_notifier)); > if (IS_ENABLED(CONFIG_ACPI)) > WARN_ON(acpi_reconfig_notifier_register(&spi_acpi_notifier)); > > So my issue might be triggered using ACPI, too. Yeah, I did notice this before my email. Here's an ugly hack (at end of email) to test my theory about Problem 1. I didn't compile test it (because I should go to bed now), but you get the idea. Can you give this a shot? It should fix your specific case. Basically for all overlays (I hope the function is only used for overlays) we assume all nodes are NOT devices until they actually get added as a device. Don't review the code, it's not meant to be :) -Saravana --- a/drivers/of/dynamic.c +++ b/drivers/of/dynamic.c @@ -226,6 +226,7 @@ static void __of_attach_node(struct device_node *np) np->sibling = np->parent->child; np->parent->child = np; of_node_clear_flag(np, OF_DETACHED); + np->fwnode.flags |= FWNODE_FLAG_NOT_DEVICE; } /** diff --git a/drivers/of/platform.c b/drivers/of/platform.c index 81c8c227ab6b..7299cd668e51 100644 --- a/drivers/of/platform.c +++ b/drivers/of/platform.c @@ -732,6 +732,7 @@ static int of_platform_notify(struct notifier_block *nb, if (of_node_check_flag(rd->dn, OF_POPULATED)) return NOTIFY_OK; + rd->dn->fwnode.flags &= ~FWNODE_FLAG_NOT_DEVICE; /* pdev_parent may be NULL when no bus platform device */ pdev_parent = of_find_device_by_node(rd->dn->parent); pdev = of_platform_device_create(rd->dn, NULL, diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c index 15f174f4e056..1de55561b25d 100644 --- a/drivers/spi/spi.c +++ b/drivers/spi/spi.c @@ -4436,6 +4436,7 @@ static int of_spi_notify(struct notifier_block *nb, unsigned long action, return NOTIFY_OK; } + rd->dn->fwnode.flags &= ~FWNODE_FLAG_NOT_DEVICE; spi = of_register_spi_device(ctlr, rd->dn); put_device(&ctlr->dev);
On Tue, Feb 07, 2023 at 11:31:57PM -0800, Saravana Kannan wrote: > On Tue, Feb 7, 2023 at 6:08 PM Saravana Kannan <saravanak@google.com> wrote: ... > Another way to get this to work is to: > 1) unload pinctrl driver, unload spi driver. > 2) apply overlay > 3) reload pinctrl driver, reload spi driver. > > This is assuming unloading those 2 drivers doesn't crash your system. Just a side note. For ACPI case the ACPICA prevents appearing of the same device in the namespace, so the above is kinda enforced, that's why overlays work better there (but have a lot of limitations).
Hi Saravana, On Mon, Feb 06, 2023 at 05:41:52PM -0800, Saravana Kannan wrote: > Vladimir, > > Ccing you because DSA's and fw_devlink have known/existing problems > (still in my TODOs to fix). But I want to make sure this series doesn't > cause additional problems for DSA. > > All, > > This patch series improves fw_devlink in the following ways: > > 1. It no longer cares about a fwnode having a "compatible" property. It > figures this out more dynamically. The only expectation is that > fwnodes that are converted to devices actually get probed by a driver > for the dependencies to be enforced correctly. > > 2. Finer grained dependency tracking. fw_devlink will now create device > links from the consumer to the actual resource's device (if it has one, > Eg: gpio_device) instead of the parent supplier device. This improves > things like async suspend/resume ordering, potentially remove the need > for frameworks to create device links, more parallelized async probing, > and better sync_state() tracking. > > 3. Handle hardware/software quirks where a child firmware node gets > populated as a device before its parent firmware node AND actually > supplies a non-optional resource to the parent firmware node's > device. > > 4. Way more robust at cycle handling (see patch for the insane cases). > > 5. Stops depending on OF_POPULATED to figure out some corner cases. > > 6. Simplifies the work that needs to be done by the firmware specific > code. > > The v3 series has gone through my usual testing on my end and looks good > to me. Booted on an NXP LS1028A (arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts) and a Turris MOX (arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts) with no observed regressions. Is there something specific you would like me to test?
On Fri, Feb 10, 2023 at 11:27:11AM -0800, Saravana Kannan wrote: > On Fri, Feb 10, 2023 at 2:13 AM Vladimir Oltean <vladimir.oltean@nxp.com> wrote: > > > > Hi Saravana, > > > > On Mon, Feb 06, 2023 at 05:41:52PM -0800, Saravana Kannan wrote: > > > Vladimir, > > > > > > Ccing you because DSA's and fw_devlink have known/existing problems > > > (still in my TODOs to fix). But I want to make sure this series doesn't > > > cause additional problems for DSA. > > > > > > All, > > > > > > This patch series improves fw_devlink in the following ways: > > > > > > 1. It no longer cares about a fwnode having a "compatible" property. It > > > figures this out more dynamically. The only expectation is that > > > fwnodes that are converted to devices actually get probed by a driver > > > for the dependencies to be enforced correctly. > > > > > > 2. Finer grained dependency tracking. fw_devlink will now create device > > > links from the consumer to the actual resource's device (if it has one, > > > Eg: gpio_device) instead of the parent supplier device. This improves > > > things like async suspend/resume ordering, potentially remove the need > > > for frameworks to create device links, more parallelized async probing, > > > and better sync_state() tracking. > > > > > > 3. Handle hardware/software quirks where a child firmware node gets > > > populated as a device before its parent firmware node AND actually > > > supplies a non-optional resource to the parent firmware node's > > > device. > > > > > > 4. Way more robust at cycle handling (see patch for the insane cases). > > > > > > 5. Stops depending on OF_POPULATED to figure out some corner cases. > > > > > > 6. Simplifies the work that needs to be done by the firmware specific > > > code. > > > > > > The v3 series has gone through my usual testing on my end and looks good > > > to me. > > > > Booted on an NXP LS1028A (arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts) > > and a Turris MOX (arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts) > > with no observed regressions. > > Thanks for testing Vladimir! > > > Is there something specific you would like > > me to test? > > Not really, I just want to make sure the common DSA architectures > don't hit any regression. In the hardware you tested, are there cases > of PHYs where the supplier is the parent MDIO? I remember that being > the only case where I needed special casing > (FWNODE_FLAG_NEEDS_CHILD_BOUND_ON_ADD) in fw_devlink -- so it'll be > good to make sure I didn't accidentally break anything there. > > -Saravana Yes and no (I never had a system which depended on FWNODE_FLAG_NEEDS_CHILD_BOUND_ON_ADD). Yes, because well, yes, in arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts, the PHYs will depend on interrupts provided by their (parent) switch. However this is not explicit in the device tree. To make it explicit, one would need to add: diff --git a/arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts b/arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts index cd0988317623..d789cda49e35 100644 --- a/arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts +++ b/arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts @@ -305,12 +305,14 @@ phy1: ethernet-phy@1 { }; /* switch nodes are enabled by U-Boot if modules are present */ - switch0@10 { + switch0_peridot: switch0@10 { compatible = "marvell,mv88e6190"; reg = <0x10>; dsa,member = <0 0>; interrupt-parent = <&moxtet>; interrupts = <MOXTET_IRQ_PERIDOT(0)>; + interrupt-controller; + #interrupt-cells = <2>; status = "disabled"; mdio { @@ -319,34 +321,42 @@ mdio { switch0phy1: switch0phy1@1 { reg = <0x1>; + interrupts-extended = <&switch0_peridot 1 IRQ_TYPE_LEVEL_HIGH>; }; switch0phy2: switch0phy2@2 { reg = <0x2>; + interrupts-extended = <&switch0_peridot 2 IRQ_TYPE_LEVEL_HIGH>; }; switch0phy3: switch0phy3@3 { reg = <0x3>; + interrupts-extended = <&switch0_peridot 3 IRQ_TYPE_LEVEL_HIGH>; }; switch0phy4: switch0phy4@4 { reg = <0x4>; + interrupts-extended = <&switch0_peridot 4 IRQ_TYPE_LEVEL_HIGH>; }; switch0phy5: switch0phy5@5 { reg = <0x5>; + interrupts-extended = <&switch0_peridot 5 IRQ_TYPE_LEVEL_HIGH>; }; switch0phy6: switch0phy6@6 { reg = <0x6>; + interrupts-extended = <&switch0_peridot 6 IRQ_TYPE_LEVEL_HIGH>; }; switch0phy7: switch0phy7@7 { reg = <0x7>; + interrupts-extended = <&switch0_peridot 7 IRQ_TYPE_LEVEL_HIGH>; }; switch0phy8: switch0phy8@8 { reg = <0x8>; + interrupts-extended = <&switch0_peridot 8 IRQ_TYPE_LEVEL_HIGH>; }; }; @@ -430,12 +440,14 @@ port-sfp@a { }; }; - switch0@2 { + switch0_topaz: switch0@2 { compatible = "marvell,mv88e6085"; reg = <0x2>; dsa,member = <0 0>; interrupt-parent = <&moxtet>; interrupts = <MOXTET_IRQ_TOPAZ>; + interrupt-controller; + #interrupt-cells = <2>; status = "disabled"; mdio { @@ -444,18 +456,22 @@ mdio { switch0phy1_topaz: switch0phy1@11 { reg = <0x11>; + interrupts-extended = <&switch0_topaz 0x11 IRQ_TYPE_LEVEL_HIGH>; }; switch0phy2_topaz: switch0phy2@12 { reg = <0x12>; + interrupts-extended = <&switch0_topaz 0x12 IRQ_TYPE_LEVEL_HIGH>; }; switch0phy3_topaz: switch0phy3@13 { reg = <0x13>; + interrupts-extended = <&switch0_topaz 0x13 IRQ_TYPE_LEVEL_HIGH>; }; switch0phy4_topaz: switch0phy4@14 { reg = <0x14>; + interrupts-extended = <&switch0_topaz 0x14 IRQ_TYPE_LEVEL_HIGH>; }; }; @@ -497,12 +513,14 @@ port@5 { }; }; - switch1@11 { + switch1_peridot: switch1@11 { compatible = "marvell,mv88e6190"; reg = <0x11>; dsa,member = <0 1>; interrupt-parent = <&moxtet>; interrupts = <MOXTET_IRQ_PERIDOT(1)>; + interrupt-controller; + #interrupt-cells = <2>; status = "disabled"; mdio { @@ -511,34 +529,42 @@ mdio { switch1phy1: switch1phy1@1 { reg = <0x1>; + interrupts-extended = <&switch1_peridot 1 IRQ_TYPE_LEVEL_HIGH>; }; switch1phy2: switch1phy2@2 { reg = <0x2>; + interrupts-extended = <&switch1_peridot 2 IRQ_TYPE_LEVEL_HIGH>; }; switch1phy3: switch1phy3@3 { reg = <0x3>; + interrupts-extended = <&switch1_peridot 3 IRQ_TYPE_LEVEL_HIGH>; }; switch1phy4: switch1phy4@4 { reg = <0x4>; + interrupts-extended = <&switch1_peridot 4 IRQ_TYPE_LEVEL_HIGH>; }; switch1phy5: switch1phy5@5 { reg = <0x5>; + interrupts-extended = <&switch1_peridot 5 IRQ_TYPE_LEVEL_HIGH>; }; switch1phy6: switch1phy6@6 { reg = <0x6>; + interrupts-extended = <&switch1_peridot 6 IRQ_TYPE_LEVEL_HIGH>; }; switch1phy7: switch1phy7@7 { reg = <0x7>; + interrupts-extended = <&switch1_peridot 7 IRQ_TYPE_LEVEL_HIGH>; }; switch1phy8: switch1phy8@8 { reg = <0x8>; + interrupts-extended = <&switch1_peridot 8 IRQ_TYPE_LEVEL_HIGH>; }; }; @@ -622,12 +648,14 @@ port-sfp@a { }; }; - switch1@2 { + switch1_topaz: switch1@2 { compatible = "marvell,mv88e6085"; reg = <0x2>; dsa,member = <0 1>; interrupt-parent = <&moxtet>; interrupts = <MOXTET_IRQ_TOPAZ>; + interrupt-controller; + #interrupt-cells = <2>; status = "disabled"; mdio { @@ -636,18 +664,22 @@ mdio { switch1phy1_topaz: switch1phy1@11 { reg = <0x11>; + interrupts-extended = <&switch1_topaz 0x11 IRQ_TYPE_LEVEL_HIGH>; }; switch1phy2_topaz: switch1phy2@12 { reg = <0x12>; + interrupts-extended = <&switch1_topaz 0x12 IRQ_TYPE_LEVEL_HIGH>; }; switch1phy3_topaz: switch1phy3@13 { reg = <0x13>; + interrupts-extended = <&switch1_topaz 0x13 IRQ_TYPE_LEVEL_HIGH>; }; switch1phy4_topaz: switch1phy4@14 { reg = <0x14>; + interrupts-extended = <&switch1_topaz 0x14 IRQ_TYPE_LEVEL_HIGH>; }; }; @@ -689,12 +721,14 @@ port@5 { }; }; - switch2@12 { + switch2_peridot: switch2@12 { compatible = "marvell,mv88e6190"; reg = <0x12>; dsa,member = <0 2>; interrupt-parent = <&moxtet>; interrupts = <MOXTET_IRQ_PERIDOT(2)>; + interrupt-controller; + #interrupt-cells = <2>; status = "disabled"; mdio { @@ -703,34 +737,42 @@ mdio { switch2phy1: switch2phy1@1 { reg = <0x1>; + interrupts-extended = <&switch2_peridot 1 IRQ_TYPE_LEVEL_HIGH>; }; switch2phy2: switch2phy2@2 { reg = <0x2>; + interrupts-extended = <&switch2_peridot 2 IRQ_TYPE_LEVEL_HIGH>; }; switch2phy3: switch2phy3@3 { reg = <0x3>; + interrupts-extended = <&switch2_peridot 3 IRQ_TYPE_LEVEL_HIGH>; }; switch2phy4: switch2phy4@4 { reg = <0x4>; + interrupts-extended = <&switch2_peridot 4 IRQ_TYPE_LEVEL_HIGH>; }; switch2phy5: switch2phy5@5 { reg = <0x5>; + interrupts-extended = <&switch2_peridot 5 IRQ_TYPE_LEVEL_HIGH>; }; switch2phy6: switch2phy6@6 { reg = <0x6>; + interrupts-extended = <&switch2_peridot 6 IRQ_TYPE_LEVEL_HIGH>; }; switch2phy7: switch2phy7@7 { reg = <0x7>; + interrupts-extended = <&switch2_peridot 7 IRQ_TYPE_LEVEL_HIGH>; }; switch2phy8: switch2phy8@8 { reg = <0x8>; + interrupts-extended = <&switch2_peridot 8 IRQ_TYPE_LEVEL_HIGH>; }; }; @@ -805,12 +847,14 @@ port-sfp@a { }; }; - switch2@2 { + switch2_topaz: switch2@2 { compatible = "marvell,mv88e6085"; reg = <0x2>; dsa,member = <0 2>; interrupt-parent = <&moxtet>; interrupts = <MOXTET_IRQ_TOPAZ>; + interrupt-controller; + #interrupt-cells = <2>; status = "disabled"; mdio { @@ -819,18 +863,22 @@ mdio { switch2phy1_topaz: switch2phy1@11 { reg = <0x11>; + interrupts-extended = <&switch2_topaz 0x11 IRQ_TYPE_LEVEL_HIGH>; }; switch2phy2_topaz: switch2phy2@12 { reg = <0x12>; + interrupts-extended = <&switch2_topaz 0x12 IRQ_TYPE_LEVEL_HIGH>; }; switch2phy3_topaz: switch2phy3@13 { reg = <0x13>; + interrupts-extended = <&switch2_topaz 0x13 IRQ_TYPE_LEVEL_HIGH>; }; switch2phy4_topaz: switch2phy4@14 { reg = <0x14>; + interrupts-extended = <&switch2_topaz 0x14 IRQ_TYPE_LEVEL_HIGH>; }; }; However, as I had explained in one of the first discussions here: https://lore.kernel.org/netdev/20210901012826.iuy2bhvkrgahhrl7@skbuf/ it was always hit-or-miss whether the above device tree had an issue with fw_devlink or not: it depended on how the driver was written (and the mv88e6xxx switch driver was tricking the fw_devlink logic from that time to drop the device links because of an unrelated -EPROBE_DEFER). What I had done to "untrick" fw_devlink so that I could see the issue (which was originally reported by Alvin Šipraga) was to modify the mv88e6xxx driver, and change the placement of mv88e6xxx_mdios_register() to a point after which we will never hit -EPROBE_DEFER (from driver probe() to the dsa_switch_ops :: setup() method): diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c index 0a5d6c7bb128..48650465660d 100644 --- a/drivers/net/dsa/mv88e6xxx/chip.c +++ b/drivers/net/dsa/mv88e6xxx/chip.c @@ -3672,11 +3672,18 @@ static int mv88e6390_setup_errata(struct mv88e6xxx_chip *chip) return mv88e6xxx_software_reset(chip); } +static int mv88e6xxx_mdios_register(struct mv88e6xxx_chip *chip, + struct device_node *np); +static void mv88e6xxx_mdios_unregister(struct mv88e6xxx_chip *chip); + static void mv88e6xxx_teardown(struct dsa_switch *ds) { + struct mv88e6xxx_chip *chip = ds->priv; + mv88e6xxx_teardown_devlink_params(ds); dsa_devlink_resources_unregister(ds); mv88e6xxx_teardown_devlink_regions_global(ds); + mv88e6xxx_mdios_unregister(chip); } static int mv88e6xxx_setup(struct dsa_switch *ds) @@ -3686,6 +3693,10 @@ static int mv88e6xxx_setup(struct dsa_switch *ds) int err; int i; + err = mv88e6xxx_mdios_register(chip, chip->dev->of_node); + if (err) + return err; + chip->ds = ds; ds->slave_mii_bus = mv88e6xxx_default_mdio_bus(chip); @@ -3811,8 +3822,10 @@ static int mv88e6xxx_setup(struct dsa_switch *ds) unlock: mv88e6xxx_reg_unlock(chip); - if (err) + if (err) { + mv88e6xxx_mdios_unregister(chip); return err; + } /* Have to be called without holding the register lock, since * they take the devlink lock, and we later take the locks in @@ -3837,6 +3850,7 @@ static int mv88e6xxx_setup(struct dsa_switch *ds) mv88e6xxx_teardown_devlink_params(ds); out_resources: dsa_devlink_resources_unregister(ds); + mv88e6xxx_mdios_unregister(chip); return err; } @@ -7220,18 +7234,12 @@ static int mv88e6xxx_probe(struct mdio_device *mdiodev) if (err) goto out_g1_atu_prob_irq; - err = mv88e6xxx_mdios_register(chip, np); - if (err) - goto out_g1_vtu_prob_irq; - err = mv88e6xxx_register_switch(chip); if (err) - goto out_mdio; + goto out_g1_vtu_prob_irq; return 0; -out_mdio: - mv88e6xxx_mdios_unregister(chip); out_g1_vtu_prob_irq: mv88e6xxx_g1_vtu_prob_irq_free(chip); out_g1_atu_prob_irq: @@ -7268,7 +7276,6 @@ static void mv88e6xxx_remove(struct mdio_device *mdiodev) mv88e6xxx_phy_destroy(chip); mv88e6xxx_unregister_switch(chip); - mv88e6xxx_mdios_unregister(chip); mv88e6xxx_g1_vtu_prob_irq_free(chip); mv88e6xxx_g1_atu_prob_irq_free(chip); After applying both of the above changes on top of yours, I confirm that the PHYs on the mv88e6xxx on Turris MOX still probe with their specific PHY driver rather than the generic one, and with interrupts (not poll mode): [ 6.125894] mv88e6085 d0032004.mdio-mii:11 lan9 (uninitialized): PHY [!soc!internal-regs@d0000000!mdio@32004!switch1@11!mdio:01] driver [Marvell 88E6390 Family] (irq=49) [ 6.222024] mv88e6085 d0032004.mdio-mii:11 lan10 (uninitialized): PHY [!soc!internal-regs@d0000000!mdio@32004!switch1@11!mdio:02] driver [Marvell 88E6390 Family] (irq=50) [ 6.277554] mv88e6085 d0032004.mdio-mii:11 lan11 (uninitialized): PHY [!soc!internal-regs@d0000000!mdio@32004!switch1@11!mdio:03] driver [Marvell 88E6390 Family] (irq=51) [ 6.361556] mv88e6085 d0032004.mdio-mii:11 lan12 (uninitialized): PHY [!soc!internal-regs@d0000000!mdio@32004!switch1@11!mdio:04] driver [Marvell 88E6390 Family] (irq=52) [ 6.445574] mv88e6085 d0032004.mdio-mii:11 lan13 (uninitialized): PHY [!soc!internal-regs@d0000000!mdio@32004!switch1@11!mdio:05] driver [Marvell 88E6390 Family] (irq=53) [ 6.529560] mv88e6085 d0032004.mdio-mii:11 lan14 (uninitialized): PHY [!soc!internal-regs@d0000000!mdio@32004!switch1@11!mdio:06] driver [Marvell 88E6390 Family] (irq=54) [ 6.589555] mv88e6085 d0032004.mdio-mii:11 lan15 (uninitialized): PHY [!soc!internal-regs@d0000000!mdio@32004!switch1@11!mdio:07] driver [Marvell 88E6390 Family] (irq=55) [ 6.673559] mv88e6085 d0032004.mdio-mii:11 lan16 (uninitialized): PHY [!soc!internal-regs@d0000000!mdio@32004!switch1@11!mdio:08] driver [Marvell 88E6390 Family] (irq=56) [ 6.733558] mv88e6085 d0032004.mdio-mii:12 lan17 (uninitialized): PHY [!soc!internal-regs@d0000000!mdio@32004!switch2@12!mdio:01] driver [Marvell 88E6390 Family] (irq=74) [ 6.817557] mv88e6085 d0032004.mdio-mii:12 lan18 (uninitialized): PHY [!soc!internal-regs@d0000000!mdio@32004!switch2@12!mdio:02] driver [Marvell 88E6390 Family] (irq=75) [ 6.889628] mv88e6085 d0032004.mdio-mii:12 lan19 (uninitialized): PHY [!soc!internal-regs@d0000000!mdio@32004!switch2@12!mdio:03] driver [Marvell 88E6390 Family] (irq=76) [ 6.973593] mv88e6085 d0032004.mdio-mii:12 lan20 (uninitialized): PHY [!soc!internal-regs@d0000000!mdio@32004!switch2@12!mdio:04] driver [Marvell 88E6390 Family] (irq=77) [ 7.057572] mv88e6085 d0032004.mdio-mii:12 lan21 (uninitialized): PHY [!soc!internal-regs@d0000000!mdio@32004!switch2@12!mdio:05] driver [Marvell 88E6390 Family] (irq=78) [ 7.109547] mv88e6085 d0032004.mdio-mii:12 lan22 (uninitialized): PHY [!soc!internal-regs@d0000000!mdio@32004!switch2@12!mdio:06] driver [Marvell 88E6390 Family] (irq=79) [ 7.193553] mv88e6085 d0032004.mdio-mii:12 lan23 (uninitialized): PHY [!soc!internal-regs@d0000000!mdio@32004!switch2@12!mdio:07] driver [Marvell 88E6390 Family] (irq=80) [ 7.277550] mv88e6085 d0032004.mdio-mii:12 lan24 (uninitialized): PHY [!soc!internal-regs@d0000000!mdio@32004!switch2@12!mdio:08] driver [Marvell 88E6390 Family] (irq=81) [ 7.365556] mv88e6085 d0032004.mdio-mii:10 lan1 (uninitialized): PHY [!soc!internal-regs@d0000000!mdio@32004!switch0@10!mdio:01] driver [Marvell 88E6390 Family] (irq=109) [ 7.421549] mv88e6085 d0032004.mdio-mii:10 lan2 (uninitialized): PHY [!soc!internal-regs@d0000000!mdio@32004!switch0@10!mdio:02] driver [Marvell 88E6390 Family] (irq=110) [ 7.505554] mv88e6085 d0032004.mdio-mii:10 lan3 (uninitialized): PHY [!soc!internal-regs@d0000000!mdio@32004!switch0@10!mdio:03] driver [Marvell 88E6390 Family] (irq=111) [ 7.589571] mv88e6085 d0032004.mdio-mii:10 lan4 (uninitialized): PHY [!soc!internal-regs@d0000000!mdio@32004!switch0@10!mdio:04] driver [Marvell 88E6390 Family] (irq=112) [ 7.673560] mv88e6085 d0032004.mdio-mii:10 lan5 (uninitialized): PHY [!soc!internal-regs@d0000000!mdio@32004!switch0@10!mdio:05] driver [Marvell 88E6390 Family] (irq=113) [ 7.733547] mv88e6085 d0032004.mdio-mii:10 lan6 (uninitialized): PHY [!soc!internal-regs@d0000000!mdio@32004!switch0@10!mdio:06] driver [Marvell 88E6390 Family] (irq=114) [ 7.817555] mv88e6085 d0032004.mdio-mii:10 lan7 (uninitialized): PHY [!soc!internal-regs@d0000000!mdio@32004!switch0@10!mdio:07] driver [Marvell 88E6390 Family] (irq=115) [ 7.901572] mv88e6085 d0032004.mdio-mii:10 lan8 (uninitialized): PHY [!soc!internal-regs@d0000000!mdio@32004!switch0@10!mdio:08] driver [Marvell 88E6390 Family] (irq=116) even though I am seeing these error messages earlier in the boot process (maybe this is something to look into): [ 0.910219] mdio_bus d0032004.mdio-mii:10: Failed to create device link with d0032004.mdio-mii:10 [ 0.910228] mdio_bus d0032004.mdio-mii:10: Failed to create device link with d0032004.mdio-mii:10 [ 0.910237] mdio_bus d0032004.mdio-mii:10: Failed to create device link with d0032004.mdio-mii:10 [ 0.910244] mdio_bus d0032004.mdio-mii:10: Failed to create device link with d0032004.mdio-mii:10 [ 0.910251] mdio_bus d0032004.mdio-mii:10: Failed to create device link with d0032004.mdio-mii:10 [ 0.910259] mdio_bus d0032004.mdio-mii:10: Failed to create device link with d0032004.mdio-mii:10 [ 0.910266] mdio_bus d0032004.mdio-mii:10: Failed to create device link with d0032004.mdio-mii:10 [ 0.910273] mdio_bus d0032004.mdio-mii:10: Failed to create device link with d0032004.mdio-mii:10 [ 0.910936] mv88e6085 d0032004.mdio-mii:10: switch 0x3900 detected: Marvell 88E6390, revision 1 [ 0.928360] mdio_bus d0032004.mdio-mii:11: Failed to create device link with d0032004.mdio-mii:11 [ 0.928380] mdio_bus d0032004.mdio-mii:11: Failed to create device link with d0032004.mdio-mii:11 [ 0.928388] mdio_bus d0032004.mdio-mii:11: Failed to create device link with d0032004.mdio-mii:11 [ 0.928396] mdio_bus d0032004.mdio-mii:11: Failed to create device link with d0032004.mdio-mii:11 [ 0.928403] mdio_bus d0032004.mdio-mii:11: Failed to create device link with d0032004.mdio-mii:11 [ 0.928410] mdio_bus d0032004.mdio-mii:11: Failed to create device link with d0032004.mdio-mii:11 [ 0.928418] mdio_bus d0032004.mdio-mii:11: Failed to create device link with d0032004.mdio-mii:11 [ 0.928425] mdio_bus d0032004.mdio-mii:11: Failed to create device link with d0032004.mdio-mii:11 [ 0.928993] mv88e6085 d0032004.mdio-mii:11: switch 0x1900 detected: Marvell 88E6190, revision 1 [ 0.943306] mdio_bus d0032004.mdio-mii:12: Failed to create device link with d0032004.mdio-mii:12 [ 0.943327] mdio_bus d0032004.mdio-mii:12: Failed to create device link with d0032004.mdio-mii:12 [ 0.943334] mdio_bus d0032004.mdio-mii:12: Failed to create device link with d0032004.mdio-mii:12 [ 0.943342] mdio_bus d0032004.mdio-mii:12: Failed to create device link with d0032004.mdio-mii:12 [ 0.943349] mdio_bus d0032004.mdio-mii:12: Failed to create device link with d0032004.mdio-mii:12 [ 0.943357] mdio_bus d0032004.mdio-mii:12: Failed to create device link with d0032004.mdio-mii:12 [ 0.943364] mdio_bus d0032004.mdio-mii:12: Failed to create device link with d0032004.mdio-mii:12 [ 0.943371] mdio_bus d0032004.mdio-mii:12: Failed to create device link with d0032004.mdio-mii:12 [ 0.943879] mv88e6085 d0032004.mdio-mii:12: switch 0x1900 detected: Marvell 88E6190, revision 1 If _on top_ of all the above, I also remove the logic that sets FWNODE_FLAG_NEEDS_CHILD_BOUND_ON_ADD: drivers/net/phy/mdio_bus.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c index 00d5bcdf0e6f..4d4c42771d37 100644 --- a/drivers/net/phy/mdio_bus.c +++ b/drivers/net/phy/mdio_bus.c @@ -665,9 +665,9 @@ int __mdiobus_register(struct mii_bus *bus, struct module *owner) if (!bus->read && !bus->read_c45) return -EINVAL; - if (bus->parent && bus->parent->of_node) - bus->parent->of_node->fwnode.flags |= - FWNODE_FLAG_NEEDS_CHILD_BOUND_ON_ADD; +// if (bus->parent && bus->parent->of_node) +// bus->parent->of_node->fwnode.flags |= +// FWNODE_FLAG_NEEDS_CHILD_BOUND_ON_ADD; WARN(bus->state != MDIOBUS_ALLOCATED && bus->state != MDIOBUS_UNREGISTERED, then *finally* I get something approximating Alvin's reported issue. In my case, one switch out of 3 gets its PHYs bound to the Generic PHY driver (why not all is a story for another time): [ 6.106204] mv88e6085 d0032004.mdio-mii:11 lan9 (uninitialized): PHY [!soc!internal-regs@d0000000!mdio@32004!switch1@11!mdio:01] driver [Marvell 88E6390 Family] (irq=49) [ 6.193561] mv88e6085 d0032004.mdio-mii:11 lan10 (uninitialized): PHY [!soc!internal-regs@d0000000!mdio@32004!switch1@11!mdio:02] driver [Marvell 88E6390 Family] (irq=50) [ 6.249654] mv88e6085 d0032004.mdio-mii:11 lan11 (uninitialized): PHY [!soc!internal-regs@d0000000!mdio@32004!switch1@11!mdio:03] driver [Marvell 88E6390 Family] (irq=51) [ 6.333580] mv88e6085 d0032004.mdio-mii:11 lan12 (uninitialized): PHY [!soc!internal-regs@d0000000!mdio@32004!switch1@11!mdio:04] driver [Marvell 88E6390 Family] (irq=52) [ 6.417577] mv88e6085 d0032004.mdio-mii:11 lan13 (uninitialized): PHY [!soc!internal-regs@d0000000!mdio@32004!switch1@11!mdio:05] driver [Marvell 88E6390 Family] (irq=53) [ 6.501561] mv88e6085 d0032004.mdio-mii:11 lan14 (uninitialized): PHY [!soc!internal-regs@d0000000!mdio@32004!switch1@11!mdio:06] driver [Marvell 88E6390 Family] (irq=54) [ 6.561655] mv88e6085 d0032004.mdio-mii:11 lan15 (uninitialized): PHY [!soc!internal-regs@d0000000!mdio@32004!switch1@11!mdio:07] driver [Marvell 88E6390 Family] (irq=55) [ 6.645583] mv88e6085 d0032004.mdio-mii:11 lan16 (uninitialized): PHY [!soc!internal-regs@d0000000!mdio@32004!switch1@11!mdio:08] driver [Marvell 88E6390 Family] (irq=56) [ 6.733557] mv88e6085 d0032004.mdio-mii:12 lan17 (uninitialized): PHY [!soc!internal-regs@d0000000!mdio@32004!switch2@12!mdio:01] driver [Marvell 88E6390 Family] (irq=74) [ 6.817563] mv88e6085 d0032004.mdio-mii:12 lan18 (uninitialized): PHY [!soc!internal-regs@d0000000!mdio@32004!switch2@12!mdio:02] driver [Marvell 88E6390 Family] (irq=75) [ 6.873653] mv88e6085 d0032004.mdio-mii:12 lan19 (uninitialized): PHY [!soc!internal-regs@d0000000!mdio@32004!switch2@12!mdio:03] driver [Marvell 88E6390 Family] (irq=76) [ 6.957582] mv88e6085 d0032004.mdio-mii:12 lan20 (uninitialized): PHY [!soc!internal-regs@d0000000!mdio@32004!switch2@12!mdio:04] driver [Marvell 88E6390 Family] (irq=77) [ 7.041567] mv88e6085 d0032004.mdio-mii:12 lan21 (uninitialized): PHY [!soc!internal-regs@d0000000!mdio@32004!switch2@12!mdio:05] driver [Marvell 88E6390 Family] (irq=78) [ 7.093561] mv88e6085 d0032004.mdio-mii:12 lan22 (uninitialized): PHY [!soc!internal-regs@d0000000!mdio@32004!switch2@12!mdio:06] driver [Marvell 88E6390 Family] (irq=79) [ 7.177476] mv88e6085 d0032004.mdio-mii:12 lan23 (uninitialized): PHY [!soc!internal-regs@d0000000!mdio@32004!switch2@12!mdio:07] driver [Marvell 88E6390 Family] (irq=80) [ 7.245560] mv88e6085 d0032004.mdio-mii:12 lan24 (uninitialized): PHY [!soc!internal-regs@d0000000!mdio@32004!switch2@12!mdio:08] driver [Marvell 88E6390 Family] (irq=81) [ 7.269178] mv88e6085 d0032004.mdio-mii:10 lan1 (uninitialized): PHY [!soc!internal-regs@d0000000!mdio@32004!switch0@10!mdio:01] driver [Generic PHY] (irq=POLL) [ 7.288234] mv88e6085 d0032004.mdio-mii:10 lan2 (uninitialized): PHY [!soc!internal-regs@d0000000!mdio@32004!switch0@10!mdio:02] driver [Generic PHY] (irq=POLL) [ 7.307295] mv88e6085 d0032004.mdio-mii:10 lan3 (uninitialized): PHY [!soc!internal-regs@d0000000!mdio@32004!switch0@10!mdio:03] driver [Generic PHY] (irq=POLL) [ 7.326342] mv88e6085 d0032004.mdio-mii:10 lan4 (uninitialized): PHY [!soc!internal-regs@d0000000!mdio@32004!switch0@10!mdio:04] driver [Generic PHY] (irq=POLL) [ 7.345384] mv88e6085 d0032004.mdio-mii:10 lan5 (uninitialized): PHY [!soc!internal-regs@d0000000!mdio@32004!switch0@10!mdio:05] driver [Generic PHY] (irq=POLL) [ 7.364449] mv88e6085 d0032004.mdio-mii:10 lan6 (uninitialized): PHY [!soc!internal-regs@d0000000!mdio@32004!switch0@10!mdio:06] driver [Generic PHY] (irq=POLL) [ 7.383496] mv88e6085 d0032004.mdio-mii:10 lan7 (uninitialized): PHY [!soc!internal-regs@d0000000!mdio@32004!switch0@10!mdio:07] driver [Generic PHY] (irq=POLL) [ 7.402563] mv88e6085 d0032004.mdio-mii:10 lan8 (uninitialized): PHY [!soc!internal-regs@d0000000!mdio@32004!switch0@10!mdio:08] driver [Generic PHY] (irq=POLL) So I guess that FWNODE_FLAG_NEEDS_CHILD_BOUND_ON_ADD does something. OTOH, if I apply just my patch to remove the FWNODE_FLAG_NEEDS_CHILD_BOUND_ON_ADD, but without making the device tree change or the mv88e6xxx driver change, the PHYs still probe with the correct driver and with interrupts (i.e. they don't get their probing deferred). This also seems to prove my point that my patches to bring the Turris MOX to a testable state for this fwnode flag are indeed required. HTH.
On Fri, Feb 10, 2023 at 1:08 PM Vladimir Oltean <vladimir.oltean@nxp.com> wrote: > > On Fri, Feb 10, 2023 at 11:27:11AM -0800, Saravana Kannan wrote: > > On Fri, Feb 10, 2023 at 2:13 AM Vladimir Oltean <vladimir.oltean@nxp.com> wrote: > > > > > > Hi Saravana, > > > > > > On Mon, Feb 06, 2023 at 05:41:52PM -0800, Saravana Kannan wrote: > > > > Vladimir, > > > > > > > > Ccing you because DSA's and fw_devlink have known/existing problems > > > > (still in my TODOs to fix). But I want to make sure this series doesn't > > > > cause additional problems for DSA. > > > > > > > > All, > > > > > > > > This patch series improves fw_devlink in the following ways: > > > > > > > > 1. It no longer cares about a fwnode having a "compatible" property. It > > > > figures this out more dynamically. The only expectation is that > > > > fwnodes that are converted to devices actually get probed by a driver > > > > for the dependencies to be enforced correctly. > > > > > > > > 2. Finer grained dependency tracking. fw_devlink will now create device > > > > links from the consumer to the actual resource's device (if it has one, > > > > Eg: gpio_device) instead of the parent supplier device. This improves > > > > things like async suspend/resume ordering, potentially remove the need > > > > for frameworks to create device links, more parallelized async probing, > > > > and better sync_state() tracking. > > > > > > > > 3. Handle hardware/software quirks where a child firmware node gets > > > > populated as a device before its parent firmware node AND actually > > > > supplies a non-optional resource to the parent firmware node's > > > > device. > > > > > > > > 4. Way more robust at cycle handling (see patch for the insane cases). > > > > > > > > 5. Stops depending on OF_POPULATED to figure out some corner cases. > > > > > > > > 6. Simplifies the work that needs to be done by the firmware specific > > > > code. > > > > > > > > The v3 series has gone through my usual testing on my end and looks good > > > > to me. > > > > > > Booted on an NXP LS1028A (arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts) > > > and a Turris MOX (arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts) > > > with no observed regressions. > > > > Thanks for testing Vladimir! > > > > > Is there something specific you would like > > > me to test? > > > > Not really, I just want to make sure the common DSA architectures > > don't hit any regression. In the hardware you tested, are there cases > > of PHYs where the supplier is the parent MDIO? I remember that being > > the only case where I needed special casing > > (FWNODE_FLAG_NEEDS_CHILD_BOUND_ON_ADD) in fw_devlink -- so it'll be > > good to make sure I didn't accidentally break anything there. > > > > -Saravana > > Yes and no (I never had a system which depended on FWNODE_FLAG_NEEDS_CHILD_BOUND_ON_ADD). > > Yes, because well, yes, in arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts, > the PHYs will depend on interrupts provided by their (parent) switch. However this > is not explicit in the device tree. To make it explicit, one would need to add: > > diff --git a/arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts b/arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts > index cd0988317623..d789cda49e35 100644 > --- a/arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts > +++ b/arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts -----8<---- Snipped DT diff ----- > However, as I had explained in one of the first discussions here: > https://lore.kernel.org/netdev/20210901012826.iuy2bhvkrgahhrl7@skbuf/ > > it was always hit-or-miss whether the above device tree had an issue > with fw_devlink or not: it depended on how the driver was written (and > the mv88e6xxx switch driver was tricking the fw_devlink logic from that > time to drop the device links because of an unrelated -EPROBE_DEFER). Yeah, I never forgot this issue. That's why I used "additional" in my cover letter :) So far I've not needed to change fw_devlink in a way that'd break this unintentional "tricky behavior" but I might be coming up to that wall soon. So this reply is becoming more relevant to me: https://lore.kernel.org/lkml/CAGETcx8De_qm9hVtK5CznfWke9nmOfV8OcvAW6kmwyeb7APr=g@mail.gmail.com/ Not sure if you've had a chance to read or think about it. > What I had done to "untrick" fw_devlink so that I could see the issue > (which was originally reported by Alvin Šipraga) was to modify the > mv88e6xxx driver, and change the placement of mv88e6xxx_mdios_register() > to a point after which we will never hit -EPROBE_DEFER (from driver probe() > to the dsa_switch_ops :: setup() method): > > diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c > index 0a5d6c7bb128..48650465660d 100644 > --- a/drivers/net/dsa/mv88e6xxx/chip.c > +++ b/drivers/net/dsa/mv88e6xxx/chip.c -----8<---- snipped > After applying both of the above changes on top of yours, I confirm that > the PHYs on the mv88e6xxx on Turris MOX still probe with their specific > PHY driver rather than the generic one, and with interrupts (not poll mode): > -----8<---- snipped > > even though I am seeing these error messages earlier in the boot process (maybe this is something to look into): > > [ 0.910219] mdio_bus d0032004.mdio-mii:10: Failed to create device link with d0032004.mdio-mii:10 -----8<---- snipped > [ 0.943879] mv88e6085 d0032004.mdio-mii:12: switch 0x1900 detected: Marvell 88E6190, revision 1 > > > If _on top_ of all the above, I also remove the logic that sets FWNODE_FLAG_NEEDS_CHILD_BOUND_ON_ADD: > then *finally* I get something approximating Alvin's reported issue. > In my case, one switch out of 3 gets its PHYs bound to the Generic PHY > driver (why not all is a story for another time): -----8<---- snipped > So I guess that FWNODE_FLAG_NEEDS_CHILD_BOUND_ON_ADD does something. Thanks for the extensive effort into testing this! -Saravana
Hi Saravana, On Wed, Feb 8, 2023 at 3:08 AM Saravana Kannan <saravanak@google.com> wrote: > On Tue, Feb 7, 2023 at 12:57 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > On Tue, Feb 7, 2023 at 2:42 AM Saravana Kannan <saravanak@google.com> wrote: > > > The driver core now: > > > - Has the parent device of a supplier pick up the consumers if the > > > supplier never has a device created for it. > > > - Ignores a supplier if the supplier has no parent device and will never > > > be probed by a driver > > > > > > And already prevents creating a device link with the consumer as a > > > supplier of a parent. > > > > > > So, we no longer need to find the "compatible" node of the supplier or > > > do any other checks in of_link_to_phandle(). We simply need to make sure > > > that the supplier is available in DT. > > > > > > Signed-off-by: Saravana Kannan <saravanak@google.com> > > > > Thanks for your patch! > > > > This patch introduces a regression when dynamically loading DT overlays. > > Unfortunately this happens when using the out-of-tree OF configfs, > > which is not supported upstream. Still, there may be (obscure) > > in-tree users. > > > > When loading a DT overlay[1] to enable an SPI controller, and > > instantiate a connected SPI EEPROM: > > > > $ overlay add 25lc040 > > OF: overlay: WARNING: memory leak will occur if overlay removed, > > property: /keys/status > > OF: overlay: WARNING: memory leak will occur if overlay removed, > > property: /soc/spi@e6e90000/pinctrl-0 > > OF: overlay: WARNING: memory leak will occur if overlay removed, > > property: /soc/spi@e6e90000/pinctrl-names > > OF: overlay: WARNING: memory leak will occur if overlay removed, > > property: /soc/spi@e6e90000/cs-gpios > > OF: overlay: WARNING: memory leak will occur if overlay removed, > > property: /soc/spi@e6e90000/status > > OF: overlay: WARNING: memory leak will occur if overlay removed, > > property: /__symbols__/msiof0_pins > > > > The SPI controller and the SPI EEPROM are no longer instantiated. > > > > # cat /sys/kernel/debug/devices_deferred > > e6e90000.spi platform: wait for supplier msiof0 > > > > Let's remove the overlay again: > > > > $ overlay rm 25lc040 > > input: keys as /devices/platform/keys/input/input1 > > > > And retry: > > > > $ overlay add 25lc040 > > OF: overlay: WARNING: memory leak will occur if overlay removed, > > property: /keys/status > > OF: overlay: WARNING: memory leak will occur if overlay removed, > > property: /soc/spi@e6e90000/pinctrl-0 > > OF: overlay: WARNING: memory leak will occur if overlay removed, > > property: /soc/spi@e6e90000/pinctrl-names > > OF: overlay: WARNING: memory leak will occur if overlay removed, > > property: /soc/spi@e6e90000/cs-gpios > > OF: overlay: WARNING: memory leak will occur if overlay removed, > > property: /soc/spi@e6e90000/status > > OF: overlay: WARNING: memory leak will occur if overlay removed, > > property: /__symbols__/msiof0_pins > > spi_sh_msiof e6e90000.spi: DMA available > > spi_sh_msiof e6e90000.spi: registered master spi0 > > spi spi0.0: setup mode 0, 8 bits/w, 100000 Hz max --> 0 > > at25 spi0.0: 512 Byte at25 eeprom, pagesize 16 > > spi_sh_msiof e6e90000.spi: registered child spi0.0 > > > > Now it succeeds, and the SPI EEPROM is available, and works. > > > > Without this patch, or with this patch reverted after applying the > > full series: > > > > $ overlay add 25lc040 > > OF: overlay: WARNING: memory leak will occur if overlay removed, > > property: /keys/status > > OF: overlay: WARNING: memory leak will occur if overlay removed, > > property: /soc/spi@e6e90000/pinctrl-0 > > OF: overlay: WARNING: memory leak will occur if overlay removed, > > property: /soc/spi@e6e90000/pinctrl-names > > OF: overlay: WARNING: memory leak will occur if overlay removed, > > property: /soc/spi@e6e90000/cs-gpios > > OF: overlay: WARNING: memory leak will occur if overlay removed, > > property: /soc/spi@e6e90000/status > > OF: overlay: WARNING: memory leak will occur if overlay removed, > > property: /__symbols__/msiof0_pins > > OF: Not linking spi@e6e90000 to interrupt-controller@f1010000 - No > > struct device > > spi_sh_msiof e6e90000.spi: DMA available > > spi_sh_msiof e6e90000.spi: registered master spi0 > > spi spi0.0: setup mode 0, 8 bits/w, 100000 Hz max --> 0 > > at25 spi0.0: 444 bps (2 bytes in 9 ticks) > > at25 spi0.0: 512 Byte at25 eeprom, pagesize 16 > > spi_sh_msiof e6e90000.spi: registered child spi0.0 > > > > The SPI EEPROM is available on the first try after boot. > > Sigh... I spent way too long trying to figure out if I caused a memory > leak. I should have scrolled down further! Doesn't look like that part > is related to anything I did. > > There are some flags set to avoid re-parsing fwnodes multiple times. > My guess is that the issue you are seeing has to do with how many of > the in memory structs are reused vs not when an overlay is > applied/removed and some of these flags might not be getting cleared > and this is having a bigger impact with this patch (because the fwnode > links are no longer anchored on "compatible" nodes). > > With/without this patch (let's keep the series) can you look at how > the following things change between each step you do above (add, > remove, retry): > 1) List of directories under /sys/class/devlink > 2) Enable the debug logs inside __fwnode_link_add(), > __fwnode_link_del(), device_link_add() Without "of: property: Simplify of_link_to_phandle()": - Adding overlay: spi@e6e90000 Linked as a fwnode consumer to clock-controller@e6150000 spi@e6e90000 Linked as a fwnode consumer to system-controller@e6180000 spi@e6e90000 Linked as a fwnode consumer to pinctrl@e6060000 spi@e6e90000 Linked as a fwnode consumer to gpio@e6055000 platform e6e90000.spi: Linked as a consumer to e6055000.gpio spi@e6e90000 Dropping the fwnode link to gpio@e6055000 platform e6e90000.spi: Linked as a consumer to e6060000.pinctrl spi@e6e90000 Dropping the fwnode link to pinctrl@e6060000 spi@e6e90000 Dropping the fwnode link to system-controller@e6180000 platform e6e90000.spi: Linked as a consumer to e6150000.clock-controller spi@e6e90000 Dropping the fwnode link to clock-controller@e6150000 +platform:e6055000.gpio--platform:e6e90000.spi -> ../../devices/virtual/devlink/platform:e6055000.gpio--platform:e6e90000.spi +platform:e6060000.pinctrl--platform:e6e90000.spi -> ../../devices/virtual/devlink/platform:e6060000.pinctrl--platform:e6e90000.spi +platform:e6150000.clock-controller--platform:e6e90000.spi -> ../../devices/virtual/devlink/platform:e6150000.clock-controller--platform:e6e90000.spi -platform:e6060000.pinctrl--platform:keys -> ../../devices/virtual/devlink/platform:e6060000.pinctrl--platform:keys SPI EEPROM works - Removing overlay: platform keys: Linked as a sync state only consumer to e6055000.gpio -platform:e6055000.gpio--platform:e6e90000.spi -> ../../devices/virtual/devlink/platform:e6055000.gpio--platform:e6e90000.spi -platform:e6060000.pinctrl--platform:e6e90000.spi -> ../../devices/virtual/devlink/platform:e6060000.pinctrl--platform:e6e90000.spi -platform:e6150000.clock-controller--platform:e6e90000.spi -> ../../devices/virtual/devlink/platform:e6150000.clock-controller--platform:e6e90000.spi platform:e6060000.pinctrl--platform:keys link is not recreated?!?!? - Adding overlay again: No debug output No change in sys/class/devlink?!?!? SPI EEPROM works With "of: property: Simplify of_link_to_phandle()": - Adding overlay: spi@e6e90000 Linked as a fwnode consumer to interrupt-controller@f1010000 spi@e6e90000 Linked as a fwnode consumer to clock-controller@e6150000 spi@e6e90000 Linked as a fwnode consumer to system-controller@e6180000 spi@e6e90000 Linked as a fwnode consumer to msiof0 spi@e6e90000 Linked as a fwnode consumer to gpio@e6055000 platform e6e90000.spi: Linked as a consumer to e6055000.gpio spi@e6e90000 Dropping the fwnode link to gpio@e6055000 spi@e6e90000 Dropping the fwnode link to system-controller@e6180000 platform e6e90000.spi: Linked as a consumer to e6150000.clock-controller spi@e6e90000 Dropping the fwnode link to clock-controller@e6150000 platform e6e90000.spi: Linked as a consumer to soc spi@e6e90000 Dropping the fwnode link to interrupt-controller@f1010000 +platform:e6055000.gpio--platform:e6e90000.spi -> ../../devices/virtual/devlink/platform:e6055000.gpio--platform:e6e90000.spi +platform:e6150000.clock-controller--platform:e6e90000.spi -> ../../devices/virtual/devlink/platform:e6150000.clock-controller--platform:e6e90000.spi +platform:soc--platform:e6e90000.spi -> ../../devices/virtual/devlink/platform:soc--platform:e6e90000.spi -platform:e6060000.pinctrl--platform:keys -> ../../devices/virtual/devlink/platform:e6060000.pinctrl--platform:keys SPI EEPROM does not work - Removing overlay: platform keys: Linked as a sync state only consumer to e6055000.gpio spi@e6e90000 Dropping the fwnode link to msiof0 -platform:e6055000.gpio--platform:e6e90000.spi -> ../../devices/virtual/devlink/platform:e6055000.gpio--platform:e6e90000.spi -platform:e6150000.clock-controller--platform:e6e90000.spi -> ../../devices/virtual/devlink/platform:e6150000.clock-controller--platform:e6e90000.spi -platform:soc--platform:e6e90000.spi -> ../../devices/virtual/devlink/platform:soc--platform:e6e90000.spi platform:e6060000.pinctrl--platform:keys link is not recreated?!?!? - Adding overlay again: No debug output No change in sys/class/devlink?!?!? SPI EEPROM works Gr{oetje,eeting}s, Geert
Hi Saravana, On Wed, Feb 8, 2023 at 9:35 AM Saravana Kannan <saravanak@google.com> wrote: > On Tue, Feb 7, 2023 at 11:57 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > On Wed, Feb 8, 2023 at 8:32 AM Saravana Kannan <saravanak@google.com> wrote: > > > On Tue, Feb 7, 2023 at 6:08 PM Saravana Kannan <saravanak@google.com> wrote: > > > > On Tue, Feb 7, 2023 at 12:57 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > > > > On Tue, Feb 7, 2023 at 2:42 AM Saravana Kannan <saravanak@google.com> wrote: > > > > > > The driver core now: > > > > > > - Has the parent device of a supplier pick up the consumers if the > > > > > > supplier never has a device created for it. > > > > > > - Ignores a supplier if the supplier has no parent device and will never > > > > > > be probed by a driver > > > > > > > > > > > > And already prevents creating a device link with the consumer as a > > > > > > supplier of a parent. > > > > > > > > > > > > So, we no longer need to find the "compatible" node of the supplier or > > > > > > do any other checks in of_link_to_phandle(). We simply need to make sure > > > > > > that the supplier is available in DT. > > > > > > > > > > > > Signed-off-by: Saravana Kannan <saravanak@google.com> > > > > > > > > > > Thanks for your patch! > > > > > > > > > > This patch introduces a regression when dynamically loading DT overlays. > > > > > Unfortunately this happens when using the out-of-tree OF configfs, > > > > > which is not supported upstream. Still, there may be (obscure) > > > > > in-tree users. > > > > > > > > > > When loading a DT overlay[1] to enable an SPI controller, and > > > > > instantiate a connected SPI EEPROM: > > > > [...] > > > > > > > The SPI controller and the SPI EEPROM are no longer instantiated. > > > > > > Sigh... I spent way too long trying to figure out if I caused a memory > > > > leak. I should have scrolled down further! Doesn't look like that part > > > > is related to anything I did. > > > > > > > > There are some flags set to avoid re-parsing fwnodes multiple times. > > > > My guess is that the issue you are seeing has to do with how many of > > > > the in memory structs are reused vs not when an overlay is > > > > applied/removed and some of these flags might not be getting cleared > > > > and this is having a bigger impact with this patch (because the fwnode > > > > links are no longer anchored on "compatible" nodes). > > > > > > > > With/without this patch (let's keep the series) can you look at how > > > > the following things change between each step you do above (add, > > > > remove, retry): > > > > 1) List of directories under /sys/class/devlink > > > > 2) Enable the debug logs inside __fwnode_link_add(), > > > > __fwnode_link_del(), device_link_add() > > > > > > > > My guess is that the final solution would entail clearing > > > > FWNODE_FLAG_LINKS_ADDED for some fwnodes. > > > > > > You replied just as I was about to hit send. So sending this anyway... > > > > > > Ok, I took a closer look and I think it's a bit of a mess. The fact > > > that it even worked for you without this patch is a bit of a > > > coincidence. > > > > > > Let's just take platform devices that are created by > > > driver/of/platform.c as an example. > > > > > > The main problem is that when you add/remove properties to a DT node > > > of an existing platform device, nothing is really done about it at the > > > device level. We don't even unbind and rebind the driver so the driver > > > could make use of the new properties. We don't remove and add back the > > > device so whoever might use the new property will use it. And if you > > > are adding a new node, it'll only trigger any platform device level > > > impact if it's a new node of a "simple-bus" (or similar bus) device. > > > > > > Problem 1: > > > So if you add a new child node to an existing probed device that adds > > > its children explicitly (as in, the parent is not a "simple-bus" like > > > device), nothing will happen. The newly added child device node will > > > get converted into a platform device, not will the parent device > > > notice it. So in your case of adding msiof0_pins, it's just that when > > > the consumer gets the pins, the driver doesn't get involved much and > > > it's the pinctrl framework that reads the DT and figures it out. > > > > > > With this patch, the fwnode links point to the actual resource and the > > > actual parent device inherits them if they don't get converted to a > > > struct device. But since we are adding this msiof0_pins after the > > > parent device has probed, the fwnode link isn't inherited by the > > > parent pinctrl device. > > > > > > Problem 2: > > > So if you add a property to an already bound device, nothing is done > > > by the driver. In your overlay example, if you move the status="okay" > > > line to be the first property you change in the msiof0 spi device, > > > you'll probably see that fw_devlink is no longer the one blocking the > > > probe. This is because the platform device will get added as soon as > > > the status flips from disabled to enabled and at that point fw_devlink > > > will think it has no suppliers and won't do any probe deferring. And > > > then as the new properties get added nothing will happen at the device > > > or fw_devlink level. If the msiof0's spi driver fails immediately with > > > NOT -EPROBE_DEFER when platform device is added because it couldn't > > > find any pinctrl property, then msiof0 will never probe (unless you > > > remove and add the driver). If it had failed with -EPROBE_DEFER, then > > > it might probe again if something else triggers a deferred probe > > > attempt. Clearly, things working/not working based on the order of > > > properties in DT is not a good implementation. > > > > > > Problem 3: > > > What if you enable a previously disabled supplier. There's no way to > > > handle that from a fw_devlink level without re-parsing the entire > > > device tree because existing devices might be consumers now. > > > > > > Anyway, long story short, it's sorta worked due to coincidence and > > > it's quite messy to get it to work correctly. > > > > Several subsystems register notifiers to be informed of the events > > above. E.g. drivers/spi/spi.c: > > > > if (IS_ENABLED(CONFIG_OF_DYNAMIC)) > > WARN_ON(of_reconfig_notifier_register(&spi_of_notifier)); > > if (IS_ENABLED(CONFIG_ACPI)) > > WARN_ON(acpi_reconfig_notifier_register(&spi_acpi_notifier)); > > > > So my issue might be triggered using ACPI, too. > > Yeah, I did notice this before my email. Here's an ugly hack (at end > of email) to test my theory about Problem 1. I didn't compile test it > (because I should go to bed now), but you get the idea. Can you give > this a shot? It should fix your specific case. Basically for all > overlays (I hope the function is only used for overlays) we assume all > nodes are NOT devices until they actually get added as a device. Don't > review the code, it's not meant to be :) > > -Saravana > > --- a/drivers/of/dynamic.c > +++ b/drivers/of/dynamic.c > @@ -226,6 +226,7 @@ static void __of_attach_node(struct device_node *np) > np->sibling = np->parent->child; > np->parent->child = np; > of_node_clear_flag(np, OF_DETACHED); > + np->fwnode.flags |= FWNODE_FLAG_NOT_DEVICE; > } > > /** > diff --git a/drivers/of/platform.c b/drivers/of/platform.c > index 81c8c227ab6b..7299cd668e51 100644 > --- a/drivers/of/platform.c > +++ b/drivers/of/platform.c > @@ -732,6 +732,7 @@ static int of_platform_notify(struct notifier_block *nb, > if (of_node_check_flag(rd->dn, OF_POPULATED)) > return NOTIFY_OK; > > + rd->dn->fwnode.flags &= ~FWNODE_FLAG_NOT_DEVICE; > /* pdev_parent may be NULL when no bus platform device */ > pdev_parent = of_find_device_by_node(rd->dn->parent); > pdev = of_platform_device_create(rd->dn, NULL, > diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c > index 15f174f4e056..1de55561b25d 100644 > --- a/drivers/spi/spi.c > +++ b/drivers/spi/spi.c > @@ -4436,6 +4436,7 @@ static int of_spi_notify(struct notifier_block > *nb, unsigned long action, > return NOTIFY_OK; > } > > + rd->dn->fwnode.flags &= ~FWNODE_FLAG_NOT_DEVICE; > spi = of_register_spi_device(ctlr, rd->dn); > put_device(&ctlr->dev); Thanks, these changes fix my SPI EEPROM in a DT overlay. A similar change should be applied to the i2c bus core (and to other users of of_reconfig_notifier_register()?). For reference, the same debug output and /sys/class/devlink changes with this fix applied can be found below. Note that there are still a few remaining issues, for which I do not know the full impact: - platform:e6060000.pinctrl--platform:keys link is not recreated on overlay remove, - There is no change in /sys/class/devlink after an add/remove/add cycle. Shouldn't removing a DT overlay restore /sys/class/devlink to the exact same state as before adding the DT overlay? With extra FWNODE_FLAG_NOT_DEVICE handling: - Adding overlay: spi@e6e90000 Linked as a fwnode consumer to interrupt-controller@f1010000 spi@e6e90000 Linked as a fwnode consumer to clock-controller@e6150000 spi@e6e90000 Linked as a fwnode consumer to system-controller@e6180000 spi@e6e90000 Linked as a fwnode consumer to msiof0 spi@e6e90000 Linked as a fwnode consumer to gpio@e6055000 platform e6e90000.spi: Linked as a consumer to e6055000.gpio spi@e6e90000 Dropping the fwnode link to gpio@e6055000 platform e6e90000.spi: Linked as a consumer to e6060000.pinctrl spi@e6e90000 Dropping the fwnode link to msiof0 spi@e6e90000 Dropping the fwnode link to system-controller@e6180000 platform e6e90000.spi: Linked as a consumer to e6150000.clock-controller spi@e6e90000 Dropping the fwnode link to clock-controller@e6150000 platform e6e90000.spi: Linked as a consumer to soc spi@e6e90000 Dropping the fwnode link to interrupt-controller@f1010000 +platform:e6055000.gpio--platform:e6e90000.spi -> ../../devices/virtual/devlink/platform:e6055000.gpio--platform:e6e90000.spi +platform:e6060000.pinctrl--platform:e6e90000.spi -> ../../devices/virtual/devlink/platform:e6060000.pinctrl--platform:e6e90000.spi +platform:e6150000.clock-controller--platform:e6e90000.spi -> ../../devices/virtual/devlink/platform:e6150000.clock-controller--platform:e6e90000.spi +platform:soc--platform:e6e90000.spi -> ../../devices/virtual/devlink/platform:soc--platform:e6e90000.spi -platform:e6060000.pinctrl--platform:keys -> ../../devices/virtual/devlink/platform:e6060000.pinctrl--platform:keys SPI EEPROM works - Removing overlay: platform keys: Linked as a sync state only consumer to e6055000.gpio -platform:e6055000.gpio--platform:e6e90000.spi -> ../../devices/virtual/devlink/platform:e6055000.gpio--platform:e6e90000.spi -platform:e6060000.pinctrl--platform:e6e90000.spi -> ../../devices/virtual/devlink/platform:e6060000.pinctrl--platform:e6e90000.spi -platform:e6150000.clock-controller--platform:e6e90000.spi -> ../../devices/virtual/devlink/platform:e6150000.clock-controller--platform:e6e90000.spi -platform:soc--platform:e6e90000.spi -> ../../devices/virtual/devlink/platform:soc--platform:e6e90000.spi platform:e6060000.pinctrl--platform:keys link is not recreated?!?!? - Adding overlay again: No debug output No change in sys/class/devlink?!?!? SPI EEPROM works Gr{oetje,eeting}s, Geert
Hi, * Saravana Kannan <saravanak@google.com> [230207 01:42]: > Naresh, Tony, Abel, Geert, Dmitry, Maxim(s), Miquel, Luca, Doug, Martin, > Jean-Philippe, > > Can I get your Tested-by's for this v3 series please? Just FYI, the patches in next-20230215 behave for me. Regards, Tony
Hi Saravana, On Mon, Feb 06, 2023 at 05:41:52PM -0800, Saravana Kannan wrote: > Naresh, Tony, Abel, Geert, Dmitry, Maxim(s), Miquel, Luca, Doug, Martin, > Jean-Philippe, > > Can I get your Tested-by's for this v3 series please? Sorry for the delay (I misconfigured my inbox). I tested virtio-iommu with these changes, no regression: Tested-by: Jean-Philippe Brucker <jpb@kernel.org> Removing driver_deferred_probe_check_state() by reverting [1] breaks loading virtio-iommu as a module, as the dependency between PCI devices and PCI IOMMU is ignored, and the device probed too early [2]. I'll try to figure out how to make that work. Thanks, Jean [1] https://lore.kernel.org/lkml/20220819221616.2107893-5-saravanak@google.com/ [2] https://lore.kernel.org/lkml/Yv+dpeIPvde7oDHi@myrica/
On 07/02/2023 03:41, Saravana Kannan wrote: > Naresh, Tony, Abel, Geert, Dmitry, Maxim(s), Miquel, Luca, Doug, Martin, > Jean-Philippe, > > Can I get your Tested-by's for this v3 series please? > > Vladimir, > > Ccing you because DSA's and fw_devlink have known/existing problems > (still in my TODOs to fix). But I want to make sure this series doesn't > cause additional problems for DSA. > > All, > > This patch series improves fw_devlink in the following ways: > > 1. It no longer cares about a fwnode having a "compatible" property. It > figures this out more dynamically. The only expectation is that > fwnodes that are converted to devices actually get probed by a driver > for the dependencies to be enforced correctly. > > 2. Finer grained dependency tracking. fw_devlink will now create device > links from the consumer to the actual resource's device (if it has one, > Eg: gpio_device) instead of the parent supplier device. This improves > things like async suspend/resume ordering, potentially remove the need > for frameworks to create device links, more parallelized async probing, > and better sync_state() tracking. > > 3. Handle hardware/software quirks where a child firmware node gets > populated as a device before its parent firmware node AND actually > supplies a non-optional resource to the parent firmware node's > device. > > 4. Way more robust at cycle handling (see patch for the insane cases). > > 5. Stops depending on OF_POPULATED to figure out some corner cases. > > 6. Simplifies the work that needs to be done by the firmware specific > code. > > The v3 series has gone through my usual testing on my end and looks good > to me. Saravana, Please excuse me, I was completely overwhelmed with my regular work and had no time to properly test the series, while doing just the light test would defeat the purpose of testing. Tested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> # Qualcomm RB3 Thanks a lot for going through all the troubles and hunting all the issues! Just a note: on an RB3 device (arm64 qcom/sdm845-db845c.dtsi) extended with the patch at [3] I got the following messages in dmesg: [ 1.051325] platform ae00000.mdss: Failed to create device link with ae00000.mdss [ 1.059368] platform ae00000.mdss: Failed to create device link with ae00000.mdss [ 1.067174] platform ae00000.mdss: Failed to create device link with ae00000.mdss [ 1.088322] platform c440000.spmi: Failed to create device link with c440000.spmi [ 1.096019] platform c440000.spmi: Failed to create device link with c440000.spmi [ 1.103707] platform c440000.spmi: Failed to create device link with c440000.spmi [ 1.111400] platform c440000.spmi: Failed to create device link with c440000.spmi [ 1.119141] platform c440000.spmi: Failed to create device link with c440000.spmi [ 1.126825] platform c440000.spmi: Failed to create device link with c440000.spmi [ 2.024763] qcom-lab-ibb-regulator c440000.spmi:pmic@3:labibb: Failed to create device link with c440000.spmi [ 2.035026] qcom-lab-ibb-regulator c440000.spmi:pmic@3:labibb: Failed to create device link with c440000.spmi They look to be harmless, but it might be good to filter some of them out? Especially the ones which tell about creating a device link pointing back to the same device. [3] https://lore.kernel.org/linux-arm-msm/20230118082048.2198715-1-dmitry.baryshkov@linaro.org/ > > Thanks, > Saravana > > [1] - https://lore.kernel.org/lkml/20220810060040.321697-1-saravanak@google.com/ > [2] - https://lore.kernel.org/lkml/CAGETcx-JUV1nj8wBJrTPfyvM7=Mre5j_vkVmZojeiumUGG6QZQ@mail.gmail.com/ > > v1 -> v2: > - Fixed Patch 1 to handle a corner case discussed in [2]. > - New patch 10 to handle "fsl,imx8mq-gpc" being initialized by 2 drivers. > - New patch 11 to add fw_devlink support for SCMI devices. > > v2 -> v3: > - Addressed most of Andy's comments in v2 > - Added Colin and Sudeep's Tested-by for the series (except the imx and > renesas patches) > - Added Sudeep's Acked-by for the scmi patch. > - Added Geert's Reviewed-by for the renesas patch. > - Fixed gpiolib crash reported by Naresh. > - Patch 6: Fix __fwnode_links_move_consumers() to preserve fwnode link flags. > - New Patch 12 to fix nvmem-cells issue reported by Maxim(s)/Miquel. > - Deleted some stale function doc in Patch 8 > > Cc: Abel Vesa <abel.vesa@linaro.org> > Cc: Alexander Stein <alexander.stein@ew.tq-group.com> > Cc: Tony Lindgren <tony@atomide.com> > Cc: Sudeep Holla <sudeep.holla@arm.com> > Cc: Geert Uytterhoeven <geert@linux-m68k.org> > Cc: John Stultz <jstultz@google.com> > Cc: Doug Anderson <dianders@chromium.org> > Cc: Guenter Roeck <linux@roeck-us.net> > Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> > Cc: Maxim Kiselev <bigunclemax@gmail.com> > Cc: Maxim Kochetkov <fido_max@inbox.ru> > Cc: Miquel Raynal <miquel.raynal@bootlin.com> > Cc: Luca Weiss <luca.weiss@fairphone.com> > Cc: Colin Foster <colin.foster@in-advantage.com> > Cc: Martin Kepplinger <martin.kepplinger@puri.sm> > Cc: Jean-Philippe Brucker <jpb@kernel.org> > Cc: Vladimir Oltean <vladimir.oltean@nxp.com> > > Saravana Kannan (12): > driver core: fw_devlink: Don't purge child fwnode's consumer links > driver core: fw_devlink: Improve check for fwnode with no > device/driver > soc: renesas: Move away from using OF_POPULATED for fw_devlink > gpiolib: Clear the gpio_device's fwnode initialized flag before adding > driver core: fw_devlink: Add DL_FLAG_CYCLE support to device links > driver core: fw_devlink: Allow marking a fwnode link as being part of > a cycle > driver core: fw_devlink: Consolidate device link flag computation > driver core: fw_devlink: Make cycle detection more robust > of: property: Simplify of_link_to_phandle() > irqchip/irq-imx-gpcv2: Mark fwnode device as not initialized > firmware: arm_scmi: Set fwnode for the scmi_device > mtd: mtdpart: Don't create platform device that'll never probe > > drivers/base/core.c | 449 +++++++++++++++++++++----------- > drivers/firmware/arm_scmi/bus.c | 3 +- > drivers/gpio/gpiolib.c | 7 + > drivers/irqchip/irq-imx-gpcv2.c | 1 + > drivers/mtd/mtdpart.c | 10 + > drivers/of/property.c | 84 +----- > drivers/soc/imx/gpcv2.c | 2 +- > drivers/soc/renesas/rcar-sysc.c | 2 +- > include/linux/device.h | 1 + > include/linux/fwnode.h | 12 +- > 10 files changed, 344 insertions(+), 227 deletions(-) > -- With best wishes Dmitry
On Wed, Feb 15, 2023 at 7:12 PM Dmitry Baryshkov <dmitry.baryshkov@linaro.org> wrote: > > On 07/02/2023 03:41, Saravana Kannan wrote: > > Naresh, Tony, Abel, Geert, Dmitry, Maxim(s), Miquel, Luca, Doug, Martin, > > Jean-Philippe, > > > > Can I get your Tested-by's for this v3 series please? > > > > Vladimir, > > > > Ccing you because DSA's and fw_devlink have known/existing problems > > (still in my TODOs to fix). But I want to make sure this series doesn't > > cause additional problems for DSA. > > > > All, > > > > This patch series improves fw_devlink in the following ways: > > > > 1. It no longer cares about a fwnode having a "compatible" property. It > > figures this out more dynamically. The only expectation is that > > fwnodes that are converted to devices actually get probed by a driver > > for the dependencies to be enforced correctly. > > > > 2. Finer grained dependency tracking. fw_devlink will now create device > > links from the consumer to the actual resource's device (if it has one, > > Eg: gpio_device) instead of the parent supplier device. This improves > > things like async suspend/resume ordering, potentially remove the need > > for frameworks to create device links, more parallelized async probing, > > and better sync_state() tracking. > > > > 3. Handle hardware/software quirks where a child firmware node gets > > populated as a device before its parent firmware node AND actually > > supplies a non-optional resource to the parent firmware node's > > device. > > > > 4. Way more robust at cycle handling (see patch for the insane cases). > > > > 5. Stops depending on OF_POPULATED to figure out some corner cases. > > > > 6. Simplifies the work that needs to be done by the firmware specific > > code. > > > > The v3 series has gone through my usual testing on my end and looks good > > to me. > > Saravana, > > Please excuse me, I was completely overwhelmed with my regular work and > had no time to properly test the series, while doing just the light > test would defeat the purpose of testing. > > Tested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> # Qualcomm RB3 > > Thanks a lot for going through all the troubles and hunting all the issues! You are welcome! Thanks for testing it. > Just a note: on an RB3 device (arm64 qcom/sdm845-db845c.dtsi) extended > with the patch at [3] I got the following messages in dmesg: > > [ 1.051325] platform ae00000.mdss: Failed to create device link > with ae00000.mdss > [ 1.059368] platform ae00000.mdss: Failed to create device link > with ae00000.mdss > [ 1.067174] platform ae00000.mdss: Failed to create device link > with ae00000.mdss > [ 1.088322] platform c440000.spmi: Failed to create device link > with c440000.spmi > [ 1.096019] platform c440000.spmi: Failed to create device link > with c440000.spmi > [ 1.103707] platform c440000.spmi: Failed to create device link > with c440000.spmi > [ 1.111400] platform c440000.spmi: Failed to create device link > with c440000.spmi > [ 1.119141] platform c440000.spmi: Failed to create device link > with c440000.spmi > [ 1.126825] platform c440000.spmi: Failed to create device link > with c440000.spmi > [ 2.024763] qcom-lab-ibb-regulator c440000.spmi:pmic@3:labibb: > Failed to create device link with c440000.spmi > [ 2.035026] qcom-lab-ibb-regulator c440000.spmi:pmic@3:labibb: > Failed to create device link with c440000.spmi > > They look to be harmless, but it might be good to filter some of them > out? Especially the ones which tell about creating a device link > pointing back to the same device. I'm sure it's harmless when the supplier == consumer. Agreed on filtering these out. I looked at [3], but it's not obvious to me how this is happening for your specific case. There are a couple of ways I can think of: 1. A SYNC_STATE_ONLY link being created as a proxy link (I don't do as many checks here because it can't break anything) 2. __fw_devlink_pickup_dangling_consumers() causing the consumer and supplier to be the same. But I want to understand which one is happening in your case. Can you add a WARN_ON(1) after the error message and give me the list of stack dumps that are unique? Thanks, Saravana > > [3] https://lore.kernel.org/linux-arm-msm/20230118082048.2198715-1-dmitry.baryshkov@linaro.org/ > > > > > Thanks, > > Saravana > > > > [1] - https://lore.kernel.org/lkml/20220810060040.321697-1-saravanak@google.com/ > > [2] - https://lore.kernel.org/lkml/CAGETcx-JUV1nj8wBJrTPfyvM7=Mre5j_vkVmZojeiumUGG6QZQ@mail.gmail.com/ > > > > v1 -> v2: > > - Fixed Patch 1 to handle a corner case discussed in [2]. > > - New patch 10 to handle "fsl,imx8mq-gpc" being initialized by 2 drivers. > > - New patch 11 to add fw_devlink support for SCMI devices. > > > > v2 -> v3: > > - Addressed most of Andy's comments in v2 > > - Added Colin and Sudeep's Tested-by for the series (except the imx and > > renesas patches) > > - Added Sudeep's Acked-by for the scmi patch. > > - Added Geert's Reviewed-by for the renesas patch. > > - Fixed gpiolib crash reported by Naresh. > > - Patch 6: Fix __fwnode_links_move_consumers() to preserve fwnode link flags. > > - New Patch 12 to fix nvmem-cells issue reported by Maxim(s)/Miquel. > > - Deleted some stale function doc in Patch 8 > > > > Cc: Abel Vesa <abel.vesa@linaro.org> > > Cc: Alexander Stein <alexander.stein@ew.tq-group.com> > > Cc: Tony Lindgren <tony@atomide.com> > > Cc: Sudeep Holla <sudeep.holla@arm.com> > > Cc: Geert Uytterhoeven <geert@linux-m68k.org> > > Cc: John Stultz <jstultz@google.com> > > Cc: Doug Anderson <dianders@chromium.org> > > Cc: Guenter Roeck <linux@roeck-us.net> > > Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> > > Cc: Maxim Kiselev <bigunclemax@gmail.com> > > Cc: Maxim Kochetkov <fido_max@inbox.ru> > > Cc: Miquel Raynal <miquel.raynal@bootlin.com> > > Cc: Luca Weiss <luca.weiss@fairphone.com> > > Cc: Colin Foster <colin.foster@in-advantage.com> > > Cc: Martin Kepplinger <martin.kepplinger@puri.sm> > > Cc: Jean-Philippe Brucker <jpb@kernel.org> > > Cc: Vladimir Oltean <vladimir.oltean@nxp.com> > > > > Saravana Kannan (12): > > driver core: fw_devlink: Don't purge child fwnode's consumer links > > driver core: fw_devlink: Improve check for fwnode with no > > device/driver > > soc: renesas: Move away from using OF_POPULATED for fw_devlink > > gpiolib: Clear the gpio_device's fwnode initialized flag before adding > > driver core: fw_devlink: Add DL_FLAG_CYCLE support to device links > > driver core: fw_devlink: Allow marking a fwnode link as being part of > > a cycle > > driver core: fw_devlink: Consolidate device link flag computation > > driver core: fw_devlink: Make cycle detection more robust > > of: property: Simplify of_link_to_phandle() > > irqchip/irq-imx-gpcv2: Mark fwnode device as not initialized > > firmware: arm_scmi: Set fwnode for the scmi_device > > mtd: mtdpart: Don't create platform device that'll never probe > > > > drivers/base/core.c | 449 +++++++++++++++++++++----------- > > drivers/firmware/arm_scmi/bus.c | 3 +- > > drivers/gpio/gpiolib.c | 7 + > > drivers/irqchip/irq-imx-gpcv2.c | 1 + > > drivers/mtd/mtdpart.c | 10 + > > drivers/of/property.c | 84 +----- > > drivers/soc/imx/gpcv2.c | 2 +- > > drivers/soc/renesas/rcar-sysc.c | 2 +- > > include/linux/device.h | 1 + > > include/linux/fwnode.h | 12 +- > > 10 files changed, 344 insertions(+), 227 deletions(-) > > > > -- > With best wishes > > Dmitry
Naresh, Tony, Abel, Geert, Dmitry, Maxim(s), Miquel, Luca, Doug, Martin, Jean-Philippe, Can I get your Tested-by's for this v3 series please? Vladimir, Ccing you because DSA's and fw_devlink have known/existing problems (still in my TODOs to fix). But I want to make sure this series doesn't cause additional problems for DSA. All, This patch series improves fw_devlink in the following ways: 1. It no longer cares about a fwnode having a "compatible" property. It figures this out more dynamically. The only expectation is that fwnodes that are converted to devices actually get probed by a driver for the dependencies to be enforced correctly. 2. Finer grained dependency tracking. fw_devlink will now create device links from the consumer to the actual resource's device (if it has one, Eg: gpio_device) instead of the parent supplier device. This improves things like async suspend/resume ordering, potentially remove the need for frameworks to create device links, more parallelized async probing, and better sync_state() tracking. 3. Handle hardware/software quirks where a child firmware node gets populated as a device before its parent firmware node AND actually supplies a non-optional resource to the parent firmware node's device. 4. Way more robust at cycle handling (see patch for the insane cases). 5. Stops depending on OF_POPULATED to figure out some corner cases. 6. Simplifies the work that needs to be done by the firmware specific code. The v3 series has gone through my usual testing on my end and looks good to me. Thanks, Saravana [1] - https://lore.kernel.org/lkml/20220810060040.321697-1-saravanak@google.com/ [2] - https://lore.kernel.org/lkml/CAGETcx-JUV1nj8wBJrTPfyvM7=Mre5j_vkVmZojeiumUGG6QZQ@mail.gmail.com/ v1 -> v2: - Fixed Patch 1 to handle a corner case discussed in [2]. - New patch 10 to handle "fsl,imx8mq-gpc" being initialized by 2 drivers. - New patch 11 to add fw_devlink support for SCMI devices. v2 -> v3: - Addressed most of Andy's comments in v2 - Added Colin and Sudeep's Tested-by for the series (except the imx and renesas patches) - Added Sudeep's Acked-by for the scmi patch. - Added Geert's Reviewed-by for the renesas patch. - Fixed gpiolib crash reported by Naresh. - Patch 6: Fix __fwnode_links_move_consumers() to preserve fwnode link flags. - New Patch 12 to fix nvmem-cells issue reported by Maxim(s)/Miquel. - Deleted some stale function doc in Patch 8 Cc: Abel Vesa <abel.vesa@linaro.org> Cc: Alexander Stein <alexander.stein@ew.tq-group.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Sudeep Holla <sudeep.holla@arm.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: John Stultz <jstultz@google.com> Cc: Doug Anderson <dianders@chromium.org> Cc: Guenter Roeck <linux@roeck-us.net> Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Cc: Maxim Kiselev <bigunclemax@gmail.com> Cc: Maxim Kochetkov <fido_max@inbox.ru> Cc: Miquel Raynal <miquel.raynal@bootlin.com> Cc: Luca Weiss <luca.weiss@fairphone.com> Cc: Colin Foster <colin.foster@in-advantage.com> Cc: Martin Kepplinger <martin.kepplinger@puri.sm> Cc: Jean-Philippe Brucker <jpb@kernel.org> Cc: Vladimir Oltean <vladimir.oltean@nxp.com> Saravana Kannan (12): driver core: fw_devlink: Don't purge child fwnode's consumer links driver core: fw_devlink: Improve check for fwnode with no device/driver soc: renesas: Move away from using OF_POPULATED for fw_devlink gpiolib: Clear the gpio_device's fwnode initialized flag before adding driver core: fw_devlink: Add DL_FLAG_CYCLE support to device links driver core: fw_devlink: Allow marking a fwnode link as being part of a cycle driver core: fw_devlink: Consolidate device link flag computation driver core: fw_devlink: Make cycle detection more robust of: property: Simplify of_link_to_phandle() irqchip/irq-imx-gpcv2: Mark fwnode device as not initialized firmware: arm_scmi: Set fwnode for the scmi_device mtd: mtdpart: Don't create platform device that'll never probe drivers/base/core.c | 449 +++++++++++++++++++++----------- drivers/firmware/arm_scmi/bus.c | 3 +- drivers/gpio/gpiolib.c | 7 + drivers/irqchip/irq-imx-gpcv2.c | 1 + drivers/mtd/mtdpart.c | 10 + drivers/of/property.c | 84 +----- drivers/soc/imx/gpcv2.c | 2 +- drivers/soc/renesas/rcar-sysc.c | 2 +- include/linux/device.h | 1 + include/linux/fwnode.h | 12 +- 10 files changed, 344 insertions(+), 227 deletions(-)