[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130814153906.GU6427@sirena.org.uk>
Date: Wed, 14 Aug 2013 16:39:06 +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 10:27:26AM -0400, Alan Stern wrote:
> On Wed, 14 Aug 2013, Mark Brown wrote:
> > I'd expect that we're just looking at hooks around connection and
> > disconnection here here - if we're looking at much more it seems like we
> > must be doing something wrong.
> Connection and disconnection of what?
The device on the bus.
> In the example mentioned earlier, the GPIOs to power an on-board USB
> hub would have to be initialized when the host controller was started.
> You wouldn't want to wait for the on-board hub to be detected, because
> without those GPIOs set properly, it never would be discovered on the
> USB bus. Right?
Yes, so you'd want callbacks when the device actually appears and
disappears.
> Perhaps the platform-level code would need to hook into the places
> where the discoverable bus is registered and unregistered.
We'd need some way to get information to the drivers still, and to
handle drivers that want to stop and start things.
Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)
Powered by blists - more mailing lists