Thread (58 messages) 58 messages, 8 authors, 2025-10-09

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

From: "Rafael J. Wysocki" <rafael@kernel.org>
Date: 2025-09-24 10:52:26
Also in: linux-acpi, linux-leds, linux-media, linux-spi, lkml, netdev

Hi Sakari,

On Wed, Sep 24, 2025 at 9:46 AM Sakari Ailus
[off-list ref] 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?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help