From: Bryan O'Donoghue <bod@kernel.org>
To: Krzysztof Kozlowski <krzk@kernel.org>
Cc: geocausa@gmail.com, Sakari Ailus <sakari.ailus@linux.intel.com>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>, Sergey Lebedev <lsa.uz@pm.me>,
German Pablo Lindo <germanpapulindez@gmail.com>,
linux-media@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] dt-bindings: media: i2c: Add OmniVision OV13858
Date: Sat, 17 Oct 2026 22:28:34 +0100 [thread overview]
Message-ID: <e7c16b26-9525-4a54-8098-20148c8461a9@kernel.org> (raw)
In-Reply-To: <20261017-successful-sturgeon-of-experiment-9d8caa@quoll>
On 17/10/2026 17:57, Krzysztof Kozlowski wrote:
> On Fri, Oct 16, 2026 at 09:49:16PM +0100, Bryan O'Donoghue wrote:
>> On 15/10/2026 22:48, George Neacsu via B4 Relay wrote:
>>> + - clocks
>>> + - avdd-supply
>>> + - dovdd-supply
>>> + - dvdd-supply
>>
>> The clocks, supplies and resets should all be optional as nothing says Linux
>> must control any of those on every system.
>>
>> i.e. you might have a co-processor or CPLD which owns the reset, power-rails
>> and the clock might not come from the SoC.
>
> That would mean that every other binding/device would have them
> optional. What Linux controls or does not, is not really important here
> - these are required in the board design.
>
> Best regards,
> Krzysztof
Yeah I take your point, they should be optional in the driver. Actually
though we don't always know or represent a regulator for example or the
regulator can be on a daughter board - as is common on Laptops.
What is the DT policy for that ? My own understanding was that it is
better to not require all the regulators from the DT description and
leave it up to the individual DTs to describe what can be described.
Should we have a fake regulator - or reuse one ?
OK the LLM tells me that I should have 'regulator-fixed' for that case
always-on, no GPIO, so describing a regulator we know exists but can't
actually control, hmm.
Fair enough, that's the answer.
---
bod
next prev parent reply other threads:[~2026-10-17 21:28 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-15 21:48 [PATCH 0/2] media: ov13858: device tree support for the Surface Pro 11 (Snapdragon) George Neacsu via B4 Relay
2026-10-15 21:48 ` [PATCH 1/2] dt-bindings: media: i2c: Add OmniVision OV13858 George Neacsu via B4 Relay
2026-10-16 20:49 ` Bryan O'Donoghue
2026-10-17 16:57 ` Krzysztof Kozlowski
2026-10-17 21:28 ` Bryan O'Donoghue [this message]
2026-10-17 16:58 ` Krzysztof Kozlowski
2026-10-15 21:48 ` [PATCH 2/2] media: i2c: ov13858: Add device tree support George Neacsu via B4 Relay
2026-10-16 16:06 ` Bryan O'Donoghue
2026-10-16 16:16 ` George Neacsu
2026-10-16 20:43 ` Bryan O'Donoghue
2026-10-16 21:08 ` Sergey Lebedev
2026-10-16 21:48 ` George Neacsu
2026-10-16 22:25 ` George Neacsu
2026-10-16 7:01 ` [PATCH 0/2] media: ov13858: device tree support for the Surface Pro 11 (Snapdragon) Sergey Lebedev
2026-10-16 14:55 ` George Neacsu
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=e7c16b26-9525-4a54-8098-20148c8461a9@kernel.org \
--to=bod@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=geocausa@gmail.com \
--cc=germanpapulindez@gmail.com \
--cc=krzk+dt@kernel.org \
--cc=krzk@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=lsa.uz@pm.me \
--cc=mchehab@kernel.org \
--cc=robh@kernel.org \
--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