Re: RFC: Platform data for onboard USB assets

Nicolas Pitre
2011-03-23T15:11:34Z

On Wed, 23 Mar 2011, Benjamin Herrenschmidt wrote:

> Among ideas that have been proposed have been the idea of having stubs
> generating pseudo-device nodes from platform_data for devices in order
> to enable the drivers to use a single interface for example. That didn't
> really go through tho. However, whatever the final approach will be, the
> point remains that for drivers that have not so far been "contaminated"
> by the platform_data paradigm, we have the opportunity to try something
> better, which can then, maybe, be retro-fitted on a case by case basis
> to platform drivers, for example as such drivers get converted to also
> be capable of using the device-tree.
>
> This is where I'm trying to propose a middle ground with the idea of
> named properties. It goes toward the direction that platform_device has
> been trying to to with the struct resource, but there's only so much you
> can do with these and they are showing their limits when it comes to
> expose arbitrary informations. MAC addresses are an example but there
> are many more, from clock bindings, power control, PHY data, connector
> informations, yadadada... which all can potentially apply to on-board
> USB or PCI based devices.

I think your middle ground proposal is more than that. Conceptually, it
positions DT as one of the possible device configuration backends
instead of making DT the sanctioned configuration frontend. To me this
is very important as I don't want to be stuck with DT support where it
would simply be an unwanted burden and overhead. By having this generic
abstraction in the middle, it is then possible to decouple DT from the
actual drivers, and then use DT because it makes sense and not just
because there is no way around it. And who knows when some other non-DT
configuration scheme may appear in the industry where the simple
addition of another backend would make things more straight forward than
having to construct synthetic FTDs on the fly.

Nicolas