[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130819160130.GD30073@sirena.org.uk>
Date: Mon, 19 Aug 2013 17:01:30 +0100
From: Mark Brown <broonie@...nel.org>
To: Ming Lei <tom.leiming@...il.com>
Cc: Alan Stern <stern@...land.harvard.edu>,
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" <devicetree@...r.kernel.org>,
linux-usb <linux-usb@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Non-enumerable devices on USB and other enumerable buses
On Mon, Aug 19, 2013 at 08:17:53PM +0800, Ming Lei wrote:
> On Sat, Aug 17, 2013 at 9:29 AM, Alan Stern <stern@...land.harvard.edu> wrote:
> > Aong those lines, I would like to point out that the device concept
> > embodied in the kernel's data structures can be pretty thin. For
> > example, it might be little more than a port number or bus address.
> Maybe the principle behind drivers/usb/core/usb-acpi.c is helpful
> for the problem, and DT may refer to ACPI to describe on-board
> USB devices, and the way to retrieve platform data too.
I can't parse this at all well - why would DT want to refer to ACPI, do
you mean people may wish to look at the code as an example? As Grant
noted DT already has some mechanisms for enumerable buses which looking
at the code appears to be broadly what that's doing.
Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)
Powered by blists - more mailing lists