From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Michael Walle <michael@walle.cc>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
linux-acpi@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: fwnode_for_each_child_node() and OF backend discrepancy
Date: Tue, 28 Jun 2022 14:10:43 +0300 [thread overview]
Message-ID: <Yrrhs3D++V79/4Jk@smile.fi.intel.com> (raw)
In-Reply-To: <4e1d5db9dea68d82c94336a1d6aac404@walle.cc>
On Mon, Jun 27, 2022 at 02:49:51PM +0200, Michael Walle wrote:
> Hi,
>
> I tired to iterate over all child nodes, regardless if they are available
> or not. Now there is that handy fwnode_for_each_child_node() (and the
> fwnode_for_each_available_child_node()). The only thing is the OF backend
> already skips disabled nodes [1], making fwnode_for_each_child_node() and
> fwnode_for_each_available_child_node() behave the same with the OF backend.
>
> Doesn't seem to be noticed by anyone for now. I'm not sure how to fix that
> one. fwnode_for_each_child_node() and also fwnode_get_next_child_node() are
> used by a handful of drivers. I've looked at some, but couldn't decide
> whether they really want to iterate over all child nodes or just the enabled
> ones.
>
> Any thoughts?
It was discussed at least twice this year (in regard to some new IIO drivers)
and Rob told that iterating over disabled (not available) nodes in OF kinda
legacy/design mistake. That's why device_for_each_child_node() goes only
over available nodes only.
So, why do you need to iterate over disabled ones?
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2022-06-28 11:10 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-27 12:49 fwnode_for_each_child_node() and OF backend discrepancy Michael Walle
2022-06-27 13:08 ` Krzysztof Kozlowski
2022-06-27 13:33 ` Rafael J. Wysocki
2022-06-28 10:32 ` Krzysztof Kozlowski
2022-06-28 14:41 ` Sakari Ailus
2022-06-29 10:50 ` Rafael J. Wysocki
2022-06-29 13:01 ` Grant Likely
2022-06-28 11:10 ` Andy Shevchenko [this message]
2022-06-28 11:36 ` Michael Walle
2022-06-28 13:11 ` Andy Shevchenko
2022-06-28 13:23 ` Michael Walle
2022-06-28 13:29 ` Andy Shevchenko
2022-06-28 13:47 ` Michael Walle
2022-06-28 13:51 ` Krzysztof Kozlowski
2022-06-28 14:22 ` Michael Walle
2022-06-28 14:36 ` Krzysztof Kozlowski
2022-06-28 15:09 ` Michael Walle
2022-06-28 15:17 ` Krzysztof Kozlowski
2022-06-28 20:28 ` Andy Shevchenko
2022-06-28 20:52 ` Horatiu Vultur
2022-06-28 21:07 ` Michael Walle
2022-06-30 20:16 ` Horatiu Vultur
2022-06-30 21:00 ` Michael Walle
2022-06-30 21:21 ` Vladimir Oltean
2022-06-30 21:32 ` Michael Walle
2022-06-28 21:59 ` Vladimir Oltean
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=Yrrhs3D++V79/4Jk@smile.fi.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=devicetree@vger.kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michael@walle.cc \
--cc=rafael@kernel.org \
--cc=robh+dt@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