Re: RFC: Platform data for onboard USB assets
From: Jaswinder Singh
Date: Tue Mar 22 2011 - 14:19:57 EST
On 22 March 2011 21:34, Andy Green <andy@xxxxxxxxxxx> 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
> 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
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
>> 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
>> So, perhaps the answer to Q(a) is - Yes.
>> (b) IMHO, though stable enough, the most obvious method of 'devpath
>> 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.
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/