Re: RFC: Platform data for onboard USB assets

Andy Green
2011-03-23T11:13:54Z

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.

-Andy