[PATCH] device property: introduce fwnode_for_each_child_node_scoped()

[PATCH] device property: introduce fwnode_for_each_child_node_scoped()

[Javier Carrasco]

Add a scoped version of fwnode_for_each_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.

Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net>
---
This macro has been tested with a patch series that has not been
applied yet and is under discussion in input [1], which makes use of the
non-scoped version of the loop.

Based on linux-next (next-20240502).

Link: https://lore.kernel.org/linux-input/20240422-feature-ts_virtobj_patch-v9-0-acf118d12a8a@wolfvision.net/ [1]
---
 include/linux/property.h | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/include/linux/property.h b/include/linux/property.h
index 61fc20e5f81f..88f930165071 100644
--- a/include/linux/property.h
+++ b/include/linux/property.h
@@ -164,6 +164,11 @@ struct fwnode_handle *fwnode_get_next_available_child_node(
 	for (child = fwnode_get_next_child_node(fwnode, NULL); child;	\
 	     child = fwnode_get_next_child_node(fwnode, child))
 
+#define fwnode_for_each_child_node_scoped(fwnode, child)		\
+	for (struct fwnode_handle *child __free(fwnode_handle) =	\
+		fwnode_get_next_child_node(fwnode, NULL);		\
+	     child; child = fwnode_get_next_child_node(fwnode, child))
+
 #define fwnode_for_each_available_child_node(fwnode, child)		       \
 	for (child = fwnode_get_next_available_child_node(fwnode, NULL); child;\
 	     child = fwnode_get_next_available_child_node(fwnode, child))

---
base-commit: 9c6ecb3cb6e20c4fd7997047213ba0efcf9ada1a
change-id: 20240502-fwnode_for_each_child_node_scoped-ce15a9a831c3

Best regards,
-- 
Javier Carrasco <javier.carrasco@wolfvision.net>

Re: [PATCH] device property: introduce fwnode_for_each_child_node_scoped()

[Andy Shevchenko]

On Thu, May 02, 2024 at 12:55:40PM +0200, Javier Carrasco wrote:
> Add a scoped version of fwnode_for_each_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.

Why not _available variant? I believe most of the code should use that.

> Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net>
> ---
> This macro has been tested with a patch series that has not been
> applied yet and is under discussion in input [1], which makes use of the
> non-scoped version of the loop.

So, why should we apply a dead code?

> Based on linux-next (next-20240502).

Use --base instead of this. Ah, and you do, so no need to have this comment.

> Link: https://lore.kernel.org/linux-input/20240422-feature-ts_virtobj_patch-v9-0-acf118d12a8a@wolfvision.net/ [1]

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] device property: introduce fwnode_for_each_child_node_scoped()

[Javier Carrasco]

On 5/2/24 17:34, Andy Shevchenko wrote:
> On Thu, May 02, 2024 at 12:55:40PM +0200, Javier Carrasco wrote:
>> Add a scoped version of fwnode_for_each_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.
> 
> Why not _available variant? I believe most of the code should use that.
> 

That is a good point. I just took a look at users of the _available
variant and at least the LTC2992 (which I can actually test) does not
call fwnode_handle_put() in one error path, so it could already profit
from a scoped version. I will send a new series with the _available
variant and a first use case for the LTC2992.

>> Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net>
>> ---
>> This macro has been tested with a patch series that has not been
>> applied yet and is under discussion in input [1], which makes use of the
>> non-scoped version of the loop.
> 
> So, why should we apply a dead code?
> 

I will add this patch to the series I mentioned, so there is a first use
case. Even if the _available variant is preferred, the other one is more
widely used, and having a scoped version will allow for safer code.

>> Based on linux-next (next-20240502).
> 
> Use --base instead of this. Ah, and you do, so no need to have this comment.
> 

Ack.

>> Link: https://lore.kernel.org/linux-input/20240422-feature-ts_virtobj_patch-v9-0-acf118d12a8a@wolfvision.net/ [1]
> 

Thank you for the review and best regards,
Javier Carrasco

Re: [PATCH] device property: introduce fwnode_for_each_child_node_scoped()

[Andy Shevchenko]

On Thu, May 02, 2024 at 07:58:26PM +0200, Javier Carrasco wrote:
> On 5/2/24 17:34, Andy Shevchenko wrote:
> > On Thu, May 02, 2024 at 12:55:40PM +0200, Javier Carrasco wrote:

...

> >> This macro has been tested with a patch series that has not been
> >> applied yet and is under discussion in input [1], which makes use of the
> >> non-scoped version of the loop.
> > 
> > So, why should we apply a dead code?
> 
> I will add this patch to the series I mentioned, so there is a first use
> case.

Sounds like a good plan.

> Even if the _available variant is preferred, the other one is more
> widely used, and having a scoped version will allow for safer code.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] device property: introduce fwnode_for_each_child_node_scoped()

[Andy Shevchenko]

On Thu, May 02, 2024 at 09:03:09PM +0300, Andy Shevchenko wrote:
> On Thu, May 02, 2024 at 07:58:26PM +0200, Javier Carrasco wrote:
> > On 5/2/24 17:34, Andy Shevchenko wrote:
> > > On Thu, May 02, 2024 at 12:55:40PM +0200, Javier Carrasco wrote:

...

> > >> This macro has been tested with a patch series that has not been
> > >> applied yet and is under discussion in input [1], which makes use of the
> > >> non-scoped version of the loop.
> > > 
> > > So, why should we apply a dead code?
> > 
> > I will add this patch to the series I mentioned, so there is a first use
> > case.
> 
> Sounds like a good plan.

Ah, note that IIO has already some patches against device property APIs. Maybe
it's already done by Jonathan.
Cc'ed to him.

> > Even if the _available variant is preferred, the other one is more
> > widely used, and having a scoped version will allow for safer code.

-- 
With Best Regards,
Andy Shevchenko