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 <[email protected]>
---
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 <[email protected]>
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 <[email protected]>
> ---
> 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 <[email protected]>
>> ---
>> 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