public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Kefeng Wang <wangkefeng.wang@huawei.com>,
	Arnd Bergmann <arnd@arndb.de>,
	linux-acpi@vger.kernel.org, Hanjun Guo <hanjun.guo@linaro.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH 2/4] device property: Introduce helper device_get_reference_node()
Date: Fri, 04 Dec 2015 02:02:50 +0100	[thread overview]
Message-ID: <3758717.EIXdfl3l2U@vostro.rjw.lan> (raw)
In-Reply-To: <21014512.b9662OruTx@vostro.rjw.lan>

On Friday, December 04, 2015 12:29:12 AM Rafael J. Wysocki wrote:
> On Thursday, December 03, 2015 03:28:42 PM 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.
> > 
> > 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.
> > 
> > I don't know, maybe there is an intention that fwnode should not be
> > used for DT?
> 
> No, there isn't.
> 
> > Maybe someone who knows what the intentions are behind this fwnode stuff
> > can enlighten the situation, and maybe sort out this apparent oversight
> > which IMHO should've been spotted in the initial fwnode review?
> 
> At that time there was a plan (or maybe just and intention, I'm not sure to
> be honest) to introduce and accessor macro for the of_node pointer in struct
> device and make the users of it access it via that macro, which then would
> make it possible to switch over to using dev->fwnode in the DT case (by
> changing the implementation of that macro).
> 
> That hasn't materialized as clearly visible, but still can be done AFAICS,
> although finding a volunteer for that work may be hard I suppose.

That said if there are real problems with this (other than aesthetics),
I actually may go off and do it, but I can't promise that to happen soon.

Thanks,
Rafael


  reply	other threads:[~2015-12-04  0:32 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 [this message]
2015-12-11 12:35     ` Lorenzo Pieralisi
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=3758717.EIXdfl3l2U@vostro.rjw.lan \
    --to=rjw@rjwysocki.net \
    --cc=arnd@arndb.de \
    --cc=hanjun.guo@linaro.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux@arm.linux.org.uk \
    --cc=wangkefeng.wang@huawei.com \
    /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