Message-ID: <20130815225427.GA18597@sirena.org.uk>
Date:	Thu, 15 Aug 2013 23:54:27 +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 Thu, Aug 15, 2013 at 04:42:01PM -0400, Alan Stern wrote:

> Okay.  Here's a restatement of what you wrote above:

> 	In the case where platform data is required to enumerate the
> 	device, you need to know about the device prior to enumeration.

> Obviously true.

> 	You need to get the platform data to the driver when it does
> 	enumerate.

> Not necessarily; see below.

I think this is pretty essential - there is no point in having platform
data if you can't pass it to the device.  It needs to make it to the
driver at the very least by the time the probe function runs.

> > Powering on the device is exactly the sort of thing I'm talking about
> > here.

> So something needs to power-on the device.  But what?  The driver that
> enumerates it, or some other part of the kernel?

> If some other part of the kernel takes care of this then you _don't_
> have to get the platform data to the driver when it enumerates.

Right, but my contention would be that if it's not the driver for the
device that is being instantiated it's probably not going to be
anything scalable since that's where we generally put our knowledge of a
given bit of silicon.

> >  I'm not sure what you think "the platform" is here but it sounds
> > awfully like the sort of random board specific bodge code that people
> > currently use - something has got to know what's needed to get the
> > device up and running and how to do it and the device driver seems like
> > the sensible place to do that.

> Just the reverse.  The driver should deal with things it knows about:  
> how to discover and enumerate devices on its bus.  It should not

For a bus controller of course, they should be totally out of this.

> contain anything platform-specific.  Adding this in would be a
> logistical nightmare -- you'd have to stuff power-on procedures for all
> sorts of different platforms into this one poor driver!

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.

> > I think I completely misunderstood what you mean by powering up on
> > initial use.  If you're saying that we should have some platform code
> > for doing this I don't think that's a scalable solution.

> How can it be avoided?  The powering-up operation is platform-specific.  
> By definition, whatever code carries out the operation is platform
> code.

Like I say device power management isn't system specific, it's silicon
specific - think of what's in the driver as being the power up sequence
from the datasheet.

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

Powered by blists - more mailing lists