All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matti Vaittinen <mazziesaccount@gmail.com>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Sakari Ailus <sakari.ailus@linux.intel.com>
Cc: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>,
	Paul Elder <paul.elder@ideasonboard.com>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	linux-media@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] media: i2c: thp7312: use fwnode_for_each_child_node()
Date: Tue, 8 Apr 2025 14:40:05 +0300	[thread overview]
Message-ID: <a02fca0e-bb67-4fe6-9ba4-24c82a4bbcc1@gmail.com> (raw)
In-Reply-To: <20250408111613.GC31475@pendragon.ideasonboard.com>

On 08/04/2025 14:16, Laurent Pinchart wrote:
> On Tue, Apr 08, 2025 at 11:08:10AM +0000, Sakari Ailus wrote:
>> Moi,
>>
>> On Tue, Apr 08, 2025 at 01:42:12PM +0300, Matti Vaittinen wrote:
>>> On 08/04/2025 13:36, Sakari Ailus wrote:
>>>> Hei Laurent, Matti,
>>>>
>>>> On Tue, Apr 08, 2025 at 01:26:42PM +0300, Matti Vaittinen wrote:
>>>>> On 08/04/2025 13:12, Laurent Pinchart wrote:
>>>>>> Hi Sakari,
>>>>>>
>>>>>> On Tue, Apr 08, 2025 at 08:48:45AM +0000, Sakari Ailus wrote:
>>>>>>> On Fri, Mar 21, 2025 at 12:41:00PM +0200, Laurent Pinchart wrote:
>>>>>>>> On Fri, Mar 21, 2025 at 10:58:27AM +0200, Matti Vaittinen wrote:
>>>>>>>>> When fwnode_for_each_available_child_node() is used on the device-tree
>>>>>>>>> backed systems, it renders to same operation as the
>>>>>>>>> fwnode_for_each_child_node(), because the fwnode_for_each_child_node()
>>>>>>>>> does only iterate through those device-tree nodes which are available.
>>>>>>>>
>>>>>>>> This makes me wonder why the OF backend implements
>>>>>>>> fwnode_for_each_child_node() as fwnode_for_each_available_child_node().
>>>>>>>> Is that on purpose, or is it a bug ?
>>>>>>>
>>>>>>> I discussed this with Rafael and he didn't recall why the original
>>>>>>> implementation was like that. The general direction later on has been not
>>>>>>> to present unavailable nodes over the fwnode interface.
>>>>>>>
>>>>>>> So I'd say:
>>>>>>>
>>>>>>> Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
>>>>>>>
>>>>>>> We should also change the documentation of the fwnode API accordingly.
>>>>>>
>>>>>> Does that also mean that the fwnode_for_each_available_child_node()
>>>>>> function will be dropped ? It's used by few drivers (5 in addition to
>>>>>> the thp7312 driver, plus 3 call sites in drivers/base/core.c), so a
>>>>>> patch series to drop it should be easy.
>>>>>>
>>>>>
>>>>> I assume the fwnode_for_each_available_child_node() still makes sense for
>>>>> ACPI backed users, no?
>>>>
>>>> Not really (see my earlier explanation in
>>>> <Z9mQPJwnKAkPHriT@kekkonen.localdomain>).
>>>
>>> I capture that the _named_ available nodes don't have value as ACPI names
>>> aren't really what is expected by the _named_ callers. What I didn't pick is
>>> that the fwnode_for_each_available_child_node() - which should iterate all
>>> available child nodes ignoring the name - wouldn't be useful.
>>
>> Fair enough. I don't think we need to support enumerating unavailable ACPI
>> device nodes in this API. I'd indeed change the behaviour so that only
>> available nodes are enumerated. I can post a patch for that.
> 
> Unless there's a specific reason against it that I wouldn't be aware of,
> I would also very much favour merging the fwnode_for_each_child_node()
> and fwnode_for_each_available_child_node() functions into a single one
> that only enumerates available nodes, with a consistent behaviour across
> all backend. Having fwnode_for_each_child_node() return unavailable ACPI
> nodes but not unavailable DT nodes would be really confusing.

Absolutely no objections.

Yours,
	-- Matti

      reply	other threads:[~2025-04-08 11:40 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-21  8:58 [PATCH v2] media: i2c: thp7312: use fwnode_for_each_child_node() Matti Vaittinen
2025-03-21 10:41 ` Laurent Pinchart
2025-03-24  9:28   ` Sakari Ailus
2025-04-08  8:48   ` Sakari Ailus
2025-04-08 10:12     ` Laurent Pinchart
2025-04-08 10:26       ` Matti Vaittinen
2025-04-08 10:36         ` Sakari Ailus
2025-04-08 10:42           ` Matti Vaittinen
2025-04-08 11:08             ` Sakari Ailus
2025-04-08 11:16               ` Laurent Pinchart
2025-04-08 11:40                 ` Matti Vaittinen [this message]

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=a02fca0e-bb67-4fe6-9ba4-24c82a4bbcc1@gmail.com \
    --to=mazziesaccount@gmail.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=matti.vaittinen@fi.rohmeurope.com \
    --cc=mchehab@kernel.org \
    --cc=paul.elder@ideasonboard.com \
    --cc=sakari.ailus@linux.intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.