[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.44L0.1308162117240.24059-100000@netrider.rowland.org>
Date: Fri, 16 Aug 2013 21:29:34 -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 Fri, 16 Aug 2013, Mark Brown wrote:
> > Besides, you need to get the platform information to the driver in any
> > case, no matter how you decide to solve the chicken-and-egg problem.
> > It shouldn't be a factor in deciding which solution to use.
>
> It's not that this is hard, it's that I don't see how if you already
> have some concept of the device in the kernel data structures (which you
> must have in order to be able to provide platform data when it's needed)
> anything is gained by not using that when dealing with bootstrapping
> issues.
I agree. In fact, there's no choice but to use this device concept
during startup. Otherwise there's no way to get the platform data to
the driver when it is needed, because there's no way to tell which
device the data applies to. The question is how elaborate the concept
needs to be and how it gets used.
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.
> Anyway, I think it's time to try to implement something rather than talk
> about it.
Hopefully this discussion has given you some ideas for alternative
approachs, or at least helped to solidify your ideas.
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