Hello everyone,

Historically the fwnode property API has enumerated only available device
nodes on OF whereas on ACPI, also nodes that haven't been present in the
system have been provided. Both OF and ACPI have similar concepts of node
availbility, on OF it's the "status" property present on device nodes and
on ACPI the _STA object evaluates to device present, enabled and
functional bits, of which the present and functional bits are currently
being used to determine whether to enumerate a device.

Two additional functions, fwnode_get_next_available_child_node() and
fwnode_for_each_available_child_node(), have been provided to enumerate
the available nodes only on ACPI, whereas on OF the implementation has
been the same on the non-available variants. The motivation for providing
these has very likely been to provide fwnode variants of the similarly
named functions but the difference isn't justifiable from API consistency
viewpoint.

This set switches the users away from the "available" fwnode API functions
and later on removes them, aligning the functionality on all fwnode
backends.

since v1:

- Move patch "ACPI: property: Make acpi_get_next_subnode() static" as
  first.

- Add missing parentheses and kernel-doc Return: section in
  acpi_get_next_present_subnode() documentation and move the Return
  section: of fwnode_graph_get_endpoint_by_id() to the end of the
  documentation section (new patch for the latter).

- Use device_get_next_child_node() instead of fwnode_get_next_child_node()
  in flash LED driver drivers.

- Rework iterating port nodes in acpi_graph_get_next_endpoint() as
  suggested by Andy (new patch).

Sakari Ailus (16):
  ACPI: property: Make acpi_get_next_subnode() static
  ACPI: property: Use ACPI functions in acpi_graph_get_next_endpoint()
    only
  ACPI: property: Rework acpi_graph_get_next_endpoint()
  ACPI: property: Return present device nodes only on fwnode interface
  property: Move Return: section of fwnode_graph_get_endpoint_by_id()
    down
  property: Drop DEVICE_DISABLED flag in
    fwnode_graph_get_endpoint_by_id()
  property: Drop DEVICE_DISABLED flag in
    fwnode_graph_get_endpoint_count()
  property: Document that fwnode API returns available nodes
  driver core: Use fwnode_for_each_child_node() instead
  net: lan966x: Use fwnode_for_each_child_node() instead
  Input: touch-overlay - Use fwnode_for_each_child_node() instead
  media: thp7312: Use fwnode_for_each_child_node() instead
  leds: Use fwnode_for_each_child_node() instead
  leds: Use fwnode_get_next_child_node() instead
  property: Drop functions operating on "available" child nodes
  spi: cadence: Remove explicit device node availability check

 drivers/acpi/property.c                       | 42 +++++++++----
 drivers/base/core.c                           | 10 ++--
 drivers/base/property.c                       | 60 ++++---------------
 drivers/input/touch-overlay.c                 |  2 +-
 drivers/leds/flash/leds-rt4505.c              |  2 +-
 drivers/leds/flash/leds-rt8515.c              |  2 +-
 drivers/leds/flash/leds-sgm3140.c             |  3 +-
 drivers/leds/flash/leds-tps6131x.c            |  2 +-
 drivers/leds/leds-max5970.c                   |  2 +-
 drivers/leds/leds-max77705.c                  |  2 +-
 drivers/leds/rgb/leds-ktd202x.c               |  4 +-
 drivers/leds/rgb/leds-ncp5623.c               |  2 +-
 drivers/media/i2c/thp7312.c                   |  2 +-
 .../ethernet/microchip/lan966x/lan966x_main.c |  2 +-
 drivers/spi/spi-cadence-xspi.c                |  3 -
 include/linux/acpi.h                          | 10 ----
 include/linux/property.h                      | 14 +----
 17 files changed, 61 insertions(+), 103 deletions(-)

-- 
2.47.3

Hi Sakari,

On Wed, Sep 24, 2025 at 9:46 AM Sakari Ailus
<sakari.ailus@linux.intel.com> wrote:
>
> Hello everyone,
>
> Historically the fwnode property API has enumerated only available device
> nodes on OF whereas on ACPI, also nodes that haven't been present in the
> system have been provided. Both OF and ACPI have similar concepts of node
> availbility, on OF it's the "status" property present on device nodes and
> on ACPI the _STA object evaluates to device present, enabled and
> functional bits, of which the present and functional bits are currently
> being used to determine whether to enumerate a device.
>
> Two additional functions, fwnode_get_next_available_child_node() and
> fwnode_for_each_available_child_node(), have been provided to enumerate
> the available nodes only on ACPI, whereas on OF the implementation has
> been the same on the non-available variants. The motivation for providing
> these has very likely been to provide fwnode variants of the similarly
> named functions but the difference isn't justifiable from API consistency
> viewpoint.
>
> This set switches the users away from the "available" fwnode API functions
> and later on removes them, aligning the functionality on all fwnode
> backends.
>
> since v1:
>
> - Move patch "ACPI: property: Make acpi_get_next_subnode() static" as
>   first.
>
> - Add missing parentheses and kernel-doc Return: section in
>   acpi_get_next_present_subnode() documentation and move the Return
>   section: of fwnode_graph_get_endpoint_by_id() to the end of the
>   documentation section (new patch for the latter).
>
> - Use device_get_next_child_node() instead of fwnode_get_next_child_node()
>   in flash LED driver drivers.
>
> - Rework iterating port nodes in acpi_graph_get_next_endpoint() as
>   suggested by Andy (new patch).

I think that you really have four series here, or rather two series, a
collection of patches depending on them, and a follow-up cleanup.

> Sakari Ailus (16):
>   ACPI: property: Make acpi_get_next_subnode() static
>   ACPI: property: Use ACPI functions in acpi_graph_get_next_endpoint()
>     only
>   ACPI: property: Rework acpi_graph_get_next_endpoint()
>   ACPI: property: Return present device nodes only on fwnode interface

So the above is one series, focused on ACPI property changes.

They can go in via ACPI as soon as everyone is happy with them.  I
think I can push them for 6.18 if that helps to process the other
patches.

>   property: Move Return: section of fwnode_graph_get_endpoint_by_id()
>     down
>   property: Drop DEVICE_DISABLED flag in
>     fwnode_graph_get_endpoint_by_id()
>   property: Drop DEVICE_DISABLED flag in
>     fwnode_graph_get_endpoint_count()

The above patches are another series that doesn't depend on the first
one AFAICS and can go in via driver core.

>   property: Document that fwnode API returns available nodes
>   driver core: Use fwnode_for_each_child_node() instead
>   net: lan966x: Use fwnode_for_each_child_node() instead
>   Input: touch-overlay - Use fwnode_for_each_child_node() instead
>   media: thp7312: Use fwnode_for_each_child_node() instead
>   leds: Use fwnode_for_each_child_node() instead
>   leds: Use fwnode_get_next_child_node() instead

The above can go in via respective subsystem trees when the ACPI
property series gets in (I'm not sure if/how they depend on the second
series).

And the following one is a follow-up cleanup getting rid of code that
would be redundant going forward.

>   property: Drop functions operating on "available" child nodes
>   spi: cadence: Remove explicit device node availability check

Does the spi change depend on the previous patch?

Hi Rafael,

On Wed, Sep 24, 2025 at 12:52:12PM +0200, Rafael J. Wysocki wrote:
> Hi Sakari,
> 
> On Wed, Sep 24, 2025 at 9:46 AM Sakari Ailus
> <sakari.ailus@linux.intel.com> wrote:
> >
> > Hello everyone,
> >
> > Historically the fwnode property API has enumerated only available device
> > nodes on OF whereas on ACPI, also nodes that haven't been present in the
> > system have been provided. Both OF and ACPI have similar concepts of node
> > availbility, on OF it's the "status" property present on device nodes and
> > on ACPI the _STA object evaluates to device present, enabled and
> > functional bits, of which the present and functional bits are currently
> > being used to determine whether to enumerate a device.
> >
> > Two additional functions, fwnode_get_next_available_child_node() and
> > fwnode_for_each_available_child_node(), have been provided to enumerate
> > the available nodes only on ACPI, whereas on OF the implementation has
> > been the same on the non-available variants. The motivation for providing
> > these has very likely been to provide fwnode variants of the similarly
> > named functions but the difference isn't justifiable from API consistency
> > viewpoint.
> >
> > This set switches the users away from the "available" fwnode API functions
> > and later on removes them, aligning the functionality on all fwnode
> > backends.
> >
> > since v1:
> >
> > - Move patch "ACPI: property: Make acpi_get_next_subnode() static" as
> >   first.
> >
> > - Add missing parentheses and kernel-doc Return: section in
> >   acpi_get_next_present_subnode() documentation and move the Return
> >   section: of fwnode_graph_get_endpoint_by_id() to the end of the
> >   documentation section (new patch for the latter).
> >
> > - Use device_get_next_child_node() instead of fwnode_get_next_child_node()
> >   in flash LED driver drivers.
> >
> > - Rework iterating port nodes in acpi_graph_get_next_endpoint() as
> >   suggested by Andy (new patch).
> 
> I think that you really have four series here, or rather two series, a
> collection of patches depending on them, and a follow-up cleanup.
> 
> > Sakari Ailus (16):
> >   ACPI: property: Make acpi_get_next_subnode() static
> >   ACPI: property: Use ACPI functions in acpi_graph_get_next_endpoint()
> >     only
> >   ACPI: property: Rework acpi_graph_get_next_endpoint()
> >   ACPI: property: Return present device nodes only on fwnode interface
> 
> So the above is one series, focused on ACPI property changes.
> 
> They can go in via ACPI as soon as everyone is happy with them.  I
> think I can push them for 6.18 if that helps to process the other
> patches.

If it's an option, that would be nice. But see below.

> 
> >   property: Move Return: section of fwnode_graph_get_endpoint_by_id()
> >     down
> >   property: Drop DEVICE_DISABLED flag in
> >     fwnode_graph_get_endpoint_by_id()
> >   property: Drop DEVICE_DISABLED flag in
> >     fwnode_graph_get_endpoint_count()
> 
> The above patches are another series that doesn't depend on the first
> one AFAICS and can go in via driver core.

Agreed.

> 
> >   property: Document that fwnode API returns available nodes
> >   driver core: Use fwnode_for_each_child_node() instead
> >   net: lan966x: Use fwnode_for_each_child_node() instead
> >   Input: touch-overlay - Use fwnode_for_each_child_node() instead
> >   media: thp7312: Use fwnode_for_each_child_node() instead
> >   leds: Use fwnode_for_each_child_node() instead
> >   leds: Use fwnode_get_next_child_node() instead
> 
> The above can go in via respective subsystem trees when the ACPI
> property series gets in (I'm not sure if/how they depend on the second
> series).
> 
> And the following one is a follow-up cleanup getting rid of code that
> would be redundant going forward.
> 
> >   property: Drop functions operating on "available" child nodes
> >   spi: cadence: Remove explicit device node availability check
> 
> Does the spi change depend on the previous patch?

There's really only one dependency, apart from the direct dependency of
fwnode_get_next_available_child_node() /
fwnode_for_each_available_child_node() definitions removed in the second
last patch: fwnode_get_next_child_node() and fwnode_for_each_child_node()
may still return non-available nodes before the last of the ACPI patches in
the set. So if the ACPI patches aren't merged but the rest are,
non-available nodes could be returned.

How about:

1. Merge the ACPI patches to 6.18.

2. Merge the rest, apart from the second last patch, for 6.19.

3. Once everything else is in, merge the last patch. Could wait for 6.20.

Perhaps I should split the series in three sets?

I'll send an update on the ACPI patches soon, to address a comment related
to them.

-- 
Kind regards,

Sakari Ailus

Hi Sakari,

On Fri, Sep 26, 2025 at 1:48 PM Sakari Ailus
<sakari.ailus@linux.intel.com> wrote:
>
> Hi Rafael,
>
> On Wed, Sep 24, 2025 at 12:52:12PM +0200, Rafael J. Wysocki wrote:
> > Hi Sakari,
> >
> > On Wed, Sep 24, 2025 at 9:46 AM Sakari Ailus
> > <sakari.ailus@linux.intel.com> wrote:
> > >
> > > Hello everyone,
> > >
> > > Historically the fwnode property API has enumerated only available device
> > > nodes on OF whereas on ACPI, also nodes that haven't been present in the
> > > system have been provided. Both OF and ACPI have similar concepts of node
> > > availbility, on OF it's the "status" property present on device nodes and
> > > on ACPI the _STA object evaluates to device present, enabled and
> > > functional bits, of which the present and functional bits are currently
> > > being used to determine whether to enumerate a device.
> > >
> > > Two additional functions, fwnode_get_next_available_child_node() and
> > > fwnode_for_each_available_child_node(), have been provided to enumerate
> > > the available nodes only on ACPI, whereas on OF the implementation has
> > > been the same on the non-available variants. The motivation for providing
> > > these has very likely been to provide fwnode variants of the similarly
> > > named functions but the difference isn't justifiable from API consistency
> > > viewpoint.
> > >
> > > This set switches the users away from the "available" fwnode API functions
> > > and later on removes them, aligning the functionality on all fwnode
> > > backends.
> > >
> > > since v1:
> > >
> > > - Move patch "ACPI: property: Make acpi_get_next_subnode() static" as
> > >   first.
> > >
> > > - Add missing parentheses and kernel-doc Return: section in
> > >   acpi_get_next_present_subnode() documentation and move the Return
> > >   section: of fwnode_graph_get_endpoint_by_id() to the end of the
> > >   documentation section (new patch for the latter).
> > >
> > > - Use device_get_next_child_node() instead of fwnode_get_next_child_node()
> > >   in flash LED driver drivers.
> > >
> > > - Rework iterating port nodes in acpi_graph_get_next_endpoint() as
> > >   suggested by Andy (new patch).
> >
> > I think that you really have four series here, or rather two series, a
> > collection of patches depending on them, and a follow-up cleanup.
> >
> > > Sakari Ailus (16):
> > >   ACPI: property: Make acpi_get_next_subnode() static
> > >   ACPI: property: Use ACPI functions in acpi_graph_get_next_endpoint()
> > >     only
> > >   ACPI: property: Rework acpi_graph_get_next_endpoint()
> > >   ACPI: property: Return present device nodes only on fwnode interface
> >
> > So the above is one series, focused on ACPI property changes.
> >
> > They can go in via ACPI as soon as everyone is happy with them.  I
> > think I can push them for 6.18 if that helps to process the other
> > patches.
>
> If it's an option, that would be nice. But see below.
>
> >
> > >   property: Move Return: section of fwnode_graph_get_endpoint_by_id()
> > >     down
> > >   property: Drop DEVICE_DISABLED flag in
> > >     fwnode_graph_get_endpoint_by_id()
> > >   property: Drop DEVICE_DISABLED flag in
> > >     fwnode_graph_get_endpoint_count()
> >
> > The above patches are another series that doesn't depend on the first
> > one AFAICS and can go in via driver core.
>
> Agreed.
>
> >
> > >   property: Document that fwnode API returns available nodes
> > >   driver core: Use fwnode_for_each_child_node() instead
> > >   net: lan966x: Use fwnode_for_each_child_node() instead
> > >   Input: touch-overlay - Use fwnode_for_each_child_node() instead
> > >   media: thp7312: Use fwnode_for_each_child_node() instead
> > >   leds: Use fwnode_for_each_child_node() instead
> > >   leds: Use fwnode_get_next_child_node() instead
> >
> > The above can go in via respective subsystem trees when the ACPI
> > property series gets in (I'm not sure if/how they depend on the second
> > series).
> >
> > And the following one is a follow-up cleanup getting rid of code that
> > would be redundant going forward.
> >
> > >   property: Drop functions operating on "available" child nodes
> > >   spi: cadence: Remove explicit device node availability check
> >
> > Does the spi change depend on the previous patch?
>
> There's really only one dependency, apart from the direct dependency of
> fwnode_get_next_available_child_node() /
> fwnode_for_each_available_child_node() definitions removed in the second
> last patch: fwnode_get_next_child_node() and fwnode_for_each_child_node()
> may still return non-available nodes before the last of the ACPI patches in
> the set. So if the ACPI patches aren't merged but the rest are,
> non-available nodes could be returned.
>
> How about:
>
> 1. Merge the ACPI patches to 6.18.
>
> 2. Merge the rest, apart from the second last patch, for 6.19.
>
> 3. Once everything else is in, merge the last patch. Could wait for 6.20.

Sounds good.

> Perhaps I should split the series in three sets?

That would help I think.

> I'll send an update on the ACPI patches soon, to address a comment related
> to them.

OK

Thanks!