Re: RFC: Platform data for onboard USB assets

From: Andy Green
Date: Wed Mar 23 2011 - 07:13:58 EST

On 03/23/2011 10:56 AM, Somebody in the thread at some point said:
rules for the default device name that usbnet assigns. Simply letting
a device driver flag "this is always an external ethernet, not
a point-to-point connection" would be enough to solve this problem,
and take some of the heat out of the discussion for how to solve
the MAC address assignment.

Completely agree, I have a happy feeling being able to say that too.
But I already see there's no path through Greg let alone Alan, so it'll
have to be dealt with a less good way.

Having a USB net driver flag the fact it knows from its vid/did that it
is probably P2P rather than net (or vice versa) isn't something I see a
problem with, it's probably quite helpful for various network
autoconfigurator guesses. What we don't want however is the kernel
deciding the naming scheme should change. Name tweaks are really policy,
knowing if an interface vid/did say its P2P or net is merely information
that can guide a policy in user space.

Now if your user space uses that flag to issue ifrenames fine, that's
your choice. It's probably sufficient just to set IFF_POINTOPOINT
appropriately on the net interface flags to make all that work ?

The problem is "[my] user space" in this case is generic Ubuntu basically. It'd be a new thing to that, that it had to understand it woke up on specifically a Panda and do Panda quirks like clear IFF_POINTTOPOINT on a magic interface. From a userland perspective, I would fairly I think term it "stinking it up" with board-specific quirks, so far generic distro userlands are AFAIK able to avoid that whole class of hack. I mean there's nothing in Fedora that snoops /proc/cpuinfo to see what it is running on and then do some special scripts at init AFAIK, that is in fact what you are suggesting unless I badly misunderstand you.

The issue is Panda has smsc95xx USB <-> Ethernet bridge chip soldered on the board wired up to a fixed USB Host port. This is indistinguishable from an smsc95xx you can buy in a pluggable USB / Ethernet dongle, and since there's no MAC address EEPROM on the board it could use, to the point they can report the same vid:pid; but you'd expect the dongle to come as usb%d as udev would already have it perfectly correctly. So vid:pid alone is not a basis for distinguishing what to do here.

That is why I characterize the issue as being one of board-specific physical knowledge that should live in the kernel's board definition file (Arnd would characterize it similarly but involving Device Tree, but the same basic deal). The board definition file knows, not that all device of that vid:pid should choose eth%d not usb%d which is not its business to know, but that the usb device on the specific wired-up USB port to the RJ45 soldered on the board should be guided a particular way when the interface name is registered. That can only be done properly in-kernel by passing in a flag to usbnet specific to the device instance to guide its choice.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at