Date:	Thu, 15 Aug 2013 20:32:42 +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 01:55:18PM -0400, Alan Stern wrote:
> On Thu, 15 Aug 2013, Mark Brown wrote:
> > On Thu, Aug 15, 2013 at 10:42:00AM -0400, Alan Stern wrote:

> > To be honest I don't see how that helps much if you're going to handle
> > the case where platform data is required to enumerate the device.  You
> > need to know about the device prior to enumeration in order to get the
> > platform data to the driver when it does enumerate and you can't
> > enumerate it until you do that anyway.

> You're a little imprecise here.  Which driver do you mean?  The driver
> that will ultimately bind to the device, or the driver that will
> discover and enumerate it (which generally is bound to the device's
> upstream parent)?  I'll assume the latter.

The driver that's binding to the device - obviously going through
teaching all controller drivers about how to start up any random child
device they might encounter is not going to be a good idea, this should
be encapsulated in the child driver.

> Under what circumstances is platform data required to enumerate a
> device on a discoverable bus?  We're assuming the platform has already
> taken care of everything required to make the device appear on the bus
> in the usual manner (such as bringing it to full power).  Can you give
> an example where something more is needed?

Powering on the device is exactly the sort of thing I'm talking about
here.  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.

> (Were you thinking of the case where the device's IRQ signal doesn't go
> over the bus but uses a different platform mechanism?  I don't quite 
> see how this can work.  What about devices on the bus that aren't known 
> to the platform beforehand?  How do they send their IRQ signals?)

Either the bus doesn't support anything like interrupts at all or they'd
use the standard bus mechanisms.  Typical reasons for bypassing the bus
include things like latency and power, or excessive cost for
implementation on the device side.

> >  A bus could insist on this if it
> > needed the information from enumeration for some reason but really it
> > seems like an implementation detail.

> It isn't an implementation detail.  The "power-up for initial
> detection" scheme is a general solution to the problem of setting up a
> complicated communication path between the bus and the platform.  
> (I.e., it gives a simple way to avoid the need for this communication,
> that can be used on any discoverable bus.)  It also is a general 
> solution for avoiding the problem of registering a device on a bus 
> before that device has been discovered and enumerated.

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.

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

Powered by blists - more mailing lists