Re: RFC: Platform data for onboard USB assets

Jaswinder Singh
2011-03-22T18:19:53Z

On 22 March 2011 21:34, Andy Green <andy@warmcat.com> wrote:
> On 03/22/2011 03:05 PM, Somebody in the thread at some point said:
>
> Hi -
>
>>  Personally, I wouldn't have bothered thinking about some kernel-wide
>> solution to the Panda SMSC9514 issue. I think defining Panda specific
>>  udev rules to 'rename the SMSC9614 on USB1(?) to ETH0' is sufficient and
>> legal to do. Bus enumeration algos change neither often nor enough.
>> I believe there would be far riskier assumptions in filesystems already.
>
> Not sure you got all the points there.  The interface index is not targeted
> at all, it's the interface class.  That is why I only talk about usb%d vs
> eth%d.
>
> If you think about what userland has to do to correct that, it involves
> userland understanding that it is running on specifically a Panda board or
> other boards that need mangling, and it is looking at the device that is
> specifically the onboard one.  (You cannot do it from VID/PID because that
> same VID/PID can turn up in a second pluggable adapter case -- still an
> smsc95xx you see -- where you really would want it called usb%d.)  This is
> why elsewhere I refer to this as a "userland board quirk database" being
> needed to solve it in userland.  If it was simpler, sure, I wouldn't bother
> looking to guide the driver's choice in kernel because you can as pointed
> out meddle them from userland.  But if you look into what has to be done in
> Userland it's nothing like a normal udev handler based only on vid/pid.
>  Userland is actually super allergic to knowing directly what it is running
> on and making decisions based on that, for good reasons, and desperately
> wants to be generic leaving all board quirks for the kernel to hide.  And
> the machine definition file is designed to understand board-specific
> information.

I thought I understood. You want the RJ-45 port of _Panda_ be
called ethN(say eth0) rather than usbN, while other USB-Ethernet adaptors,
if any and SMSC9514, connected to the USB downstream ports of
LAN9514 be named usbN.

If yes, isn't that possible by specifying a _Panda_ specific udev rule
to find and rename a network interface based only on its type and
devpath without needing its MAC address? Greg ?
The udev rule could be a part of some hwpack.

>>    Though it is illegal for a NIC to not have MAC address, no spec demands
>> the
>>  MAC be on some EEPROM or like. Theoretically, the NIC vendor could
>> hand me a NIC
>> and a note with it's unique MAC address scribbled :)
>>  As Mark already noted, savings pile if we could save eeproms when a
>> device is
>> expected to ship in tens of thousands.
>>  IIANM, Greg acknowledged passing MAC via board specific data
>> structure(albeit via DT)
>> It's a different matter that DT has many hearts to win(at least in ARM
>> Linux)
>> So, perhaps the answer to Q(a) is - Yes.
>>
>> (b) IMHO, though stable enough, the most obvious method of 'devpath
>> association'
>>  is indeed not future-proof.
>
> What're you thinking it's not future-proof against?

Even if the rootfilesystem remains the same, the devpath association will
fail if, say, Linux USB core decides to number usb busses in reverse order as
a part of some code restructuring.
After all the USB spec doesn't say about the bus/port ordering.

Thanks.