[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <DCJXQ4CUQ88U.ZEEGKWZRCGL6@kernel.org>
Date: Thu, 04 Sep 2025 12:13:53 +0200
From: "Danilo Krummrich" <dakr@...nel.org>
To: "Andy Shevchenko" <andriy.shevchenko@...ux.intel.com>
Cc: "Wolfram Sang" <wsa+renesas@...g-engineering.com>,
Jean-François Lessard <jefflessard3@...il.com>, "Daniel
Scally" <djrscally@...il.com>, "Heikki Krogerus"
<heikki.krogerus@...ux.intel.com>, "Sakari Ailus"
<sakari.ailus@...ux.intel.com>, "Greg Kroah-Hartman"
<gregkh@...uxfoundation.org>, "Rafael J. Wysocki" <rafael@...nel.org>,
<linux-i2c@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<linux-acpi@...r.kernel.org>
Subject: Re: [PATCH v4 0/2] device property: Add scoped fwnode child node
iterators
On Thu Sep 4, 2025 at 11:59 AM CEST, Andy Shevchenko wrote:
> On Thu, Sep 04, 2025 at 11:49:25AM +0200, Wolfram Sang wrote:
>>
>> > It might be good to have an immutable branch for me from i2c core.
>> > Wolfram, can you provide a such if no objections?
>>
>> Sure thing, I can do that. But there is still discussion on patch 1, so
>> I will wait for an outcome there.
>
> But it seems that the discussion can be implemented in a followup?
If Sakari attempts the rework, and we can prove this doesn't regress existing
users, removing fwnode_for_each_available_child_node_scoped() in the context
of the rework again should be trivial.
Given that, I don't see a reason to stall people working with the existing
semantics of the API in the meantime.
So, AFAIC, my ACK is still valid.
Powered by blists - more mailing lists