From: Andy Shevchenko <andy.shevchenko@gmail.com>
To: Jonathan Cameron <jic23@kernel.org>
Cc: Javier Carrasco <javier.carrasco.cruz@gmail.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Daniel Scally <djrscally@gmail.com>,
Heikki Krogerus <heikki.krogerus@linux.intel.com>,
Sakari Ailus <sakari.ailus@linux.intel.com>,
Jean Delvare <jdelvare@suse.com>,
Guenter Roeck <linux@roeck-us.net>,
Antoniu Miclaus <antoniu.miclaus@analog.com>,
linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-hwmon@vger.kernel.org, Rob Herring <robh@kernel.org>,
devicetree@vger.kernel.org
Subject: Re: [PATCH v2 3/3] hwmon: (ltc2992) Use fwnode_for_each_available_child_node_scoped()
Date: Mon, 27 May 2024 19:28:49 +0300 [thread overview]
Message-ID: <ZlS0wcbBXvSS26Qz@smile.fi.intel.com> (raw)
In-Reply-To: <20240527155717.58292509@jic23-huawei>
On Mon, May 27, 2024 at 03:57:17PM +0100, Jonathan Cameron wrote:
> On Mon, 27 May 2024 17:30:10 +0300
> Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> > Sun, May 26, 2024 at 02:48:51PM +0100, Jonathan Cameron kirjoitti:
> > > On Thu, 23 May 2024 17:47:16 +0200
> > > Javier Carrasco <javier.carrasco.cruz@gmail.com> wrote:
...
> > > This looks like another instances of the lack of clarify about
> > > what device_for_each_child_node[_scoped]() guarantees about node availability.
> > > On DT it guarantees the node is available as ultimately calls
> > > of_get_next_available_child()
> > >
> > > On ACPI it doesn't (I think).
> > > For swnode, there isn't an obvious concept of available.
> > >
> > > It would be much better if we reached some agreement on this and
> > > hence could avoid using the fwnode variants just to get the _available_ form
> > > as done here.
> >
> > > Or just add the device_for_each_available_child_node[_scoped]()
> > > and call that in almost all cases.
> >
> > device_for_each*() _implies_ availability. You need to talk to Rob about all
> > this. The design of the device_for_each*() was exactly done in accordance with
> > his suggestions...
>
> Does it imply that for ACPI? I can't find a query of _STA in the callbacks
> (which is there for the for fwnode_*available calls.
IIRC for ACPI/swnode the availability is always "yes" as long as property can
be found. Basically it means the fwnode_*() == fwnode_*available() for these
back-ends.
AFAIU ACPI concept here is that once parsed and namespaced (in terms of putting
the respective part of description table into ACPI namespace) it's lways
available. Otherwise it's not, but at the same time the respective child node
(property) may not be found
> Mind you it wouldn't be the first time I've missed something in the ACPI parsing
> code, so maybe it is there indirectly.
I might have a weak memory, but see my understanding above.
> I know from previous discussions that the DT version was intentional, but
> I'm nervous that the same assumptions don't apply to ACPI.
>
> > > In generic code, do we ever want to walk unavailable child nodes?
> >
> > ...which are most likely like your question here, i.e. why we ever need to
> > traverse over unavailable nodes.
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2024-05-27 16:28 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-23 15:47 [PATCH v2 0/3] device property: introduce fwnode_for_each_available_child_node_scoped() Javier Carrasco
2024-05-23 15:47 ` [PATCH v2 1/3] hwmon: (ltc2992) Fix memory leak in ltc2992_parse_dt() Javier Carrasco
2024-05-29 22:35 ` Guenter Roeck
2024-05-23 15:47 ` [PATCH v2 2/3] device property: introduce fwnode_for_each_available_child_node_scoped() Javier Carrasco
2024-05-23 15:47 ` [PATCH v2 3/3] hwmon: (ltc2992) Use fwnode_for_each_available_child_node_scoped() Javier Carrasco
2024-05-26 13:48 ` Jonathan Cameron
2024-05-27 14:30 ` Andy Shevchenko
2024-05-27 14:57 ` Jonathan Cameron
2024-05-27 16:28 ` Andy Shevchenko [this message]
2024-06-26 6:33 ` Nuno Sá
2024-06-24 21:45 ` Javier Carrasco
2024-06-30 11:41 ` Jonathan Cameron
2024-07-01 9:35 ` Javier Carrasco
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=ZlS0wcbBXvSS26Qz@smile.fi.intel.com \
--to=andy.shevchenko@gmail.com \
--cc=antoniu.miclaus@analog.com \
--cc=devicetree@vger.kernel.org \
--cc=djrscally@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=heikki.krogerus@linux.intel.com \
--cc=javier.carrasco.cruz@gmail.com \
--cc=jdelvare@suse.com \
--cc=jic23@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=rafael@kernel.org \
--cc=robh@kernel.org \
--cc=sakari.ailus@linux.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