Re: RFC: Platform data for onboard USB assets

[Arnd Bergmann <arnd@arndb.de>]

On Wednesday 23 March 2011, Greg KH wrote:
> On Wed, Mar 23, 2011 at 11:32:02AM +0100, Arnd Bergmann wrote:
> > On Wednesday 23 March 2011, Andy Green wrote:
> > > It's the case for even usbnet, which is using a broken heuristic to 
> > > decide what to call the interface not even based on vid / pid.
> > 
> > I agree that the heuristics in usbnet is less than helpful here,
> > which among other things leads people to mixing up the two problems
> > of fixing the device naming and fixing the MAC address assignment.
> > 
> > Even though I know Greg disagrees, I'd still prefer sanitising the
> > rules for the default device name that usbnet assigns.
> 
> I'm all for that, but recall, we can't because of previous
> implementations and past history.  I.e. you will break working systems
> if you do this.  So we are stuck with what we have at the moment, sorry.

I would still consider it a bug fix and argue that the number of actual
people impacted by the current behaviour is much larger than the potential
number people that might suffer from changing the behavior in an incompatible
way, given that:

* The common case for this hardware seems to be to ship with an eeprom
  with a valid mac address, as identified by the fact that f4e8ab7c
  "smsc95xx: generate random MAC address once, not every ifup" only recently
  got into the kernel as a bug fix for the random case, though the driver
  has been around since 2008.

* A google search on the term "smsc95xx" find almost exclusively discussions
  about how to get the device to come up with a proper name on the panda
  board, and various proposed workarounds.

* The comment in usbnet.c about this suggests that the intent has always
  been what is proposed now, it just doesn't match the code:

           // heuristic:  "usb%d" for links we know are two-host,
           // else "eth%d" when there's reasonable doubt.  userspace
           // can rename the link if it knows better.
                if ((dev->driver_info->flags & FLAG_ETHER) != 0 &&
                    (net->dev_addr [0] & 0x02) == 0)
                        strcpy (net->name, "eth%d");

  In case of smsc95xx, we *know* that it's ethernet and not two-host,
  there is no reasonable doubt about this. The code almost makes sense
  on generic cdc devices, but not for anything else.

	Arnd