Re: Non-enumerable devices on USB and other enumerable buses

[Alan Stern]

On Thu, 15 Aug 2013, Mark Brown wrote:

> No, this really is something that's very much generic to the device and
> will apply to anywhere the silicon is used.  The power on process for a
> device isn't something that changes, the mapping of resources that might
> be used in that sequence is but we've got good abstractions for pretty
> much all the resources that a device might need - clocks, power, GPIOs
> and so on - which do the mapping of those resources onto the device at
> board level so neither the provider not the user need to know about it.
> That's just data and is much easier to encode in DT or equivalent than
> actual sequences.
> 
> We've got a bunch of existing drivers in the kernel which do this sort
> of stuff, they ask for resources and then know what to do with them and
> can also make use of these resources at runtime if they want.

Okay, let's see if I understand your problem.  You've got a driver that
knows how to manage its devices, including how to power them on and
off.  But the driver can't bind to one of these devices until the
device has appeared on the bus and been enumerated, and that won't
happen until the device has been powered on.  It's a chicken-and-egg
sort of thing.

You know about the existence of these devices beforehand because that
knowledge is encapsulated in platform information somewhere.  The
question is how best to use this information to solve the
chicken-and-egg problem.

Is that it?

One possible answer is to use the platform information to (partially)  
instantiate the device before it has been detected, so that the driver
can bind to it.  Another is to use the platform information to perform
an initial power-up of the device, so that it can be detected,
enumerated, and probed in the normal manner.

The difficulty with the first proposal is that subsystems aren't
designed to allow that sort of thing.  They expect to be able to
communicate with the devices they manage, during enumeration and
probing at least.  The difficulty with the second proposal is that it
requires duplicating the power-on code.

My feeling is that the second answer involves less work and less
complexity than the first.  Both proposals require additional
"run-once" code (to do the partial instantiations or the initial
power-ons), but the first proposal also requires the subsystem's 
detection and enumeration routines to be adjusted so that they can work 
even when the device is incommunicado.

(The second proposal also has the advantage that the power-on code may 
be shared between the driver and the subsystem.)

Alan Stern

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