Re: RFC: Platform data for onboard USB assets

From: Greg KH
Date: Thu Mar 17 2011 - 17:33:10 EST


On Thu, Mar 17, 2011 at 09:24:49PM +0000, Mark Brown wrote:
> On Thu, Mar 17, 2011 at 01:26:14PM -0700, Greg KH wrote:
> > On Thu, Mar 17, 2011 at 08:18:35PM +0000, Mark Brown wrote:
>
> > > It's going to be an off the shelf USB ethernet controller. I'd be
> > > astonished if the board-configurable device IDs weren't set from the
> > > same SEPROM that the MAC address is so it'd just show up as a generic
> > > chip of whatever kind.
>
> > Huh? All USB controllers you buy have the ability to set the vendor and
> > product id, so you should always be able to key off of that.
>
> > Isn't that the case here?
>
> They generally the same facility that includes the ability to set the
> MAC address so if one's not been provided it seems optimistic to expect
> the other.

{sigh} You are probably right :(

> 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.

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?

Heck, it could be fixed today on future versions of this board, if
anyone from TI actually cared :(

thanks,

greg k-h
--
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/