Deprecating of_platform, the path from here...

Joakim Tjernlund joakim.tjernlund at transmode.se
Sat Dec 12 02:53:38 EST 2009


>
> On Thursday 10 December 2009, Grant Likely wrote:
> > On Wed, Dec 9, 2009 at 5:21 PM, David Miller <davem at davemloft.net> wrote:
> > > From: David Miller <davem at davemloft.net>
> > > Date: Wed, 09 Dec 2009 16:15:50 -0800 (PST)
> > >> What a shame, it's one of the cleanest driver probing models
> > >> in the tree.
> > >
> > > And BTW, have you folks who "decided" this considered at all the fact
> > > that it is much easier to describe represent platform devices using
> > > of OF devices rather than the other way around?
> >
> > Yup.  I also think of_platform is a cleaner implementation than
> > platform, but the fact remains that there are far more platform
> > drivers than there are of_platform.  So, as nice as of_platform is, it
> > still does pretty much exactly the same job as platform.  I'd rather
> > see of_platform features migrated to platform than creating drivers
> > with dual registrations to be used on both OF and non-OF platforms.
>
> As far as I can tell, there is another path to allow unifying the drivers
> that currently need to register to both platform_bus and of_bus, without
> destroying the features we currently have in those two.
>
> > Trying to go the other way around (deprecate platform and encouraging
> > of_platform instead) I don't think will gain much traction; whereas I
> > think bringing of_platform features into platform will be an easier
> > sell.  I'm trying to be pragmatic here.
>
> The key to the solution IMHO is the ability to create an of_platform_device
> in a hardcoded way without data from a device tree, like we create a
> platform_device today. All these static of_devices would then be rooted
> in /sys/platform by default, while those that come from a device tree are
> in the hierarchy defined there.

Yes, please. I don't like the direction some drivers are heading, namely OF only.
I always tried to view OF as an layer on top of generic methods. If
you look at spi_mpc83xx.c, it is actually less capable today since
platform has been declared legacy.

    Jocke



More information about the Linuxppc-dev mailing list