linux-kernel - Re: [PATCH v4 1/2] device property: Add scoped fwnode child node iterators

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: <aLlDJETaWTjiSP0L@kekkonen.localdomain>
Date: Thu, 4 Sep 2025 10:43:32 +0300
From: Sakari Ailus <sakari.ailus@...ux.intel.com>
To: Danilo Krummrich <dakr@...nel.org>
Cc: Jean-François Lessard <jefflessard3@...il.com>,
	Wolfram Sang <wsa+renesas@...g-engineering.com>,
	Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
	Daniel Scally <djrscally@...il.com>,
	Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"Rafael J. Wysocki" <rafael@...nel.org>,
	Javier Carrasco <javier.carrasco.cruz@...il.com>,
	linux-i2c@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-acpi@...r.kernel.org
Subject: Re: [PATCH v4 1/2] device property: Add scoped fwnode child node
 iterators

Hi Danilo,

On Thu, Sep 04, 2025 at 09:03:44AM +0200, Danilo Krummrich wrote:
> On Thu Sep 4, 2025 at 7:56 AM CEST, Sakari Ailus wrote:
> > Hi Danilo,
> >
> > On Wed, Sep 03, 2025 at 07:22:29PM +0200, Danilo Krummrich wrote:
> >> (Cc: Javier)
> >> 
> >> On Wed Sep 3, 2025 at 3:18 PM CEST, Sakari Ailus wrote:
> >> > Do we really need the available variant?
> >> >
> >> > Please see
> >> > <URL:https://lore.kernel.org/linux-acpi/Zwj12J5bTNUEnxA0@kekkonen.localdomain/>.
> >> >
> >> > I'll post a patch to remove fwnode_get_next_available_child_node(), too.
> >> 
> >> Either I'm missing something substantial or the link does indeed not provide an
> >> obvious justification of why you want to send a patch to remove
> >> fwnode_get_next_available_child_node().
> >> 
> >> Do you mean to say that all fwnode backends always return true for
> >> device_is_available() and hence the fwnode API should not make this distinction?
> >> 
> >> I.e. are you referring to the fact that of_fwnode_get_next_child_node() always
> >> calls of_get_next_available_child() and swnode has no device_is_available()
> >> callback and hence is always available? What about ACPI?
> >
> > On ACPI there's no such concept on ACPI data nodes so all data nodes are
> > considered to be available. So effectively the fwnode_*available*() is
> > always the same as the variant without _available().
> 
> What about acpi_fwnode_device_is_available()? Is it guaranteed to always
> evaluate to true?

acpi_fwnode_device_is_available() is different as it works on ACPI device
nodes having availability information.

> 
> If so, to you plan to remove device_is_available() from struct
> fwnode_operations and fixup all users of fwnode_get_next_available_child_node()
> and fwnode_for_each_available_child_node() as well?

The device_is_available() callback needs to stay; it has valid uses
elsewhere.

Technically it is possible that fwnode_*child_node() functions could return
device nodes that aren't available, but it is unlikely any caller would
want to enumerate device nodes this way. Even so, I think it'd be the best
to add an explicit availability check on ACPI side as well so only
available nodes would be returned.

The fact that none of the drivers using the two available variants acting
on child nodes had ACPI ID table suggests that the use of the variants was
motivated solely to use a function named similarly to the OF version.

-- 
Kind regards,

Sakari Ailus