From: Grant Likely <grant.likely@secretlab.ca>
To: avorontsov@ru.mvista.com
Cc: linux-kernel@vger.kernel.org, michal.simek@petalogix.com,
microblaze-uclinux@itee.uq.edu.au, sparclinux@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, davem@davemloft.net
Subject: Re: [V2 PATCH 08/10] arch/powerpc: Remove obsolete dev_archdata.of_node and of_devce.node
Date: Thu, 18 Mar 2010 10:22:14 -0600 [thread overview]
Message-ID: <fa686aa41003180922g3e867bedo337568c3ca6f2097@mail.gmail.com> (raw)
In-Reply-To: <20100318154747.GA7767@oksana.dev.rtsoft.ru>
On Thu, Mar 18, 2010 at 9:47 AM, Anton Vorontsov
<avorontsov@ru.mvista.com> wrote:
> Hi Grant,
>
> On Thu, Mar 18, 2010 at 09:22:50AM -0600, Grant Likely wrote:
>> Both dev_archdata.of_node and of_device.node are duplications of the
>> device.of_node value. =A0This patch removes them.
>
> Yeah, they're plain duplications since you introduced dev.of_node.
> I wonder what was the problem with using dev.archdata.of_node?
> Why dev.of_node is better?
CONFIG_OF support is not going to be an arch-specific thing any
longer. The code is being generalized, and I'm removing as many
things as possible that arch code needs to add to enable CONFIG_OF.
That includes the dev_archdata element.
The impact of moving of_node from dev_archdata to device is pretty
small anyway. Most current users are getting the device node from
of_device.node instead of archdata. The number of dev_archdata users
is comparatively small.
> Also, by using dev.of_node directly you have to introduce ugly
> #ifdefs in the non-OF code (as in i2c patch), which you don't
> need with transparent archdata and accessors, which you've just
> removed:
The #ifdefs are only needed in the i2c code because the i2c API
doesn't currently support separate allocation and registration of i2c
devices. With separate allocation and registration, the of_i2c code
could set the device node pointer directly without touching the common
i2c code at all (like how of_register_spi_devices handles it). I do
plan to write a patch to do this, but that is a task for another patch
series.
g.
next prev parent reply other threads:[~2010-03-18 16:22 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-18 15:22 [V2 PATCH 00/10] of: Consolidate scattered device node pointers in struct device Grant Likely
2010-03-18 15:22 ` [V2 PATCH 01/10] driver-core: Add device node pointer to " Grant Likely
2010-03-18 15:22 ` [V2 PATCH 02/10] i2c/of: Allow device node to be passed via i2c_board_info Grant Likely
2010-03-18 15:22 ` [V2 PATCH 03/10] arch/sparc: Always use 'struct device.of_node' to get device node pointer Grant Likely
2010-03-18 15:22 ` [V2 PATCH 04/10] arch/powerpc: " Grant Likely
2010-03-18 15:22 ` [V2 PATCH 05/10] arch/microblaze: " Grant Likely
2010-03-18 15:22 ` [V2 PATCH 06/10] of/drivers: Always use struct device.of_node to get " Grant Likely
2010-03-18 15:58 ` Jochen Friedrich
2010-03-18 16:24 ` Grant Likely
2010-03-18 16:59 ` Sean MacLennan
2010-03-18 17:07 ` Grant Likely
2010-03-18 17:10 ` Sean MacLennan
2010-03-18 17:12 ` Sean MacLennan
2010-03-18 15:22 ` [V2 PATCH 07/10] of: eliminate calls to dev_archdata_set_node() Grant Likely
2010-03-18 15:22 ` [V2 PATCH 08/10] arch/powerpc: Remove obsolete dev_archdata.of_node and of_devce.node Grant Likely
2010-03-18 15:47 ` Anton Vorontsov
2010-03-18 16:22 ` Grant Likely [this message]
2010-03-18 15:22 ` [V2 PATCH 09/10] arch/microblaze: " Grant Likely
2010-03-18 15:23 ` [V2 PATCH 10/10] arch/sparc: Remove obsolete dev_archdata.prom_node " Grant Likely
2010-03-18 15:35 ` [V2 PATCH 00/10] of: Consolidate scattered device node pointers in struct device Grant Likely
2010-03-23 6:57 ` Michael Ellerman
2010-03-23 7:06 ` 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=fa686aa41003180922g3e867bedo337568c3ca6f2097@mail.gmail.com \
--to=grant.likely@secretlab.ca \
--cc=avorontsov@ru.mvista.com \
--cc=davem@davemloft.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=michal.simek@petalogix.com \
--cc=microblaze-uclinux@itee.uq.edu.au \
--cc=sparclinux@vger.kernel.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).