Messages in this thread | | | Date | Tue, 25 Jun 2019 21:30:52 -0700 | From | Sandeep Patil <> | Subject | Re: [RESEND PATCH v1 0/5] Solve postboot supplier cleanup and optimize probe ordering |
| |
On Tue, Jun 25, 2019 at 11:53:13AM +0800, Greg Kroah-Hartman wrote: > On Mon, Jun 24, 2019 at 03:37:07PM -0700, Sandeep Patil wrote: > > We are trying to make sure that all (most) drivers in an Aarch64 system can > > be kernel modules for Android, like any other desktop system for > > example. There are a number of problems we need to fix before that happens > > ofcourse. > > I will argue that this is NOT an android-specific issue. If the goal of > creating an arm64 kernel that will "just work" for a wide range of > hardware configurations without rebuilding is going to happen, we need > to solve this problem with DT. This goal was one of the original wishes > of the arm64 development effort, let's not loose sight of it as > obviously, this is not working properly just yet.
I believe the proposed solution in this patch series is just that. I am not sure what the alternatives are. The alternative suggested was to reuse pre-existing dt-bindings for dependency based probe re-ordering and resolution.
However, it seems we had no way to *really* check if these dependencies are the real. So, a device may or may not actually depend on the other device for probe / initialization when the dependency is mentioned in it's dt node. From DT's point of view, there is no way to tell this ..
I don't know how this is handled in x86. With DT, I don't see how we can do this unless DT dependencies are _really_ tied with runtime dependencies (The cycles would have been apparent if that was the case.
Honestly, the "depends-on" property suggested here just piles on to the existing state. So, it is somewhat doubling the exiting bindings. It says, you must use depends-on property to define probe / initialization dependency. The existing bindings like 'clock', 'interrupt', '*-supply' do not enforce that right now, so you will have device nodes that have these bindings right now but don't necessarily need them for successful probe for example.
> > It just seems that Android is the first one to actually try and > implement that goal :)
I guess :)
- ssp
> > thanks, > > greg k-h
| |