Re: RFC: Platform data for onboard USB assets

From: Andy Green
Date: Tue Mar 22 2011 - 15:36:08 EST

On 03/22/2011 06:59 PM, Somebody in the thread at some point said:
On 23 March 2011 00:07, Andy Green<andy@xxxxxxxxxxx> wrote:
On 03/22/2011 06:19 PM, Somebody in the thread at some point said:

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.
Yes I know it's not a very elegant solution.
But we must remember, we are catering to users that lose sleep over
not having to call 'fixed RJ-45 port over USB' as eth0 :)

The characteristics of a kernel and userland solution are not the same though.

If we fix it via the kernel's definitive understanding of what board it is on, then I can put an, eg, fedora rootfs on it which doesn't have hwpack concept, and I get the same result. The usb / eth thing is indeed cosmetic and trivial in one sense but in another it is a valid example IMO where it's the kernel's job to abstract the details of the actual board out properly so userland does not ever have to know.

I was not just talking about mmc -> sdio change. Rather the bus/port numbering.
Say, mmc1:0001:2 becomes mmc7:0201:1 by some new addressing scheme.
I agree the fix is as easy as it is to break old devpath assumption in
this case.

OK so you and I at least agree that there is no reasonable "future proofing" issue here.

And yes, bus numbering also depends on things like modprobe order, which may not
be fixed for all platforms. Any change there too can break the devpath
association.

Well it has been a big thread, but I made it clear already this async platform data stuff is only usable where the bus drivers and bus host instantiation are built-ins done in the machine definition file. They're the prerequisites for the determinism that is required, and it's the common SoC case that it is already so.

The actual device drivers themselves, like wl12xx, can be in modules though just fine, what is targeted is its path on a specified bus and that is set by the bus driver. Whenever that logical device matching that path does get instantiated, it gets tagged and that is working for wl12xx case with the actual device driver in modules.

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