Hi Saravana, On Fri, Jul 1, 2022 at 1:11 AM Saravana Kannan <saravanak@xxxxxxxxxx> wrote: > On Mon, Jun 27, 2022 at 2:10 AM Tony Lindgren <tony@xxxxxxxxxxx> wrote: > > * Saravana Kannan <saravanak@xxxxxxxxxx> [220623 08:17]: > > > On Thu, Jun 23, 2022 at 12:01 AM Tony Lindgren <tony@xxxxxxxxxxx> wrote: > > > > * Saravana Kannan <saravanak@xxxxxxxxxx> [220622 19:05]: > > > > > On Tue, Jun 21, 2022 at 9:59 PM Tony Lindgren <tony@xxxxxxxxxxx> wrote: > > > > > > This issue is no directly related fw_devlink. It is a side effect of > > > > > > removing driver_deferred_probe_check_state(). We no longer return > > > > > > -EPROBE_DEFER at the end of driver_deferred_probe_check_state(). > > > > > > > > > > Yes, I understand the issue. But driver_deferred_probe_check_state() > > > > > was deleted because fw_devlink=on should have short circuited the > > > > > probe attempt with an -EPROBE_DEFER before reaching the bus/driver > > > > > probe function and hitting this -ENOENT failure. That's why I was > > > > > asking the other questions. > > > > > > > > OK. So where is the -EPROBE_DEFER supposed to happen without > > > > driver_deferred_probe_check_state() then? > > > > > > device_links_check_suppliers() call inside really_probe() would short > > > circuit and return an -EPROBE_DEFER if the device links are created as > > > expected. > > > > OK > > > > > > Hmm so I'm not seeing any supplier for the top level ocp device in > > > > the booting case without your patches. I see the suppliers for the > > > > ocp child device instances only. > > > > > > Hmmm... this is strange (that the device link isn't there), but this > > > is what I suspected. > > > > Yup, maybe it's because of the supplier being a device in the child > > interconnect for the ocp. > > Ugh... yeah, this is why the normal (not SYNC_STATE_ONLY) device link > isn't being created. > > So the aggregated view is something like (I had to set tabs = 4 space > to fit it within 80 cols): > > ocp: ocp { <========================= Consumer > compatible = "simple-pm-bus"; > power-domains = <&prm_per>; <=========== Supplier ref > > l4_wkup: interconnect@44c00000 { > compatible = "ti,am33xx-l4-wkup", "simple-pm-bus"; > > segment@200000 { /* 0x44e00000 */ > compatible = "simple-pm-bus"; > > target-module@0 { /* 0x44e00000, ap 8 58.0 */ > compatible = "ti,sysc-omap4", "ti,sysc"; > > prcm: prcm@0 { > compatible = "ti,am3-prcm", "simple-bus"; > > prm_per: prm@c00 { <========= Actual Supplier > compatible = "ti,am3-prm-inst", "ti,omap-prm-inst"; > }; > }; > }; > }; > }; > }; > > The power-domain supplier is the great-great-great-grand-child of the > consumer. It's not clear to me how this is valid. What does it even > mean? > > Rob, is this considered a valid DT? > > Geert, thoughts on whether this is a correct use of simple-pm-bus device? Well, if the hardware is wired that way... It's not that dissimilar from CPU cores, and interrupt and GPIO controllers in power domains and clocked by controllable clocks: you can cut the branch you're sitting on, and you have to be careful when going to sleep, and make sure your wake-up sources are still functional. > Also, how is the power domain attach/get working in this case? As far > as I can tell, at least for "simple-pm-bus" devices, the pm domain > attachment is happening under: > really_probe() -> call_driver_probe -> platform_probe() -> > dev_pm_domain_attach() > > So, how is the pm domain attach succeeding in the first place without > my changes? That's a software thing ;-) Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx 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