From: Matti Vaittinen <mazziesaccount@gmail.com>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>,
Paul Elder <paul.elder@ideasonboard.com>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Sakari Ailus <sakari.ailus@linux.intel.com>,
linux-media@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] media: i2c: thp7312: Don't require node availability
Date: Fri, 21 Mar 2025 08:35:06 +0200 [thread overview]
Message-ID: <ffa5ae6d-a925-41da-9826-4bb376ca0fbe@gmail.com> (raw)
In-Reply-To: <20250320142635.GA14394@pendragon.ideasonboard.com>
Hi dee Ho Laurent,
On 20/03/2025 16:26, Laurent Pinchart wrote:
> Hi Matti,
>
> On Thu, Mar 20, 2025 at 10:35:35AM +0200, Matti Vaittinen wrote:
>> It appears that the concept of available firmware nodes is not really
>> applicable to the scenarios where a specific name is required from a
>> node.
>>
>> As explained[1] by Sakari:
>> "OF only enumerates available nodes via the fwnode API, software nodes
>> don't have the concept but on ACPI I guess you could have a difference
>> in nodes where you have device sub-nodes that aren't available. Still,
>> these ACPI device nodes don't have meaningful names in this context
>> (they're 4-character object names) so you wouldn't use them like this
>> anyway."
>>
>> Use the fwnode_for_each_child_node() instead of the
>> fwnode_for_each_available_child_node() In order to make it clearly
>> visible that the 'availability' of the nodes does not need to be
>> considered here.
>
> Why not ? Node availability is a concept that exists in DT, and this
> driver has only been tested on DT-based systems.
I admit I need to study this then. I just took what Sakari said for
granted, without taking any further look at this.
I mean following quote:
"OF only enumerates available nodes via the fwnode API".
I interpreted it as if, in the dt based systems, the nodes which aren't
available, wouldn't be enumerated and available via the fwnode APIs. If
this is not true, then we probably need to re-re-re-consider also the
need for the fwnode_for_each_available_named_child_node().
> Why can't we keep the
> code as-is ?
If I am mistaken and the 'availability' has a meaning - then we can and
should. If not, then this discussion should serve as a good example why
the code should be changed ;)
I hope Sakari can share his view :)
Yours,
-- Matti
next prev parent reply other threads:[~2025-03-21 6:35 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-20 8:35 [PATCH] media: i2c: thp7312: Don't require node availability Matti Vaittinen
2025-03-20 14:26 ` Laurent Pinchart
2025-03-21 6:35 ` Matti Vaittinen [this message]
2025-03-21 8:29 ` Matti Vaittinen
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=ffa5ae6d-a925-41da-9826-4bb376ca0fbe@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox