From: lorenzo.pieralisi@arm.com (Lorenzo Pieralisi)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 2/4] device property: Introduce helper device_get_reference_node()
Date: Fri, 11 Dec 2015 12:35:06 +0000 [thread overview]
Message-ID: <20151211123506.GA30463@red-moon> (raw)
In-Reply-To: <20151203152842.GO8644@n2100.arm.linux.org.uk>
Hi Russell,
On Thu, Dec 03, 2015 at 03:28:42PM +0000, Russell King - ARM Linux wrote:
> On Wed, Dec 02, 2015 at 05:09:26PM +0800, Kefeng Wang wrote:
> > With of_parse_phandle() and acpi_dev_get_reference_device(), we can introduce
> > a universal helper device_get_reference_node() to read and parse a device
> > property and return a pointer to the resulting firmware node.
>
> What's happening to make this fwnode stuff actually usable? Whenever
> I've looked at it from the DT perspective, it looks very much like a
> half-baked train wreck - although the struct device_node contains a
> fwnode, of_node_init() initialises it partially, and we have a way to
> convert _from_ a fwnode to a device_node (to_of_node), nothing sets
> the struct device fwnode pointer.
I might have missed why that pointer is left to NULL in DT, it is
not that complicated to set it up and may actually simplify things
in the process.
Rafael certainly knows better than I do, it could have been done in
commit:
9017f25254e4 ("driver core: Implement device property accessors through
fwnode ones")
except that as you noticed the dev_fwnode has to be special cased since
the OF core does not set the fwnode pointer (there must be a reason
why, if there is not a patch to implement that is simple).
On DT the fwnode_handle is allocated in the struct device_node that
contains it but I still do not see why the fwnode pointer in struct
device can't be made to point at it.
> Whenever I've looked at this, it's always led me to the conclusion
> that the way that fwnode stuff has currently been written, I'm
> supposed to get the device_node, and then use the embedded fwnode
> directly, which I'm pretty sure misses the point of fwnode (as it
> means any driver code making use of this is tied to DT.)
>
> This patch seems to confirm my suspicions that it's just wrong -
> trying to use device_get_reference_node() here will fail in a DT
> based setup, because (I assume) dev_fwnode(dev) returns dev->fwnode
> which is NULL there.
No, dev_fwnode is special cased for OF (have a look at it in
/drivers/base/property.c), I share your question on why it has to
be so, actually this would make dev_fwnode() even simpler.
> I don't know, maybe there is an intention that fwnode should not be
> used for DT?
That's the question we need to get answered :), it might well be that
we can simply update the OF populate code to initialize the pointer
in the struct device.
Thanks,
Lorenzo
next prev parent reply other threads:[~2015-12-11 12:35 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-02 9:09 [RFC PATCH 0/4] add ACPI support for syscon Kefeng Wang
2015-12-02 9:09 ` [RFC PATCH 1/4] acpi: property: Introduce helper acpi_dev_get_reference_device() Kefeng Wang
2015-12-02 9:20 ` Mika Westerberg
2015-12-02 9:09 ` [RFC PATCH 2/4] device property: Introduce helper device_get_reference_node() Kefeng Wang
2015-12-03 15:28 ` Russell King - ARM Linux
2015-12-03 23:29 ` Rafael J. Wysocki
2015-12-04 1:02 ` Rafael J. Wysocki
2015-12-11 12:35 ` Lorenzo Pieralisi [this message]
2015-12-02 9:09 ` [RFC PATCH 3/4] ACPI/platform: Introduce helper acpi_dev_find_plat_dev() Kefeng Wang
2015-12-02 9:09 ` [RFC PATCH 4/4] mfd: syscon: add ACPI support Kefeng Wang
2015-12-02 10:44 ` Arnd Bergmann
2015-12-03 10:41 ` Graeme Gregory
2015-12-03 13:01 ` Kefeng Wang
2015-12-03 15:56 ` Lorenzo Pieralisi
2015-12-07 6:15 ` Kefeng Wang
2015-12-07 8:47 ` Arnd Bergmann
2015-12-11 10:35 ` Zhangfei Gao
2015-12-11 10:51 ` Arnd Bergmann
2015-12-11 10:59 ` Graeme Gregory
2015-12-11 12:23 ` Hanjun Guo
2015-12-02 10:50 ` [RFC PATCH 0/4] add ACPI support for syscon Lorenzo Pieralisi
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=20151211123506.GA30463@red-moon \
--to=lorenzo.pieralisi@arm.com \
--cc=linux-arm-kernel@lists.infradead.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).