Re: RFC: Platform data for onboard USB assets
From: Andy Green
Date: Fri Mar 11 2011 - 11:27:12 EST
On 03/11/2011 04:03 PM, Somebody in the thread at some point said:
On Fri, Mar 11, 2011 at 04:54:03PM +0100, Arnd Bergmann wrote:
On Friday 11 March 2011, Mark Brown wrote:
It's arguable if this stuff is broken at all, from a hardware design
point of view it's perfectly reasonable and if you're shipping volumes
in the millions very small savings add up to interesting numbers easily.
It may be reasonable if you don't expect anyone to connect the
device to an ethernet port, but in that case you could save much
more by removing the ethernet chip and the socket along with the
eeprom.
Really, any machine without a fixed MAC address is a huge pain
for users, just google for "pandaboard mac address" to see
how much work this has caused people.
I'm not familiar with the Pandaboard but most of the devices I've worked
with that do this have unique MAC addresses but they store in other
locations on the device (typically in flash).
Like I say, it's not just MAC addresses that can need configuring this
way - it can be other random "you're wired up this way" type
information that would normally be figured out from the USB IDs.
Yes that's exactly why I was thinking it's a class of requirement that
could reasonably be a little API and extending platform_data to it. So
anyone with onboard USB device can take advantage if they need to,
because I guess we see gradually more boards like that.
The driver knows well all about the actual device, but there is a class
of configuration information that is defined by the physical board
itself - as you say "how it is wired" - and needs to be passed into the
driver to inform it of its "functional configuration". When that
functional configuration information is a feature of the board alone,
actually the board definition file is the right place for it.
-Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/