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
