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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJZ5v0hSy9zQd6cP9B4QPSZi-6ughmkW=VoEBV-0MbUr2xcaAQ@mail.gmail.com>
Date: Wed, 24 Sep 2025 12:52:12 +0200
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Sakari Ailus <sakari.ailus@...ux.intel.com>
Cc: linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-input@...r.kernel.org, linux-leds@...r.kernel.org, 
	linux-media@...r.kernel.org, netdev@...r.kernel.org, 
	linux-spi@...r.kernel.org, "Rafael J. Wysocki" <rafael@...nel.org>, Len Brown <lenb@...nel.org>, 
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Danilo Krummrich <dakr@...nel.org>, 
	Andy Shevchenko <andriy.shevchenko@...ux.intel.com>, Daniel Scally <djrscally@...il.com>, 
	Heikki Krogerus <heikki.krogerus@...ux.intel.com>, 
	Javier Carrasco <javier.carrasco@...fvision.net>, 
	Dmitry Torokhov <dmitry.torokhov@...il.com>, Lee Jones <lee@...nel.org>, 
	Pavel Machek <pavel@...nel.org>, Matthias Fend <matthias.fend@...end.at>, 
	Chanwoo Choi <cw00.choi@...sung.com>, Krzysztof Kozlowski <krzk@...nel.org>, 
	Laurent Pinchart <laurent.pinchart@...asonboard.com>, 
	Paul Elder <paul.elder@...asonboard.com>, Mauro Carvalho Chehab <mchehab@...nel.org>, 
	Horatiu Vultur <horatiu.vultur@...rochip.com>, UNGLinuxDriver@...rochip.com, 
	Andrew Lunn <andrew+netdev@...n.ch>, "David S. Miller" <davem@...emloft.net>, 
	Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, 
	Mark Brown <broonie@...nel.org>, Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...nel.org>, 
	Jonathan Cameron <Jonathan.Cameron@...wei.com>
Subject: Re: [PATCH v2 00/16] Align availability checks on fwnode child node enumeration

Hi Sakari,

On Wed, Sep 24, 2025 at 9:46 AM Sakari Ailus
<sakari.ailus@...ux.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?