mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Danilo Krummrich" <dakr@kernel.org>
To: "Sakari Ailus" <sakari.ailus@linux.intel.com>
Cc: "Jean-François Lessard" <jefflessard3@gmail.com>,
	"Wolfram Sang" <wsa+renesas@sang-engineering.com>,
	"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
	"Daniel Scally" <djrscally@gmail.com>,
	"Heikki Krogerus" <heikki.krogerus@linux.intel.com>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	"Javier Carrasco" <javier.carrasco.cruz@gmail.com>,
	linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org
Subject: Re: [PATCH v4 1/2] device property: Add scoped fwnode child node iterators
Date: Thu, 04 Sep 2025 09:03:44 +0200	[thread overview]
Message-ID: <DCJTOIQ4Q0Z5.Q2UE5AQU1X35@kernel.org> (raw)
In-Reply-To: <aLkqE9c9w9m4Axsp@kekkonen.localdomain>

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?

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?

  reply	other threads:[~2025-09-04  7:03 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-02 19:04 [PATCH v4 0/2] " Jean-François Lessard
2025-09-02 19:04 ` [PATCH v4 1/2] " Jean-François Lessard
2025-09-02 19:11   ` Danilo Krummrich
2025-09-03 10:29   ` Andy Shevchenko
2025-09-03 13:18   ` Sakari Ailus
2025-09-03 16:43     ` Jean-François Lessard
2025-09-03 17:22     ` Danilo Krummrich
2025-09-04  5:56       ` Sakari Ailus
2025-09-04  7:03         ` Danilo Krummrich [this message]
2025-09-04  7:43           ` Sakari Ailus
2025-09-04  8:51             ` Danilo Krummrich
2025-09-04 11:54               ` Sakari Ailus
2025-09-04 12:39                 ` Sakari Ailus
2025-09-04 16:14                 ` Danilo Krummrich
2025-09-16 16:18                   ` Sakari Ailus
2025-09-25 20:43   ` Wolfram Sang
2025-09-02 19:04 ` [PATCH v4 2/2] i2c: core: Use fwnode_for_each_child_node_scoped() Jean-François Lessard
2025-09-03 13:19   ` Sakari Ailus
2025-09-25 20:43   ` Wolfram Sang
2025-09-03 10:30 ` [PATCH v4 0/2] device property: Add scoped fwnode child node iterators Andy Shevchenko
2025-09-04  9:49   ` Wolfram Sang
2025-09-04  9:59     ` Andy Shevchenko
2025-09-04 10:13       ` Danilo Krummrich
2025-09-04 10:38         ` Sakari Ailus
2025-09-10 12:53       ` Wolfram Sang
2025-09-12 22:28         ` Wolfram Sang
2025-09-15  6:27           ` Andy Shevchenko
2025-09-25 10:54             ` Wolfram Sang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DCJTOIQ4Q0Z5.Q2UE5AQU1X35@kernel.org \
    --to=dakr@kernel.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=djrscally@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=javier.carrasco.cruz@gmail.com \
    --cc=jefflessard3@gmail.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=sakari.ailus@linux.intel.com \
    --cc=wsa+renesas@sang-engineering.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®