From: Javier Carrasco <javier.carrasco.cruz@gmail.com>
To: Jonathan Cameron <jic23@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
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, 24 Jun 2024 23:45:42 +0200 [thread overview]
Message-ID: <3a16dc06-81df-4493-bac6-216e9c6ea16e@gmail.com> (raw)
In-Reply-To: <20240526144851.493dd3f2@jic23-huawei>
On 26/05/2024 15:48, Jonathan Cameron wrote:
> On Thu, 23 May 2024 17:47:16 +0200
> Javier Carrasco <javier.carrasco.cruz@gmail.com> wrote:
>
>> The scoped version of the fwnode_for_each_available_child_node() macro
>> automates object recfount decrement, avoiding possible memory leaks
>> in new error paths inside the loop like it happened when
>> commit '10b029020487 ("hwmon: (ltc2992) Avoid division by zero")'
>> was added.
>>
>> The new macro removes the need to manually call fwnode_handle_put() in
>> the existing error paths and in any future addition. It also removes the
>> need for the current child node declaration as well, as it is internally
>> declared.
>>
>> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>> Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
>
> 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.
>
> In generic code, do we ever want to walk unavailable child nodes?
>
> Jonathan
>
Hi,
if I did not miss anything, the discussion about the convenience of the
fwnode_for_each_available_child_node_scoped() macro stalled without a
clear outcome.
At this point there are multiple users of both
fwnode_for_each_child_node() and fwnode_for_each_available_child_node(),
and I wonder how many of them use the non-scoped version for a different
reason than not having/knowing the _available_ variant back then.
Maybe touching that now could turn into regressions if someone is just
ignoring that some nodes are actually disabled. Their bad, but still
painful. But maybe there is a better reason to have both macros I don't
know.
As I am still interested in this matter for new users that only want to
iterate over available nodes, and I want to have a scoped solution, I
would like to revive this discussion.
Thanks and best regards,
Javier Carrasco
next prev parent reply other threads:[~2024-06-24 21:45 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
2024-06-26 6:33 ` Nuno Sá
2024-06-24 21:45 ` Javier Carrasco [this message]
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=3a16dc06-81df-4493-bac6-216e9c6ea16e@gmail.com \
--to=javier.carrasco.cruz@gmail.com \
--cc=andriy.shevchenko@linux.intel.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=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