Message ID | 20240502-fwnode_for_each_child_node_scoped-v1-1-868a2b168fa8@wolfvision.net (mailing list archive) |
---|---|
State | Handled Elsewhere, archived |
Headers | show |
Series | device property: introduce fwnode_for_each_child_node_scoped() | expand |
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]
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.
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.
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))
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(+) --- base-commit: 9c6ecb3cb6e20c4fd7997047213ba0efcf9ada1a change-id: 20240502-fwnode_for_each_child_node_scoped-ce15a9a831c3 Best regards,