Date:	Thu, 15 Aug 2013 00:55:19 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Rob Herring <rob.herring@...xeda.com>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Stephen Warren <swarren@...dotorg.org>,
	Ian Campbell <ian.campbell@...rix.com>,
	Felipe Balbi <balbi@...com>,
	Grant Likely <grant.likely@...aro.org>,
	devicetree@...r.kernel.org, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: Non-enumerable devices on USB and other enumerable buses

On Wed, Aug 14, 2013 at 03:39:20PM -0400, Alan Stern wrote:

> I don't see the point of all this.  Obviously the device can't be used
> until it physically appears on the bus.  What benefit do you get from
> registering it and making it available to userspace before that?

Two things.  One is that some devices have the ability to perform useful
functions when powered down sufficiently that they can't run a complex
bus, providing notification when they need to wake up (or being woken up
if the power on comes from userspace).  The other is that then userspace
can just see the device and start using it when it needs it without
having to have a mechanism to discover that there's something there with
manual power control.

This can also be an issue in cases where we compose multiple physical
devices into composite ones for userspace (embedded audio and video do
this a lot for example).  A given bit of hardware may only be useful in
some circumstances.

> Well, basic "power this on" stuff is pretty much all we have discussed 
> in this thread so far.  What other sorts of things are going to be 
> needed for a general solution?

If you look elsewhere at the stuff I've been saying about Slimbus that's
the nastiest case I'm aware of in terms of the bus itself - that's got
the devices with low power modes that do useful things with the device
(and bus) mostly powered off and things like that.  Things like activity
detection of various kinds where the device is monitoring for activity
in a low power state.

I've also mentioned the devices that need platform data which is a part
of this too; one reason for knowing that the device is there before it
appears is so that we can pass platform data/DT/whatever to it.

> Now I'm getting confused.  It seems we're talking about at least three
> very different things here:

>      A: Devising a mechanism for platform code to do things involving
> 	devices that are dynamically registered on discoverable buses.

If we need random platform code then we're failing, half the point of
things like DT and ACPI is to avoid writing random board code.  we do
want to pass data to devices for their drivers to use but having to have
random bits of per board code would be really sad.

>      B: Telling the subsystem and driver code for a discoverable bus
> 	that a particular device is present before it has been 
> 	detected.

>      C: Implementing a mechanism whereby drivers can take a device
> 	off-line while still pretending to userspace that the device
> 	is still present, by bringing it back on-line as needed.

> I don't see much connection between these things.  Perhaps you can
> explain in more detail.

I think the solutions for these overlap so much they're the same thing.
The situation we're in in in your case B is just the idle case for
condition C - if we know about the device before it's been detected then
if it's been removed we just go back into the situation where we know
about it but it isn't powered.

> (BTW, it's worth mentioning that C has already been done, in the form
> of runtime PM.  The difference may be that you propose to take the
> device so far off-line that it disappears from the bus.  AFAICS, this
> would be purely a private matter to be arranged between the subsystem
> and the driver; it does not need to be handled at the level of the
> device-model or PM core.)

Actually runtime PM is actually already used for completely offlining
devices on buses that are too blind to notice - it's only an issue on
buses that can notice insertion and removal and want to do something
about it.  The use cases I'm describing already happen in mainline today
for devices on the dumber buses.

I think if we've got something which the hardware engineers can do on
multiple buses then they probably will so we should have at least a
pattern for how it's going to work over multiple buses rather than
having to handle different models for different buses.  I'll try to have
a think about what that pattern might be at some point (in my copious
free time).

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)

Powered by blists - more mailing lists