Message-ID: <CAJZ5v0gQ9vnT+Z8zryEausp-2xX7HocoBgwmiptxg7BGiU9C8g@mail.gmail.com>
Date: Fri, 26 Sep 2025 14:52:17 +0200
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Sakari Ailus <sakari.ailus@...ux.intel.com>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>, 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, 
	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 Fri, Sep 26, 2025 at 1:48 PM Sakari Ailus
<sakari.ailus@...ux.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@...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.
>
> 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!

Powered by blists - more mailing lists