On 26 October 2015 at 09:16, Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote: > On Mon, Sep 21, 2015 at 4:02 PM, Tomeu Vizoso > <tomeu.vizoso@xxxxxxxxxxxxx> wrote: >> Walks the OF tree up and finds the closest ancestor that has a struct >> device associated with it, probing it if isn't bound to a driver yet. >> >> The above should ensure that the dependency represented by the passed OF >> node is available, because probing a device should cause its descendants >> to be probed as well (when they get registered). >> >> Subsystems can use this when looking up resources for drivers, to reduce >> the chances of deferred probes because of the probing order of devices. >> >> Signed-off-by: Tomeu Vizoso <tomeu.vizoso@xxxxxxxxxxxxx> > > Don't know to which response I should post this comment, so I'm responding > to the original email. > > Some subsystems already do this. > If you call e.g. syscon_regmap_lookup_by_phandle(), it will call > of_syscon_register() if the syscon device pointed to hasn't been registered yet. Hi Geert, I think I prefer if devices are registered as early as possible and then only probed on-demand, as registration is very much device-specific but probing is the same for all devices. But I think in general we should be doing more things on demand and depending less on the order in which we mass initialize stuff (devices, classes, drivers, etc). Regards, Tomeu > 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 > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html