Re: RFC: Platform data for onboard USB assets

[Andy Green]

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