On Mon, Jan 14, 2019 at 11:22 PM Sascha Hauer <s.hauer@xxxxxxxxxxxxxx> wrote: > > On Sat, Jan 12, 2019 at 11:49:19AM -0800, Andrey Smirnov wrote: > > On Sat, Jan 12, 2019 at 2:48 AM Sam Ravnborg <sam@xxxxxxxxxxxx> wrote: > > > > > > Hi Andrey. > > > > > > > Feedback is welcome! > > > > > > I have looked through the patches - and nothing jumped at me. > > > A few places could use a newline but not worth a re-spin. > > > > > > I personal dislike filenames like "helpers.c" but thats pure bikeshedding. > > > > > > > One of my goals was to keep things as close to how they are in Linux > > as possible. That's how that file is called there, so you might have > > to take it with Mark Brown if you want to change that. > > > > > Looks good with the simple regulator support, which most likely will prove > > > useful later also for other drivers. > > > I hope we do not need deferred probe much... > > > > > > With deferred probe ported from the kernel, I wonder > > > how far we are from porting the devm_* functionlity too. > > > Not the I think this will share code with deferred probe, > > > just that this is another nice kernel idiom we could > > > benefit from in barebox. > > > > > > > Just to clarify, deferred probe was already a part of Barebox for a > > while, the patches in this series only change the fact that Barebox > > core now has a chance to "give up" on deferred device and declare it > > as non-existent. > > > > As for devm_* functions, not far at all. I don't think it would be > > difficult to port and I've been meaning to do that for a while, just > > never had an opportunity to do it so far. > > There's another idea I'd like to explore before we go deeper into probe > deferral. > > Whenever a framework needs a device probed from some device tree node it > could call a of_ensure_probed(struct device_node *np) function. This > function would then go back into the driver core and probe the device > behind this device node. > > This would require some restructuring of the driver core, like for > example all devices and drivers have to be registered before they are > actually probed. This of course goes against non device tree based > builds which have a hand crafted initcall order to resolve dependencies. > > Maybe this is a crazy idea, but at least I'd like to know why this > doesn't work ;) > I'd rather not spend any more time on this topic. Driver_deferred_probe_check_state() is not a hard requirement and there's a way to make the series work without it. Given the pushback against it, I'll drop it in v3 and adjust the rest of the code. Thanks, Andrey Smirnov _______________________________________________ barebox mailing list barebox@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox
