* [PATCH v1 1/1] device property: Allow secondary lookup in fwnode_get_next_child_node()
@ 2026-02-10 13:58 Andy Shevchenko
2026-02-10 22:02 ` Sakari Ailus
2026-02-22 23:19 ` Danilo Krummrich
0 siblings, 2 replies; 6+ messages in thread
From: Andy Shevchenko @ 2026-02-10 13:58 UTC (permalink / raw)
To: Andy Shevchenko, linux-acpi, linux-kernel
Cc: Daniel Scally, Heikki Krogerus, Sakari Ailus, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, stable
When device_get_child_node_count() got split to the fwnode and device
respective APIs, the fwnode didn't inherit the ability to traverse over
the secondary fwnode. Hence any user, that switches from device to fwnode
API misses this feature. In particular, this was revealed by the commit
1490cbb9dbfd ("device property: Split fwnode_get_child_node_count()")
that effectively broke the GPIO enumeration on Intel Galileo boards.
Fix this by moving the secondary lookup from device to fwnode API.
Note, in general no device_*() API should go into the depth of the fwnode
implementation.
Fixes: 114dbb4fa7c4 ("drivers property: When no children in primary, try secondary")
Cc: stable@vger.kernel.org
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/base/property.c | 27 +++++++++++++--------------
1 file changed, 13 insertions(+), 14 deletions(-)
diff --git a/drivers/base/property.c b/drivers/base/property.c
index 6a63860579dd..8d9a34be57fb 100644
--- a/drivers/base/property.c
+++ b/drivers/base/property.c
@@ -797,7 +797,18 @@ struct fwnode_handle *
fwnode_get_next_child_node(const struct fwnode_handle *fwnode,
struct fwnode_handle *child)
{
- return fwnode_call_ptr_op(fwnode, get_next_child_node, child);
+ struct fwnode_handle *next;
+
+ if (IS_ERR_OR_NULL(fwnode))
+ return NULL;
+
+ /* Try to find a child in primary fwnode */
+ next = fwnode_call_ptr_op(fwnode, get_next_child_node, child);
+ if (next)
+ return next;
+
+ /* When no more children in primary, continue with secondary */
+ return fwnode_call_ptr_op(fwnode->secondary, get_next_child_node, child);
}
EXPORT_SYMBOL_GPL(fwnode_get_next_child_node);
@@ -841,19 +852,7 @@ EXPORT_SYMBOL_GPL(fwnode_get_next_available_child_node);
struct fwnode_handle *device_get_next_child_node(const struct device *dev,
struct fwnode_handle *child)
{
- const struct fwnode_handle *fwnode = dev_fwnode(dev);
- struct fwnode_handle *next;
-
- if (IS_ERR_OR_NULL(fwnode))
- return NULL;
-
- /* Try to find a child in primary fwnode */
- next = fwnode_get_next_child_node(fwnode, child);
- if (next)
- return next;
-
- /* When no more children in primary, continue with secondary */
- return fwnode_get_next_child_node(fwnode->secondary, child);
+ return fwnode_get_next_child_node(dev_fwnode(dev), child);
}
EXPORT_SYMBOL_GPL(device_get_next_child_node);
--
2.50.1
^ permalink raw reply related [flat|nested] 6+ messages in thread* Re: [PATCH v1 1/1] device property: Allow secondary lookup in fwnode_get_next_child_node()
2026-02-10 13:58 [PATCH v1 1/1] device property: Allow secondary lookup in fwnode_get_next_child_node() Andy Shevchenko
@ 2026-02-10 22:02 ` Sakari Ailus
2026-02-11 8:14 ` Andy Shevchenko
2026-02-22 23:19 ` Danilo Krummrich
1 sibling, 1 reply; 6+ messages in thread
From: Sakari Ailus @ 2026-02-10 22:02 UTC (permalink / raw)
To: Andy Shevchenko
Cc: linux-acpi, linux-kernel, Daniel Scally, Heikki Krogerus,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich, stable
Hi Andy,
Thanks for the patch.
On Tue, Feb 10, 2026 at 02:58:22PM +0100, Andy Shevchenko wrote:
> When device_get_child_node_count() got split to the fwnode and device
> respective APIs, the fwnode didn't inherit the ability to traverse over
> the secondary fwnode. Hence any user, that switches from device to fwnode
> API misses this feature. In particular, this was revealed by the commit
> 1490cbb9dbfd ("device property: Split fwnode_get_child_node_count()")
> that effectively broke the GPIO enumeration on Intel Galileo boards.
> Fix this by moving the secondary lookup from device to fwnode API.
>
> Note, in general no device_*() API should go into the depth of the fwnode
> implementation.
>
> Fixes: 114dbb4fa7c4 ("drivers property: When no children in primary, try secondary")
> Cc: stable@vger.kernel.org
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
> drivers/base/property.c | 27 +++++++++++++--------------
> 1 file changed, 13 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/base/property.c b/drivers/base/property.c
> index 6a63860579dd..8d9a34be57fb 100644
> --- a/drivers/base/property.c
> +++ b/drivers/base/property.c
> @@ -797,7 +797,18 @@ struct fwnode_handle *
> fwnode_get_next_child_node(const struct fwnode_handle *fwnode,
> struct fwnode_handle *child)
> {
> - return fwnode_call_ptr_op(fwnode, get_next_child_node, child);
> + struct fwnode_handle *next;
> +
> + if (IS_ERR_OR_NULL(fwnode))
> + return NULL;
This test is already being done by fwnode_call_ptr_op() (via
fwnode_has_op()) so I'd omit it here. That would probably be best put in
another patch though. Up to you.
> +
> + /* Try to find a child in primary fwnode */
> + next = fwnode_call_ptr_op(fwnode, get_next_child_node, child);
> + if (next)
> + return next;
> +
> + /* When no more children in primary, continue with secondary */
> + return fwnode_call_ptr_op(fwnode->secondary, get_next_child_node, child);
> }
> EXPORT_SYMBOL_GPL(fwnode_get_next_child_node);
>
> @@ -841,19 +852,7 @@ EXPORT_SYMBOL_GPL(fwnode_get_next_available_child_node);
> struct fwnode_handle *device_get_next_child_node(const struct device *dev,
> struct fwnode_handle *child)
> {
> - const struct fwnode_handle *fwnode = dev_fwnode(dev);
> - struct fwnode_handle *next;
> -
> - if (IS_ERR_OR_NULL(fwnode))
> - return NULL;
> -
> - /* Try to find a child in primary fwnode */
> - next = fwnode_get_next_child_node(fwnode, child);
> - if (next)
> - return next;
> -
> - /* When no more children in primary, continue with secondary */
> - return fwnode_get_next_child_node(fwnode->secondary, child);
> + return fwnode_get_next_child_node(dev_fwnode(dev), child);
As the function becomes trivial, I'd move it to property.h.
> }
> EXPORT_SYMBOL_GPL(device_get_next_child_node);
>
--
Kind regards,
Sakari Ailus
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH v1 1/1] device property: Allow secondary lookup in fwnode_get_next_child_node()
2026-02-10 22:02 ` Sakari Ailus
@ 2026-02-11 8:14 ` Andy Shevchenko
2026-02-11 8:27 ` Sakari Ailus
0 siblings, 1 reply; 6+ messages in thread
From: Andy Shevchenko @ 2026-02-11 8:14 UTC (permalink / raw)
To: Sakari Ailus
Cc: linux-acpi, linux-kernel, Daniel Scally, Heikki Krogerus,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich, stable
On Wed, Feb 11, 2026 at 12:02:57AM +0200, Sakari Ailus wrote:
> On Tue, Feb 10, 2026 at 02:58:22PM +0100, Andy Shevchenko wrote:
> > When device_get_child_node_count() got split to the fwnode and device
> > respective APIs, the fwnode didn't inherit the ability to traverse over
> > the secondary fwnode. Hence any user, that switches from device to fwnode
> > API misses this feature. In particular, this was revealed by the commit
> > 1490cbb9dbfd ("device property: Split fwnode_get_child_node_count()")
> > that effectively broke the GPIO enumeration on Intel Galileo boards.
> > Fix this by moving the secondary lookup from device to fwnode API.
> >
> > Note, in general no device_*() API should go into the depth of the fwnode
> > implementation.
Thanks for the review, my answers below.
...
> > + if (IS_ERR_OR_NULL(fwnode))
> > + return NULL;
>
> This test is already being done by fwnode_call_ptr_op() (via
> fwnode_has_op()) so I'd omit it here. That would probably be best put in
> another patch though. Up to you.
I would like to keep this as is for the matter of backporting.
With that done, I can clean up further.
...
> As the function becomes trivial, I'd move it to property.h.
Yes, but the same applies to many functions in the property.c. I don't want to
treat this specially:
- exceptionally for this function (what about the rest?)
- for the matters of backporting
...
TL;DR: I would like to move this patch forward as is. After that I will
consider cleaning up as suggested taking into account other places.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH v1 1/1] device property: Allow secondary lookup in fwnode_get_next_child_node()
2026-02-11 8:14 ` Andy Shevchenko
@ 2026-02-11 8:27 ` Sakari Ailus
2026-02-11 8:33 ` Andy Shevchenko
0 siblings, 1 reply; 6+ messages in thread
From: Sakari Ailus @ 2026-02-11 8:27 UTC (permalink / raw)
To: Andy Shevchenko
Cc: linux-acpi, linux-kernel, Daniel Scally, Heikki Krogerus,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich, stable
Hi Andy,
On Wed, Feb 11, 2026 at 10:14:59AM +0200, Andy Shevchenko wrote:
> On Wed, Feb 11, 2026 at 12:02:57AM +0200, Sakari Ailus wrote:
> > On Tue, Feb 10, 2026 at 02:58:22PM +0100, Andy Shevchenko wrote:
> > > When device_get_child_node_count() got split to the fwnode and device
> > > respective APIs, the fwnode didn't inherit the ability to traverse over
> > > the secondary fwnode. Hence any user, that switches from device to fwnode
> > > API misses this feature. In particular, this was revealed by the commit
> > > 1490cbb9dbfd ("device property: Split fwnode_get_child_node_count()")
> > > that effectively broke the GPIO enumeration on Intel Galileo boards.
> > > Fix this by moving the secondary lookup from device to fwnode API.
> > >
> > > Note, in general no device_*() API should go into the depth of the fwnode
> > > implementation.
>
> Thanks for the review, my answers below.
>
> ...
>
> > > + if (IS_ERR_OR_NULL(fwnode))
> > > + return NULL;
> >
> > This test is already being done by fwnode_call_ptr_op() (via
> > fwnode_has_op()) so I'd omit it here. That would probably be best put in
> > another patch though. Up to you.
>
> I would like to keep this as is for the matter of backporting.
> With that done, I can clean up further.
>
> ...
>
> > As the function becomes trivial, I'd move it to property.h.
>
> Yes, but the same applies to many functions in the property.c. I don't want to
> treat this specially:
> - exceptionally for this function (what about the rest?)
> - for the matters of backporting
There are other similar functions in property.h already. Moving the other
trivial ones there, too, wouldn't hurt.
>
> ...
>
> TL;DR: I would like to move this patch forward as is. After that I will
> consider cleaning up as suggested taking into account other places.
Sounds good to me.
Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
--
Kind regards,
Sakari Ailus
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH v1 1/1] device property: Allow secondary lookup in fwnode_get_next_child_node()
2026-02-11 8:27 ` Sakari Ailus
@ 2026-02-11 8:33 ` Andy Shevchenko
0 siblings, 0 replies; 6+ messages in thread
From: Andy Shevchenko @ 2026-02-11 8:33 UTC (permalink / raw)
To: Sakari Ailus
Cc: linux-acpi, linux-kernel, Daniel Scally, Heikki Krogerus,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich, stable
On Wed, Feb 11, 2026 at 10:27:28AM +0200, Sakari Ailus wrote:
> On Wed, Feb 11, 2026 at 10:14:59AM +0200, Andy Shevchenko wrote:
> > On Wed, Feb 11, 2026 at 12:02:57AM +0200, Sakari Ailus wrote:
> > > On Tue, Feb 10, 2026 at 02:58:22PM +0100, Andy Shevchenko wrote:
...
> > > As the function becomes trivial, I'd move it to property.h.
> >
> > Yes, but the same applies to many functions in the property.c. I don't want to
> > treat this specially:
> > - exceptionally for this function (what about the rest?)
> > - for the matters of backporting
>
> There are other similar functions in property.h already. Moving the other
> trivial ones there, too, wouldn't hurt.
There is actually a potential issue that I would like to avoid. Id est
the device.h is a mess and first of all I want to split it to a few other
headers (one of which for the fwnode stuff), and only after that reshuffle
this, because blindly moving everything to the header is not a good
strategy in long term.
...
> > TL;DR: I would like to move this patch forward as is. After that I will
> > consider cleaning up as suggested taking into account other places.
>
> Sounds good to me.
>
> Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Thanks!
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v1 1/1] device property: Allow secondary lookup in fwnode_get_next_child_node()
2026-02-10 13:58 [PATCH v1 1/1] device property: Allow secondary lookup in fwnode_get_next_child_node() Andy Shevchenko
2026-02-10 22:02 ` Sakari Ailus
@ 2026-02-22 23:19 ` Danilo Krummrich
1 sibling, 0 replies; 6+ messages in thread
From: Danilo Krummrich @ 2026-02-22 23:19 UTC (permalink / raw)
To: Andy Shevchenko
Cc: linux-acpi, linux-kernel, Daniel Scally, Heikki Krogerus,
Sakari Ailus, Greg Kroah-Hartman, Rafael J. Wysocki, stable
On Tue Feb 10, 2026 at 2:58 PM CET, Andy Shevchenko wrote:
> When device_get_child_node_count() got split to the fwnode and device
> respective APIs, the fwnode didn't inherit the ability to traverse over
> the secondary fwnode. Hence any user, that switches from device to fwnode
> API misses this feature. In particular, this was revealed by the commit
> 1490cbb9dbfd ("device property: Split fwnode_get_child_node_count()")
> that effectively broke the GPIO enumeration on Intel Galileo boards.
> Fix this by moving the secondary lookup from device to fwnode API.
>
> Note, in general no device_*() API should go into the depth of the fwnode
> implementation.
>
> Fixes: 114dbb4fa7c4 ("drivers property: When no children in primary, try secondary")
> Cc: stable@vger.kernel.org
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Applied to driver-core-linus, thanks!
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2026-02-22 23:19 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-02-10 13:58 [PATCH v1 1/1] device property: Allow secondary lookup in fwnode_get_next_child_node() Andy Shevchenko
2026-02-10 22:02 ` Sakari Ailus
2026-02-11 8:14 ` Andy Shevchenko
2026-02-11 8:27 ` Sakari Ailus
2026-02-11 8:33 ` Andy Shevchenko
2026-02-22 23:19 ` Danilo Krummrich
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox