[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fa686aa41003180922g3e867bedo337568c3ca6f2097@mail.gmail.com>
Date: Thu, 18 Mar 2010 10:22:14 -0600
From: Grant Likely <grant.likely@...retlab.ca>
To: avorontsov@...mvista.com
Cc: davem@...emloft.net, benh@...nel.crashing.org,
linux-kernel@...r.kernel.org, michal.simek@...alogix.com,
linuxppc-dev@...ts.ozlabs.org, sparclinux@...r.kernel.org,
microblaze-uclinux@...e.uq.edu.au
Subject: Re: [V2 PATCH 08/10] arch/powerpc: Remove obsolete
dev_archdata.of_node and of_devce.node
On Thu, Mar 18, 2010 at 9:47 AM, Anton Vorontsov
<avorontsov@...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. This 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists