[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.44L0.1308141023150.1701-100000@iolanthe.rowland.org>
Date: Wed, 14 Aug 2013 10:27:26 -0400 (EDT)
From: Alan Stern <stern@...land.harvard.edu>
To: Mark Brown <broonie@...nel.org>
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, 14 Aug 2013, Mark Brown wrote:
> On Mon, Aug 12, 2013 at 09:04:00PM -0400, Alan Stern wrote:
>
> > The bus code would need hooks installed wherever the platform wants to
> > do something extra. This could end up growing to a lot of hooks. How
> > can the whole thing be done in a reasonable fashion?
>
> 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?
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?
Perhaps the platform-level code would need to hook into the places
where the discoverable bus is registered and unregistered.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists