Re: RFC: Platform data for onboard USB assets

[Roger Quadros]

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