Re: [PATCH v2 00/16] Align availability checks on fwnode child node enumeration

Rafael J. Wysocki
2025-09-26T12:52:29Z

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!