From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Jonathan Cameron <jic23@kernel.org>,
linux-iio <linux-iio@vger.kernel.org>,
Lars-Peter Clausen <lars@metafoo.de>,
"Michael Hennerich" <Michael.Hennerich@analog.com>,
Alexandru Tachici <alexandru.tachici@analog.com>,
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
Subject: Re: [PATCH 2/2] iio:adc:ad7124: Convert to fwnode handling of child node parsing.
Date: Tue, 27 Jul 2021 19:20:13 +0100 [thread overview]
Message-ID: <20210727192013.00003f3c@Huawei.com> (raw)
In-Reply-To: <CAHp75Ve6L+5zAwBJ5ep2VExyNDaSSrEBAonfMT6cFCxEpgUQQA@mail.gmail.com>
On Tue, 27 Jul 2021 17:16:07 +0300
Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> On Tue, Jul 27, 2021 at 4:52 PM Jonathan Cameron
> <Jonathan.Cameron@huawei.com> wrote:
> > On Sun, 25 Jul 2021 23:33:12 +0300
> > Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> > > On Sun, Jul 25, 2021 at 8:22 PM Jonathan Cameron <jic23@kernel.org> wrote:
>
> ...
>
> > > > - for_each_available_child_of_node(np, child) {
> > > > + device_for_each_child_node(dev, child) {
> > >
> > > Isn't this
> > > fwnode_for_each_available_child_node()
> > > better to use?
> >
> > Given we would be extracting the fwnode just to call this
> > loop, I'd say no, device version makes more sense..
> >
> > >
> > > ...
> > >
> > > So the gaps I see are
> > > device_get_available_child_node_count()
> > > and
> > > device_for_each_available_child_node()
> >
> > Do we then fix the fact that
> > device_for_each_child_node() will call the _available() form
> > for device tree? That seems inconsistent currently and
> > I was assuming that was deliberate...
>
> I'm not sure I got your point. Mine (see below) is to add the APIs
> that you want to use as a direct replacement of the corresponding OF
> counterparts.
+CC Rafael,
The oddity is that device_for_each_child_node() is a direct replacement
of the for_each_available_child_of_node() other than the obvious
use of device rather than the of node.
https://elixir.bootlin.com/linux/v5.14-rc3/source/drivers/of/property.c#L939
static struct fwnode_handle *
of_fwnode_get_next_child_node(const struct fwnode_handle *fwnode,
struct fwnode_handle *child)
{
return of_fwnode_handle(of_get_next_available_child(to_of_node(fwnode),
to_of_node(child)));
}
So the question becomes whether there is any desire at all to have a
version of the device_for_each_child_node() that does not check
if it is available or not.
Looks like it goes all the way back. Rafael, any comment on why the available
for is used here and whether it makes sense to introduce separate
versions for looping over children that cover the _available_ and everything
cases?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/base/property.c?id=8a0662d9ed2968e1186208336a8e1fab3fdfea63
I'm kind of assuming this was deliberate as we don't want to encourage
accessing disabled firmware nodes.
Jonathan
>
> > > Both of them I think are easy to add and avoid possible breakage.
>
>
next prev parent reply other threads:[~2021-07-27 18:20 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-25 17:24 [PATCH 0/2] iio:adc:ad7124: Convert to generic firmware handling Jonathan Cameron
2021-07-25 17:24 ` [PATCH 1/2] iio:adc:ad7124: Parse configuration into correct local config structure Jonathan Cameron
2021-07-25 17:24 ` [PATCH 2/2] iio:adc:ad7124: Convert to fwnode handling of child node parsing Jonathan Cameron
2021-07-25 20:33 ` Andy Shevchenko
2021-07-27 13:51 ` Jonathan Cameron
2021-07-27 14:16 ` Andy Shevchenko
2021-07-27 18:20 ` Jonathan Cameron [this message]
2021-08-15 16:09 ` Jonathan Cameron
2021-10-03 15:45 ` Jonathan Cameron
2021-11-28 18:15 ` Jonathan Cameron
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=20210727192013.00003f3c@Huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=Michael.Hennerich@analog.com \
--cc=alexandru.tachici@analog.com \
--cc=andy.shevchenko@gmail.com \
--cc=jic23@kernel.org \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=rafael.j.wysocki@intel.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;
as well as URLs for NNTP newsgroup(s).