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:
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 http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/