Re: RFC: Platform data for onboard USB assets

[Andy Green]

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
> > eth%d.

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

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.

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