include/linux/property.h | 5 +++++ 1 file changed, 5 insertions(+)
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>
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
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
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
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
© 2016 - 2025 Red Hat, Inc.