Re: RFC: Platform data for onboard USB assets

[Mark Brown <broonie@opensource.wolfsonmicro.com>]

On Thu, Mar 17, 2011 at 02:31:08PM -0700, Greg KH wrote:
> On Thu, Mar 17, 2011 at 09:24:49PM +0000, Mark Brown wrote:

> > The way this is normally done is that the ethernet controller can be
> > attached to a SEPROM which it reads when it powers on.  This will
> > contain a number of device configuration parameters, including the
> > vendor IDs and the MAC address, which will be configured before the
> > device makes itself available on the bus.  If the system integrator has
> > omitted the SEPROM then the device will come up with defaults, usually
> > something like all zeros.

> Ok, then again, let's deal with this on a case-by-case basis please, as
> this is going to be a "rare" thing in the real world.  I don't want to
> encourage _any_ engineers to think that this is ok to do for USB
> devices.

It's really not at all rare in the embedded world - the overwhelming
majority of the systems I've worked on have omitted the SEPROMS for
components that are soldered down in the system.  It'd be pretty insane
to do it for things that are distinct USB devices but that's not the
case.

There are good solid engineering reasons for doing things this way if
you've got any prospect of shifting any kind of volume, as well as the
cost saving achieved by removing a component you also simplify and most
likely speed up the production process as you can reduce the number of
components that need to be programmed on each system that gets built.

> Patches to fix this, for this specific PandaBoard controller are gladly
> accepted.  What's odd is this is explicitly a Linux development board,
> so you would think that this could have been caught, and fixed, in the
> hardware a long time ago, right?

The way everyone resolves this stuff is by patching their kernel
locally.