lkml.org 
[lkml]   [2011]   [Mar]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: RFC: Platform data for onboard USB assets
Hi,

On 03/11/2011 02:44 PM, ext Andy Green wrote:

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

I fail to see the problem. USB is a dynamically probed bus.
Whether the USB peripheral is hard-wired to the board or not, it is
still dynamically probed. The board files are not expected to know
anything about USB peripherals prior to enumeration, so platform data
does not make sense for USB.

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

Platform data makes perfect sense for I2C because it is not a
dynamically probed bus and board writers need to define which I2C chips
are present on the board.

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

What do you want to set in platform data? the ethernet device name?
Isn't that better done in user space using udev rules?

--
regards,
-roger


\
 
 \ /
  Last update: 2011-03-11 15:45    [W:0.614 / U:0.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site