Re: [RFC PATCH 1/4] PLATFORM: introduce structure to bind async platformdata to a dev path name

[Andy Green]

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

> > Okay.  This is not a PC we are talking about.
> >
> > If the platform / board definition file is registering the USB hosts
> > synchronously at boot time, the driver is composed into the monolithic
> > kernel, there are no PCI busses or whatever on the SoC, the bus indexing
> > is totally deterministic.  This is extremely common in the platform /
> > SoC case and is the case the patchset is targeted at.  Even further, the
> > only time you'd use it is to reach a USB asset that is wired up the same
> > board permanently as well.
> >
> > Anyway this seems moot by now.
>
> However, if you add a new infrastructure like this, it should be at least
> usable on systems that you description doesn't apply to.

Sounds reasonable, except the platform data is coming from a 
board-specific board definition file at boot-time to talk about assets 
that are on fixed interfaces of a specific board.  It's not really 
applicable to wider generic bus use, just like platform_data usually 
isn't and has to be targeted at "device at XYZ on I2C bus n" with 
knowledge of what driver is bound to that device.  Despite that 
"impedence mismatch", it covers the SoC onboard USB asset case just fine 
as it is.

If you mean though, that the patch series implements new configuration 
options in usbnet that are anyway interesting to expose for the general 
case, I can see the point but don't know enough about udev / usb 
subsystem internals to suggest a way to expose the options nicely.

It's also commented the "right" thing to do is to have the driver set 
the device up to wrong defaults like inappropriate interface name / 
random MAC and have userland clean up the mess, rather than have the 
board file ask the driver to set things appropriately.

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