linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
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.

  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).