Re: RFC: Platform data for onboard USB assets

From: Andy Green
Date: Tue Mar 22 2011 - 14:37:27 EST

On 03/22/2011 06:19 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

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.

That's right, your talk of usb1 eth0 made it sound like it had gotten mixed up with interface numbering business again. I guess you did have the point then.

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.

We are in a privileged position to suggest to stick all kinds in our distro support that's specific to the target, and maintain it. However just doing that relies on the current situation that people are cooking rootfs-es that only work on one target. With the move to multi-target single kernel images, and the corresponding multi-target bootloader support along the same lines that's coming, it'll eventually be possible to provide single SD images that run on many targets with common rootfs. Adding more static hacks into hwpacks on the assumption it is "a panda rootfs" goes in the wrong direction for that.

If it was solved with a flag ultimately in the board definition file of the kernel, however that manifests itself eventually to do the actual job, because that should be the single place all board-specific knowledge is coming from as it stands, it'll just work on all distros without contaminating them with our userland quirk database (be it held in hwpacks or the initscripts).

(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.

No that won't hurt anything since, as I said, the static paths are in the same tree, and can be updated to the new -- equally deterministic -- name at the same time as people start numbering their buses backwards. For example, the Panda SDIO module WLAN function is at path "mmc1:0001:2", if a patchset comes and decides to call these guys sdio0 on that bus instead it just has to grep the board definition files for mmc.\: and fix those up to the appropriate sdioN convention at the same time and everything is cool.

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