From: Grant Likely <grant.likely@secretlab.ca>
To: David Miller <davem@davemloft.net>
Cc: devicetree-discuss@lists.ozlabs.org, linuxppc-dev@ozlabs.org,
paulus@samba.org, jk@ozlabs.org
Subject: Re: Deprecating of_platform, the path from here...
Date: Thu, 10 Dec 2009 13:47:33 -0700 [thread overview]
Message-ID: <fa686aa40912101247k55d56783ge0163dd1da073b49@mail.gmail.com> (raw)
In-Reply-To: <20091209.162121.256573183.davem@davemloft.net>
Hi David,
On Wed, Dec 9, 2009 at 5:21 PM, David Miller <davem@davemloft.net> wrote:
> From: David Miller <davem@davemloft.net>
> Date: Wed, 09 Dec 2009 16:15:50 -0800 (PST)
>
>> From: Grant Likely <grant.likely@secretlab.ca>
>> Date: Wed, 9 Dec 2009 15:06:29 -0700
>>
>>> 1) of_platform will be deprecated in preference of the platform bus.
>>
>> 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.
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 platform device pdata mechanism requires data structure changes
> and is not dynamically extensible, whereas OF devices are
> fundamentally so.
>
> I don't like the idea to get rid of of_platform devices at all.
There are no plans to actually remove of_platform. I certainly don't
plan to try and force SPARC to switch from of_platform to platform
bus. But on PowerPC (and probably Microblaze) the plan is to move
away from of_platform for all the reasons discussed, and I'm not be
bringing of_platform over as I work on ARM support.
> OF devices are really clean, much like netlink messages, where
> arbitrary named attributes can be added or removed without any data
> structure changes at all.
No argument here.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
next prev parent reply other threads:[~2009-12-10 20:47 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-09 22:06 Deprecating of_platform, the path from here Grant Likely
2009-12-10 0:15 ` David Miller
2009-12-10 0:21 ` David Miller
2009-12-10 20:47 ` Grant Likely [this message]
2009-12-10 21:56 ` David Miller
2009-12-10 22:03 ` Grant Likely
2009-12-11 15:25 ` Arnd Bergmann
2009-12-11 15:53 ` Joakim Tjernlund
2009-12-11 16:44 ` Grant Likely
2009-12-11 21:17 ` Arnd Bergmann
2009-12-11 22:19 ` Benjamin Herrenschmidt
2009-12-10 1:45 ` Benjamin Herrenschmidt
2009-12-10 21:30 ` Benjamin Herrenschmidt
2009-12-10 21:53 ` Grant Likely
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fa686aa40912101247k55d56783ge0163dd1da073b49@mail.gmail.com \
--to=grant.likely@secretlab.ca \
--cc=davem@davemloft.net \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=jk@ozlabs.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=paulus@samba.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).