Message-ID: <Pine.LNX.4.44L0.1511171521000.1680-100000@iolanthe.rowland.org>
Date:	Tue, 17 Nov 2015 15:31:29 -0500 (EST)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Andrzej Hajda <a.hajda@...sung.com>
cc:	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Linux PM list <linux-pm@...r.kernel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Grant Likely <grant.likely@...aro.org>,
	Mark Brown <broonie@...nel.org>, Rob Herring <robh@...nel.org>,
	Tomeu Vizoso <tomeu.vizoso@...labora.com>,
	Thierry Reding <treding@...dia.com>,
	Dmitry Torokhov <dtor@...gle.com>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Michael Turquette <mturquette@...libre.com>
Subject: Re: [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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists