Message ID | 20220810060040.321697-1-saravanak@google.com |
---|---|
Headers | show |
Series | fw_devlink improvements | expand |
Hi, * Saravana Kannan <saravanak@google.com> [220810 05:54]: > 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. This patch fixes booting for me, so it should be applied as a fix and tagged with: Fixes: 5a46079a9645 ("PM: domains: Delete usage of driver_deferred_probe_check_state()") If there are dependencies to the other patches in this series, it might make sense to revert commit 5a46079a9645 instead. Anyways, thanks for fixing the issue, for this patch: Reviewed-by: Tony Lindgren <tony@atomide.com> Tested-by: Tony Lindgren <tony@atomide.com> For the process, looks like the earlier series got merged despite the issues reported. And we had non-booting Linux next for at least some SoCs for weeks. And now we are about to have a non-booting -rc1 unless things get fixed fast. Annoying glitches, sigh.. Regards, Tony
On Fri, Aug 12, 2022 at 2:47 AM Tony Lindgren <tony@atomide.com> wrote: > > Hi, > > * Saravana Kannan <saravanak@google.com> [220810 05:54]: > > 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. > > This patch fixes booting for me, so it should be applied as a fix and > tagged with: > > Fixes: 5a46079a9645 ("PM: domains: Delete usage of driver_deferred_probe_check_state()") > > If there are dependencies to the other patches in this series, it might > make sense to revert commit 5a46079a9645 instead. Yes, there are dependencies on the rest of the patches in this series. For linux-next, I think we should pick up this series once we get more Tested-bys. So if 5a46079a9645 is causing any regression in stable branches, we should pick up the revert series [1] instead of this series we are replying to. [1] - https://lore.kernel.org/all/20220727185012.3255200-1-saravanak@google.com/ > Anyways, thanks for fixing the issue, for this patch: > > Reviewed-by: Tony Lindgren <tony@atomide.com> > Tested-by: Tony Lindgren <tony@atomide.com> Thanks! > For the process, looks like the earlier series got merged despite the > issues reported. If I'm not mistaken, the issues were reported after the series got picked up. And the series got some tested-by s before it was picked up. And once it's in git history, we obviously can't drop it. > And we had non-booting Linux next for at least some SoCs > for weeks. And now we are about to have a non-booting -rc1 unless things > get fixed fast. Annoying glitches, sigh.. Sorry for breaking some boards -- so mean "creative" corner cases :) This rewrite is way more flexible (removes a lot of limitations in fw_devlink) and hopefully this handles all the corner cases. We'll see. -Saravana
+Naresh Kamboju On Tue, Aug 9, 2022 at 11:00 PM Saravana Kannan <saravanak@google.com> wrote: > > 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 our more dynamically. The only expectation is that > fwnode 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. > > This took way too long to get done due to typo bugs I had in my rewrite or > corner cases I had to find and handle. But it's fairly well tested at this > point and I expect this to work properly. > > Abel & Doug, > > This should fix your cyclic dependency issues with your display. Can you > give it a shot please? > > Alexander, > > This should fix your issue where the power domain device not having a > compatible property. Can you give it a shot please? > > Tony, > > This should handle the odd case of the child being the supplier of the > parent. Can you please give this a shot? I want to make sure the cycle > detection code handles this properly and treats it like it's NOT a cycle. > > Geert, > > Can you test the renesas stuff I changed please? They should continue > working like before. Any other sanity test on other hardware would be > great too. > > Sudeep, > > I don't think there are any unfixed issues you had reported in my other > patches that this series might fix, but it'll be nice if you could give > this a sanity test. > > Guenter, > > I don't think this will fix the issue you reported in the amba patch, but > it's worth a shot because it improves a bunch of corner case handling. So > it might be better at handling whatever corner cases you might have in the > qemu platforms. Hi Naresh, Thanks for testing these patches in the other thread. Mind giving your tested-by here? I know you tested these patches in X15, but were there also other boards these patches were tested on as part of the run? Thanks, Saravana > > Thanks, > Saravana > > 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> > > Saravana Kannan (9): > 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() > > drivers/base/core.c | 437 +++++++++++++++++++++----------- > drivers/gpio/gpiolib.c | 6 + > drivers/of/property.c | 84 +----- > drivers/soc/renesas/rcar-sysc.c | 2 +- > include/linux/device.h | 1 + > include/linux/fwnode.h | 12 +- > 6 files changed, 323 insertions(+), 219 deletions(-) > > -- > 2.37.1.559.g78731f0fdb-goog >
* Saravana Kannan <saravanak@google.com> [220813 00:30]: > On Fri, Aug 12, 2022 at 2:47 AM Tony Lindgren <tony@atomide.com> wrote: > > > > Hi, > > > > * Saravana Kannan <saravanak@google.com> [220810 05:54]: > > > 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. > > > > This patch fixes booting for me, so it should be applied as a fix and > > tagged with: > > > > Fixes: 5a46079a9645 ("PM: domains: Delete usage of driver_deferred_probe_check_state()") > > > > If there are dependencies to the other patches in this series, it might > > make sense to revert commit 5a46079a9645 instead. > > Yes, there are dependencies on the rest of the patches in this series. > For linux-next, I think we should pick up this series once we get more > Tested-bys. > > So if 5a46079a9645 is causing any regression in stable branches, we > should pick up the revert series [1] instead of this series we are > replying to. Agreed we should apply the reverts in [1] for v6.0-rc series. At least several generations of the TI 32-bit ARM SoCs are failing to boot otherwise. Regards, Tony
On 22-08-09 23:00:29, Saravana Kannan wrote: > 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 our more dynamically. The only expectation is that > fwnode 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. > > This took way too long to get done due to typo bugs I had in my rewrite or > corner cases I had to find and handle. But it's fairly well tested at this > point and I expect this to work properly. > > Abel & Doug, > > This should fix your cyclic dependency issues with your display. Can you > give it a shot please? Tested the specific case we discussed about here: https://lore.kernel.org/all/CAGETcx8F0wP+RA0KpjOJeZfc=DVG-MbM_=SkRHD4UhD2ReL7Kw@mail.gmail.com/raw Thanks for fixing this. Tested-by: Abel Vesa <abel.vesa@linaro.org> > > Alexander, > > This should fix your issue where the power domain device not having a > compatible property. Can you give it a shot please? > > Tony, > > This should handle the odd case of the child being the supplier of the > parent. Can you please give this a shot? I want to make sure the cycle > detection code handles this properly and treats it like it's NOT a cycle. > > Geert, > > Can you test the renesas stuff I changed please? They should continue > working like before. Any other sanity test on other hardware would be > great too. > > Sudeep, > > I don't think there are any unfixed issues you had reported in my other > patches that this series might fix, but it'll be nice if you could give > this a sanity test. > > Guenter, > > I don't think this will fix the issue you reported in the amba patch, but > it's worth a shot because it improves a bunch of corner case handling. So > it might be better at handling whatever corner cases you might have in the > qemu platforms. > > Thanks, > Saravana > > 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> > > Saravana Kannan (9): > 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() > > drivers/base/core.c | 437 +++++++++++++++++++++----------- > drivers/gpio/gpiolib.c | 6 + > drivers/of/property.c | 84 +----- > drivers/soc/renesas/rcar-sysc.c | 2 +- > include/linux/device.h | 1 + > include/linux/fwnode.h | 12 +- > 6 files changed, 323 insertions(+), 219 deletions(-) > > -- > 2.37.1.559.g78731f0fdb-goog >
On Tue, Aug 09, 2022 at 11:00:29PM -0700, Saravana Kannan wrote: > 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 our more dynamically. The only expectation is that > fwnode 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. > > This took way too long to get done due to typo bugs I had in my rewrite or > corner cases I had to find and handle. But it's fairly well tested at this > point and I expect this to work properly. > > Abel & Doug, > > This should fix your cyclic dependency issues with your display. Can you > give it a shot please? > > Alexander, > > This should fix your issue where the power domain device not having a > compatible property. Can you give it a shot please? > > Tony, > > This should handle the odd case of the child being the supplier of the > parent. Can you please give this a shot? I want to make sure the cycle > detection code handles this properly and treats it like it's NOT a cycle. > > Geert, > > Can you test the renesas stuff I changed please? They should continue > working like before. Any other sanity test on other hardware would be > great too. > > Sudeep, > > I don't think there are any unfixed issues you had reported in my other > patches that this series might fix, but it'll be nice if you could give > this a sanity test. > Sure tested this on Juno on top of v6.0-rc1 and found no regressions. So, Tested-by: Sudeep Holla <sudeep.holla@arm.com> Just wanted to check if the logs are intentional or do you plan to make them debug. On Juno with hardly few such dependencies I get below extra logs during boot, it may add loads on other platforms. I am fine either way, just thought of checking. | amba 20040000.funnel: Fixed dependency cycle(s) with /etf@20010000/in-ports/port/endpoint | amba 20120000.replicator: Fixed dependency cycle(s) with /etr@20070000/in-ports/port/endpoint | amba 20120000.replicator: Fixed dependency cycle(s) with /tpiu@20030000/in-ports/port/endpoint | amba 220c0000.funnel: Fixed dependency cycle(s) with /etm@22040000/out-ports/port/endpoint | amba 220c0000.funnel: Fixed dependency cycle(s) with /funnel@20040000/in-ports/port@0/endpoint | amba 22140000.etm: Fixed dependency cycle(s) with /funnel@220c0000/in-ports/port@1/endpoint | amba 230c0000.funnel: Fixed dependency cycle(s) with /etm@23040000/out-ports/port/endpoint | amba 230c0000.funnel: Fixed dependency cycle(s) with /funnel@20040000/in-ports/port@1/endpoint | amba 23140000.etm: Fixed dependency cycle(s) with /funnel@230c0000/in-ports/port@1/endpoint | amba 23240000.etm: Fixed dependency cycle(s) with /funnel@230c0000/in-ports/port@2/endpoint | amba 23340000.etm: Fixed dependency cycle(s) with /funnel@230c0000/in-ports/port@3/endpoint | amba 20130000.funnel: Fixed dependency cycle(s) with /stm@20100000/out-ports/port/endpoint | amba 20140000.etf: Fixed dependency cycle(s) with /funnel@20130000/out-ports/port/endpoint | amba 20150000.funnel: Fixed dependency cycle(s) with /etf@20140000/out-ports/port/endpoint | amba 20150000.funnel: Fixed dependency cycle(s) with /etf@20010000/out-ports/port/endpoint | amba 20150000.funnel: Fixed dependency cycle(s) with /replicator@20120000/in-ports/port/endpoint | i2c 0-0070: Fixed dependency cycle(s) with /hdlcd@7ff60000/port/endpoint | i2c 0-0071: Fixed dependency cycle(s) with /hdlcd@7ff50000/port/endpoint
On Mon, Aug 15, 2022 at 4:01 AM Abel Vesa <abel.vesa@linaro.org> wrote: > > On 22-08-09 23:00:29, Saravana Kannan wrote: > > 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 our more dynamically. The only expectation is that > > fwnode 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. > > > > This took way too long to get done due to typo bugs I had in my rewrite or > > corner cases I had to find and handle. But it's fairly well tested at this > > point and I expect this to work properly. > > > > Abel & Doug, > > > > This should fix your cyclic dependency issues with your display. Can you > > give it a shot please? > > Tested the specific case we discussed about here: > https://lore.kernel.org/all/CAGETcx8F0wP+RA0KpjOJeZfc=DVG-MbM_=SkRHD4UhD2ReL7Kw@mail.gmail.com/raw > > Thanks for fixing this. > > Tested-by: Abel Vesa <abel.vesa@linaro.org> Thanks! -Saravana > > > > > Alexander, > > > > This should fix your issue where the power domain device not having a > > compatible property. Can you give it a shot please? > > > > Tony, > > > > This should handle the odd case of the child being the supplier of the > > parent. Can you please give this a shot? I want to make sure the cycle > > detection code handles this properly and treats it like it's NOT a cycle. > > > > Geert, > > > > Can you test the renesas stuff I changed please? They should continue > > working like before. Any other sanity test on other hardware would be > > great too. > > > > Sudeep, > > > > I don't think there are any unfixed issues you had reported in my other > > patches that this series might fix, but it'll be nice if you could give > > this a sanity test. > > > > Guenter, > > > > I don't think this will fix the issue you reported in the amba patch, but > > it's worth a shot because it improves a bunch of corner case handling. So > > it might be better at handling whatever corner cases you might have in the > > qemu platforms. > > > > Thanks, > > Saravana > > > > 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> > > > > Saravana Kannan (9): > > 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() > > > > drivers/base/core.c | 437 +++++++++++++++++++++----------- > > drivers/gpio/gpiolib.c | 6 + > > drivers/of/property.c | 84 +----- > > drivers/soc/renesas/rcar-sysc.c | 2 +- > > include/linux/device.h | 1 + > > include/linux/fwnode.h | 12 +- > > 6 files changed, 323 insertions(+), 219 deletions(-) > > > > -- > > 2.37.1.559.g78731f0fdb-goog > >
On Mon, Aug 15, 2022 at 3:31 AM Tony Lindgren <tony@atomide.com> wrote: > > * Saravana Kannan <saravanak@google.com> [220813 00:30]: > > On Fri, Aug 12, 2022 at 2:47 AM Tony Lindgren <tony@atomide.com> wrote: > > > > > > Hi, > > > > > > * Saravana Kannan <saravanak@google.com> [220810 05:54]: > > > > 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. > > > > > > This patch fixes booting for me, so it should be applied as a fix and > > > tagged with: > > > > > > Fixes: 5a46079a9645 ("PM: domains: Delete usage of driver_deferred_probe_check_state()") > > > > > > If there are dependencies to the other patches in this series, it might > > > make sense to revert commit 5a46079a9645 instead. > > > > Yes, there are dependencies on the rest of the patches in this series. > > For linux-next, I think we should pick up this series once we get more > > Tested-bys. > > > > So if 5a46079a9645 is causing any regression in stable branches, we > > should pick up the revert series [1] instead of this series we are > > replying to. > > Agreed we should apply the reverts in [1] for v6.0-rc series. At least > several generations of the TI 32-bit ARM SoCs are failing to boot > otherwise. Actually I wasn't clear in my earlier email. I meant to say "releases branches", as in 5.19.xxx and not "stable branches". So for 5.19.xxx we'd pick up these reverts. And for v6.0-rc if my other patch series [1] fixes the issue, I'd rather apply [1] than this series. Because this series is meant to be temporary (I'll be reverting this in the future). -Saravana [1] - https://lore.kernel.org/lkml/20220810060040.321697-1-saravanak@google.com/
Hello Saravana, Am Montag, 15. August 2022, 21:17:36 CEST schrieb Saravana Kannan: > On Mon, Aug 15, 2022 at 5:39 AM Alexander Stein > > <alexander.stein@ew.tq-group.com> wrote: > > Hello Saravana, > > > > Am Mittwoch, 10. August 2022, 08:00:29 CEST schrieb Saravana Kannan: > > > Alexander, > > > > > > This should fix your issue where the power domain device not having a > > > compatible property. Can you give it a shot please? > > > > thanks for the update. Unfortunately this does not work: > > > [ 0.774838] PM: Added domain provider from /soc@0/bus@30000000/ > > > > gpc@303a0000/pgc/power-domain@0 > > > > > [ 0.775100] imx-pgc imx-pgc-domain.1: __genpd_dev_pm_attach() failed > > > to > > > > find PM domain: -2 > > > > > [ 0.775324] PM: Added domain provider from /soc@0/bus@30000000/ > > > > gpc@303a0000/pgc/power-domain@2 > > > > > [ 0.775601] PM: Added domain provider from /soc@0/bus@30000000/ > > > > gpc@303a0000/pgc/power-domain@3 > > > > > [ 0.775842] PM: Added domain provider from /soc@0/bus@30000000/ > > > > gpc@303a0000/pgc/power-domain@4 > > > > > [ 0.776642] PM: Added domain provider from /soc@0/bus@30000000/ > > > > gpc@303a0000/pgc/power-domain@7 > > > > > [ 0.776897] PM: Added domain provider from /soc@0/bus@30000000/ > > > > gpc@303a0000/pgc/power-domain@8 > > > > > [ 0.777158] PM: Added domain provider from /soc@0/bus@30000000/ > > > > gpc@303a0000/pgc/power-domain@9 > > > > > [ 0.777405] PM: Added domain provider from /soc@0/bus@30000000/ > > > > gpc@303a0000/pgc/power-domain@a > > > > > [ 0.779342] genpd genpd:0:38320000.blk-ctrl: __genpd_dev_pm_attach() > > > > failed to find PM domain: -2 > > > > > [ 0.779422] imx8m-blk-ctrl 38320000.blk-ctrl: error -ENODEV: failed > > > to > > > > attach power domain "bus" > > > > > [ 0.848785] etnaviv-gpu 38000000.gpu: __genpd_dev_pm_attach() failed > > > to > > > > find PM domain: -2 > > > > > [ 1.114220] pfuze100-regulator 0-0008: Full layer: 2, Metal layer: 1 > > > [ 1.122267] pfuze100-regulator 0-0008: FAB: 0, FIN: 0 > > > [ 1.132970] pfuze100-regulator 0-0008: pfuze100 found. > > > [ 1.157011] imx-gpcv2 303a0000.gpc: Failed to create device link with > > > > 0-0008 > > > > > [ 1.164094] imx-gpcv2 303a0000.gpc: Failed to create device link with > > > > 0-0008 > > > > The required power-supply for the power domains is still not yet > > available. > > Does this series require some other patches as well? > > Ah sorry, yeah, this needs additional patches. The one I gave in the > other thread when I debugged this and I also noticed another issue. > Here's the combined diff of what's needed. Can you add this on top of > the series and test it? > > diff --git a/drivers/irqchip/irq-imx-gpcv2.c > b/drivers/irqchip/irq-imx-gpcv2.c index b9c22f764b4d..8a0e82067924 100644 > --- a/drivers/irqchip/irq-imx-gpcv2.c > +++ b/drivers/irqchip/irq-imx-gpcv2.c > @@ -283,6 +283,7 @@ static int __init imx_gpcv2_irqchip_init(struct > device_node *node, > * later the GPC power domain driver will not be skipped. > */ > of_node_clear_flag(node, OF_POPULATED); > + fwnode_dev_initialized(domain->fwnode, false); > return 0; > } > > diff --git a/drivers/soc/imx/gpcv2.c b/drivers/soc/imx/gpcv2.c > index 6383a4edc360..181fbfe5bd4d 100644 > --- a/drivers/soc/imx/gpcv2.c > +++ b/drivers/soc/imx/gpcv2.c > @@ -1513,6 +1513,7 @@ static int imx_gpcv2_probe(struct platform_device > *pdev) > > pd_pdev->dev.parent = dev; > pd_pdev->dev.of_node = np; > + pd_pdev->dev.fwnode = of_fwnode_handle(np); > > ret = platform_device_add(pd_pdev); > if (ret) { > > With this patch, I'd really expect the power domain dependency to be > handled correctly. I was out of office so I didn't keep track of any dependencies, sorry. With these 2 changes above my power domain problem is fixed! Thanks Alexander