[PATCH v2 0/3] device property: introduce fwnode_for_each_available_child_node_scoped()

[PATCH v2 0/3] device property: introduce fwnode_for_each_available_child_node_scoped()

[Javier Carrasco]

The _scoped() version of the fwnode_for_each_available_child_node()
follows the approach recently taken for other loops that handle child
nodes like for_each_child_of_node_scoped() or
device_for_each_child_node_scoped(), which are based on the __free()
auto cleanup handler to remove the need for fwnode_handle_put() on
early loop exits.

This new variant has been tested with the LTC2992, which currently uses
the non-scoped variant. There is one error path that does not decrement
the refcount of the child node, which can be fixed by using the new
macro. The bug was introduced in a later modification of the loop, which
shows how useful an automatic cleanup solution can be in many uses of
the non-scoped version.

In order to provide a backportable patch, the conversion in the LTC2992
driver is carried out in two steps: first the missing
fwnode_handle_put() is added, and then the code is refactored to adopt
the new, safer approach.

@Andy Shevchenko: I kept your Reviewed-by in 3/3, that now also removes
the new fwnode_handle_put() and braces added with 1/3.

Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
---
Changes in v2:
- Fix the memory leak in a backportable patch and tag it for stable.
- Refactor 1/3 with 3/3 as well.
- Link to v1: https://lore.kernel.org/r/20240522-fwnode_for_each_available_child_node_scoped-v1-0-1188b0da12dc@gmail.com

---
Javier Carrasco (3):
      hwmon: (ltc2992) Fix memory leak in ltc2992_parse_dt()
      device property: introduce fwnode_for_each_available_child_node_scoped()
      hwmon: (ltc2992) Use fwnode_for_each_available_child_node_scoped()

 drivers/hwmon/ltc2992.c  | 11 +++--------
 include/linux/property.h |  5 +++++
 2 files changed, 8 insertions(+), 8 deletions(-)
---
base-commit: 124cfbcd6d185d4f50be02d5f5afe61578916773
change-id: 20240521-fwnode_for_each_available_child_node_scoped-8f1f09d3a10c

Best regards,
-- 
Javier Carrasco <javier.carrasco.cruz@gmail.com>

[PATCH v2 1/3] hwmon: (ltc2992) Fix memory leak in ltc2992_parse_dt()

[Javier Carrasco]

A new error path was added to the fwnode_for_each_available_node() loop
in ltc2992_parse_dt(), which leads to an early return that requires a
call to fwnode_handle_put() to avoid a memory leak in that case.

Add the missing fwnode_handle_put() in the error path from a zero value
shunt resistor.

Cc: stable@vger.kernel.org
Fixes: 10b029020487 ("hwmon: (ltc2992) Avoid division by zero")
Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
---
 drivers/hwmon/ltc2992.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/hwmon/ltc2992.c b/drivers/hwmon/ltc2992.c
index 229aed15d5ca..d4a93223cd3b 100644
--- a/drivers/hwmon/ltc2992.c
+++ b/drivers/hwmon/ltc2992.c
@@ -876,9 +876,11 @@ static int ltc2992_parse_dt(struct ltc2992_state *st)
 
 		ret = fwnode_property_read_u32(child, "shunt-resistor-micro-ohms", &val);
 		if (!ret) {
-			if (!val)
+			if (!val) {
+				fwnode_handle_put(child);
 				return dev_err_probe(&st->client->dev, -EINVAL,
 						     "shunt resistor value cannot be zero\n");
+			}
 			st->r_sense_uohm[addr] = val;
 		}
 	}

-- 
2.40.1

[PATCH v2 2/3] device property: introduce fwnode_for_each_available_child_node_scoped()

[Javier Carrasco]

Add a scoped version of fwnode_for_each_available_child_node() following
the approach recently taken for other loops that handle child nodes like
for_each_child_of_node_scoped() or device_for_each_child_node_scoped(),
which are based on the __free() auto cleanup handler to remove the need
for fwnode_handle_put() on early loop exits.

Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
---
 include/linux/property.h | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/include/linux/property.h b/include/linux/property.h
index 61fc20e5f81f..bcc3dda5a9d8 100644
--- a/include/linux/property.h
+++ b/include/linux/property.h
@@ -168,6 +168,11 @@ struct fwnode_handle *fwnode_get_next_available_child_node(
 	for (child = fwnode_get_next_available_child_node(fwnode, NULL); child;\
 	     child = fwnode_get_next_available_child_node(fwnode, child))
 
+#define fwnode_for_each_available_child_node_scoped(fwnode, child)	\
+	for (struct fwnode_handle *child __free(fwnode_handle) =	\
+		fwnode_get_next_available_child_node(fwnode, NULL);	\
+	     child; child = fwnode_get_next_available_child_node(fwnode, child))
+
 struct fwnode_handle *device_get_next_child_node(const struct device *dev,
 						 struct fwnode_handle *child);
 

-- 
2.40.1

[PATCH v2 3/3] hwmon: (ltc2992) Use fwnode_for_each_available_child_node_scoped()

[Javier Carrasco]

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>
---
 drivers/hwmon/ltc2992.c | 15 ++++-----------
 1 file changed, 4 insertions(+), 11 deletions(-)

diff --git a/drivers/hwmon/ltc2992.c b/drivers/hwmon/ltc2992.c
index d4a93223cd3b..3feee400ecf8 100644
--- a/drivers/hwmon/ltc2992.c
+++ b/drivers/hwmon/ltc2992.c
@@ -855,32 +855,25 @@ static const struct regmap_config ltc2992_regmap_config = {
 static int ltc2992_parse_dt(struct ltc2992_state *st)
 {
 	struct fwnode_handle *fwnode;
-	struct fwnode_handle *child;
 	u32 addr;
 	u32 val;
 	int ret;
 
 	fwnode = dev_fwnode(&st->client->dev);
 
-	fwnode_for_each_available_child_node(fwnode, child) {
+	fwnode_for_each_available_child_node_scoped(fwnode, child) {
 		ret = fwnode_property_read_u32(child, "reg", &addr);
-		if (ret < 0) {
-			fwnode_handle_put(child);
+		if (ret < 0)
 			return ret;
-		}
 
-		if (addr > 1) {
-			fwnode_handle_put(child);
+		if (addr > 1)
 			return -EINVAL;
-		}
 
 		ret = fwnode_property_read_u32(child, "shunt-resistor-micro-ohms", &val);
 		if (!ret) {
-			if (!val) {
-				fwnode_handle_put(child);
+			if (!val)
 				return dev_err_probe(&st->client->dev, -EINVAL,
 						     "shunt resistor value cannot be zero\n");
-			}
 			st->r_sense_uohm[addr] = val;
 		}
 	}

-- 
2.40.1

Re: [PATCH v2 3/3] hwmon: (ltc2992) Use fwnode_for_each_available_child_node_scoped()

[Jonathan Cameron]

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





> ---
>  drivers/hwmon/ltc2992.c | 15 ++++-----------
>  1 file changed, 4 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/hwmon/ltc2992.c b/drivers/hwmon/ltc2992.c
> index d4a93223cd3b..3feee400ecf8 100644
> --- a/drivers/hwmon/ltc2992.c
> +++ b/drivers/hwmon/ltc2992.c
> @@ -855,32 +855,25 @@ static const struct regmap_config ltc2992_regmap_config = {
>  static int ltc2992_parse_dt(struct ltc2992_state *st)
>  {
>  	struct fwnode_handle *fwnode;
> -	struct fwnode_handle *child;
>  	u32 addr;
>  	u32 val;
>  	int ret;
>  
>  	fwnode = dev_fwnode(&st->client->dev);
>  
> -	fwnode_for_each_available_child_node(fwnode, child) {
> +	fwnode_for_each_available_child_node_scoped(fwnode, child) {
>  		ret = fwnode_property_read_u32(child, "reg", &addr);
> -		if (ret < 0) {
> -			fwnode_handle_put(child);
> +		if (ret < 0)
>  			return ret;
> -		}
>  
> -		if (addr > 1) {
> -			fwnode_handle_put(child);
> +		if (addr > 1)
>  			return -EINVAL;
> -		}
>  
>  		ret = fwnode_property_read_u32(child, "shunt-resistor-micro-ohms", &val);
>  		if (!ret) {
> -			if (!val) {
> -				fwnode_handle_put(child);
> +			if (!val)
>  				return dev_err_probe(&st->client->dev, -EINVAL,
>  						     "shunt resistor value cannot be zero\n");
> -			}
>  			st->r_sense_uohm[addr] = val;
>  		}
>  	}
> 

Re: [PATCH v2 3/3] hwmon: (ltc2992) Use fwnode_for_each_available_child_node_scoped()

[Andy Shevchenko]

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:
> 
> > 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.

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...

> 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

Re: [PATCH v2 3/3] hwmon: (ltc2992) Use fwnode_for_each_available_child_node_scoped()

[Jonathan Cameron]

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:
> >   
> > > 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.  
> 
> 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.
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 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.
> 

Jonathan

Re: [PATCH v2 3/3] hwmon: (ltc2992) Use fwnode_for_each_available_child_node_scoped()

[Andy Shevchenko]

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

Re: [PATCH v2 1/3] hwmon: (ltc2992) Fix memory leak in ltc2992_parse_dt()

[Guenter Roeck]

On Thu, May 23, 2024 at 05:47:14PM +0200, Javier Carrasco wrote:
> A new error path was added to the fwnode_for_each_available_node() loop
> in ltc2992_parse_dt(), which leads to an early return that requires a
> call to fwnode_handle_put() to avoid a memory leak in that case.
> 
> Add the missing fwnode_handle_put() in the error path from a zero value
> shunt resistor.
> 
> Cc: stable@vger.kernel.org
> Fixes: 10b029020487 ("hwmon: (ltc2992) Avoid division by zero")
> Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>

Applied.

Thanks,
Guenter

> ---
>  drivers/hwmon/ltc2992.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/hwmon/ltc2992.c b/drivers/hwmon/ltc2992.c
> index 229aed15d5ca..d4a93223cd3b 100644
> --- a/drivers/hwmon/ltc2992.c
> +++ b/drivers/hwmon/ltc2992.c
> @@ -876,9 +876,11 @@ static int ltc2992_parse_dt(struct ltc2992_state *st)
>  
>  		ret = fwnode_property_read_u32(child, "shunt-resistor-micro-ohms", &val);
>  		if (!ret) {
> -			if (!val)
> +			if (!val) {
> +				fwnode_handle_put(child);
>  				return dev_err_probe(&st->client->dev, -EINVAL,
>  						     "shunt resistor value cannot be zero\n");
> +			}
>  			st->r_sense_uohm[addr] = val;
>  		}
>  	}

Re: [PATCH v2 3/3] hwmon: (ltc2992) Use fwnode_for_each_available_child_node_scoped()

[Javier Carrasco]

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

Re: [PATCH v2 3/3] hwmon: (ltc2992) Use fwnode_for_each_available_child_node_scoped()

[Nuno Sá]

On Mon, 2024-05-27 at 17:30 +0300, Andy Shevchenko 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:
> > 
> > > 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.
> 
> 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...
> 
> > 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.
> 

I have some vague idea of Rob talking about CPUs being one of the reasons for
the current design. Don't remember for sure. At least (if not already) having
this clearly documented would be nice.

- Nuno Sá

Re: [PATCH v2 3/3] hwmon: (ltc2992) Use fwnode_for_each_available_child_node_scoped()

[Jonathan Cameron]

On Mon, 24 Jun 2024 23:45:42 +0200
Javier Carrasco <javier.carrasco.cruz@gmail.com> wrote:

> 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.

Straw man for people to shoot at:

I think where possible rely on device_for_each_child_node[_scoped]()
actually meaning the available nodes.  In cases where it applies that
is normally cleaner anyway.

If you find cases where there is no relevant device (I'm sure there are some)
just provide fwnode_for_each_available_child_node() and not the non-available
one.  If that means switching some drivers to use the available form as
part of cleanups, at that point we consider if there is a special reason
it actually wants the non available modes.

Ideally we also add documentation to say the device_for_each_child_node()
will (at least mostly) not consider non available nodes.  It might
be always, I'm still personally not sure on that!

Jonathan

> 
> Thanks and best regards,
> Javier Carrasco

Re: [PATCH v2 3/3] hwmon: (ltc2992) Use fwnode_for_each_available_child_node_scoped()

[Javier Carrasco]

On 30/06/2024 13:41, Jonathan Cameron wrote:
> On Mon, 24 Jun 2024 23:45:42 +0200
> Javier Carrasco <javier.carrasco.cruz@gmail.com> wrote:
> 
>> 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>  

...

> 
> Straw man for people to shoot at:
> 
> I think where possible rely on device_for_each_child_node[_scoped]()
> actually meaning the available nodes.  In cases where it applies that
> is normally cleaner anyway.
> 
> If you find cases where there is no relevant device (I'm sure there are some)
> just provide fwnode_for_each_available_child_node() and not the non-available
> one.  If that means switching some drivers to use the available form as
> part of cleanups, at that point we consider if there is a special reason
> it actually wants the non available modes.
> 
> Ideally we also add documentation to say the device_for_each_child_node()
> will (at least mostly) not consider non available nodes.  It might
> be always, I'm still personally not sure on that!
> 
> Jonathan

There are multiple cases where fwnode_for_each_available_child_node()
seems to be used just to get a macro that explicitly guarantees node
availability i.e. they retrieve ’fwnode’ out of ’device' by means of
dev_fwnode() to pass it to the loop.

In those cases, device_for_each_child_node[_scoped]() could be used if
it guarantees availability, which no one could refute so far.

On the other hand, there are other uses that do need the fwnode_*
variants because they iterate over nodes inside another node which is
usually retrieved via device_get_named_child_node().

If there are no objections or better proposals, I will proceed as follows:

1. Document that device_for_each_child_node() means availability.
2. Use device_for_each_child_node[_scoped]() instead of the fwnode_*
variant where it makes sense.
3. Provide fwnode_*_scoped() macros.
4. Use the new macros where needed.
5. Use fwnode_for_each_available_child_node() as the default where
unavailable nodes are not explicitly required.

Any additional feedback, especially to clarify _availability_ in the
device_for_each_child_node macros, or to provide a case where
unavailable nodes must be considered (Nuno mentioned CPUs, but just as a
vague idea) is more than welcome.

Best regards,
Javier Carrasco