Re: RFC: Platform data for onboard USB assets

Andy Green
2011-03-22T16:04:28Z

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

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

In any event, the thread established that particular problem is unlikely
to get solved in the mainline kernel. So other than correct any
misconception, there's no point going further into it as it stands.

> But I do agree it is nice to have system wide solutions whenever due.
> Like this attempted patchset. Which is based upon two questions :-
>
> Q(a) Can discoverable buses(USB, SDIO etc) legally need platform_data
> or similar?
>
> Q(b) If yes, what 'key' is most suitable for identifying the right device
> to attach the data to ?
>
> (a) We already have a good example, of Panda's missing MAC. I am sure there
> would be more to think of.

Having done the SDIO async platform_data support now, it turns out SDIO
WLAN modules really do need platform_data already and at least in the
(mainline) wl12xx case, go to some lengths to work around not having an
api to deliver it.

> Though it is illegal for a NIC to not have MAC address, no spec demands the
> 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 Linux)
> So, perhaps the answer to Q(a) is - Yes.
>
> (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? As a
path-structured string, it seems it should be ideal considering the same
path elements are used in, eg, sysfs as string elements to describe
device paths. Since the strings are in the same tree as the things that
generate them, it only means updating the strings if the generator for
them changes.

> Having parent pointers to compare sounds like a bit too intrusive.
> People might want to suggest?

I spoke for half an hour with Grant Likely yesterday and showed him my
patchset that now covers SDIO async platform_data and wl12xx WLAN
particularly as found on Panda. He asked for a couple of days to see if
he could figure any different approach -- he made a point of saying non
Device-Tree interestingly -- that he liked better. I am not sure that
he will find anything he likes better since after discussing it with
him, his objection is platform_data itself, and that's what stuff like
these WLAN modules on SDIO are already set up for. Anyway I will study
any suggestion.

What I saw from wl12xx though is there are already mainline drivers that
can benefit from just delivering their existing platform_data via async
platform_data api. So I plan to wait for Grant's comments and release a
new RFC patchset in the coming days.

-Andy