Re: RFC: Platform data for onboard USB assets

Andy Green
2011-03-11T12:44:16Z

On 03/11/2011 12:31 PM, Somebody in the thread at some point said:

Hi -

>> platform_data is a well established way in Linux to pass configuration
>> data up to on-board assets from a machine file like mach-xyz.c. It's
>> also supported to pass platform_data up to devices that are probed
>> asynchronously from busses like i2c as well, which is very handy.
>>
>> However AFAIK it's not possible to bind platform_data to probed USB
>> devices as it stands.
>>
>> There are now boards which have on-board USB assets, for example OMAP4
>> Panda which has a USB<-> Ethernet bridge wired up permanently. It'd be
>> convenient to also be able to pass optional platform_data to these
>> devices when they are asynchronously probed.
>
> Sorry, but I think it's a bad idea to use platform data for this.
> USB is a bus that we can reasonably probe, while we use platform_data
> only for stuff that we can by definition not probe at all.

...

> One relatively easy solution would be to allow passing a MAC address
> to this particular device driver as a module parameter, and generating
> a fixed MAC address in the regular vendor space when installing the
> boot loader. That would also solve the problem that a DHCP server
> currently assigns a new IP address to a panda board at every boot.

I suggested this myself on #15 of the bug you linked to. However, it
seems to me there is a generic issue here and it is not to do with
whether stuff can be discovered on the bus or not; bugging the usbnet
guys to accept devname-based commandline params and solving it for
usbnet only would be covering up the actual issue.

The I2C implementation does not limit itself to providing I2C addresses
and binding to driver names so it can be probed, it also provides for
sending platform_data into the device when it is instantiated. That is
very useful and I don't think the I2C guys will be accepting patches to
remove that capability.

There is no reason I can see that onboard USB assets should continue to
be treated differently to miss out on the same capability because they
are USB and not I2C, particularly as a permanently NULL platform_data
pointer is already sitting there in the usb_device's .dev already
exactly for this use.

-Andy