lkml.org 
[lkml]   [2015]   [Nov]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFD] Functional dependencies between devices
On Tue, 17 Nov 2015, Andrzej Hajda wrote:

> > and I'd like the driver core to track them and act on them in certain cases
> > where they matter. The argument for doing that in the driver core is that
> > there are quite a few distinct use cases related to that, they are relatively
> > hard to get right in a driver (if one wants to address all of them properly)
> > and it only gets worse if multiplied by the number of drivers potentially
> > needing to do it. Morever, at least one case (asynchronous system suspend/resume)
> > cannot be handled in a single driver at all, because it requires the driver of A
> > to wait for B to suspend (during system suspend) and the driver of B to wait for
> > A to resume (during system resume).
>
> Could you elaborate these distinct use cases. I am curious because I have
> proposed resource tracking framework [1] which should solve most of the issues
> described here. It was not designed to solve suspend/resume issues, but it could
> be easily extended to support it, I suppose.
>
> [1]: https://lkml.org/lkml/2014/12/10/342

The dependencies Rafael has in mind include the following (and
undoubtedly include more):

The consumer device requires some resource from a provider
device before it can be probed. Resources can be clocks,
phys, gpios, and so on.

The consumer device can't be at full power unless a provider
device is also at full power.

> Regarding fundamental things, maybe it is just my impression but parsing private
> DT device nodes by kernel core assumes that convention about using resource
> specifiers in DT is a strict rule, it should not be true.
>
> As I wrote before I have send some early RFC with framework which solves most of
> the problems described here[1], the missing part is suspend/resume support which
> should be quite easy to add, I suspect. Moreover it solves problem of device
> driver hot bind/unbind.
> Could you take a look at it, I will be glad to know it is worth to continue work
> on it?

It looks like the major difference is that you propose to use callbacks
or notifications to do a lot of the work. For example, a driver
probing a device could register a bunch of dependencies on various
resources, and a callback would be invoked when all those dependencies
were satisfied, at which point the probe procedure could complete. No
need for deferrals.

It's an interesting idea. I'm not sure how well it applies to power
dependencies, though.

Also, there's a real problem that needs to be solved concerning how
resources are identified in the absence of DT (or ACPI or something
similar).

Alan Stern



\
 
 \ /
  Last update: 2015-11-17 21:41    [W:0.499 / U:0.132 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site