Re: [PATCH v2 00/18] PCIe support for i.MX7

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 ;)

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/barebox



[Index of Archives]     [Linux Embedded]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux