From: Luca Ceresoli <luca.ceresoli@bootlin.com>
To: Sean Anderson <sean.anderson@seco.com>,
Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Michael Turquette <mturquette@baylibre.com>,
Stephen Boyd <sboyd@kernel.org>, Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Marek Vasut <marek.vasut@gmail.com>,
devicetree@vger.kernel.org, linux-clk@vger.kernel.org,
linux-reneas-soc@vger.kernel.org
Subject: Re: [PATCH] dt-bindings: clk: vc5: Make SD/OE pin configuration properties not required
Date: Tue, 24 Jan 2023 09:12:36 +0100 [thread overview]
Message-ID: <20230124091236.1bf8c6da@booty> (raw)
In-Reply-To: <5da02a9b-3d42-a26f-0d18-29a6b5b181e5@seco.com>
Hi Sean, Geert,
On Thu, 19 Jan 2023 14:27:43 -0500
Sean Anderson <sean.anderson@seco.com> wrote:
> On 1/11/23 10:55, Geert Uytterhoeven wrote:
> > "make dtbs_check":
> >
> > arch/arm64/boot/dts/renesas/r8a77951-salvator-xs.dtb: clock-generator@6a: 'idt,shutdown' is a required property
> > From schema: Documentation/devicetree/bindings/clock/idt,versaclock5.yaml
> > arch/arm64/boot/dts/renesas/r8a77951-salvator-xs.dtb: clock-generator@6a: 'idt,output-enable-active' is a required property
> > From schema: Documentation/devicetree/bindings/clock/idt,versaclock5.yaml
> >
> > Versaclock 5 clock generators can have their configuration stored in
> > One-Time Programmable (OTP) memory. Hence there is no need to specify
> > DT properties for manual configuration if the OTP has been programmed
> > before. Likewise, the Linux driver does not touch the SD/OE bits if the
> > corresponding properties are not specified, cfr. commit d83e561d43bc71e5
> > ("clk: vc5: Add properties for configuring SD/OE behavior").
> >
> > Reflect this in the bindings by making the "idt,shutdown" and
> > "idt,output-enable-active" properties not required, just like the
> > various "idt,*" properties in the per-output child nodes.
>
> IMO we should set this stuff explicitly.
I took a moment to think better about this and I think I get your point
Sean in preferring that the hardware is described in detail.
However I'm still leaning towards approving Geert's proposal.
I'm based on the principle that DT is there to describe the aspects of
the hardware that the software needs _and_ it is unable to discover by
itself.
Based on that, does the software need to know SD/OR configuration? If
they are already written in the OTP then it doesn't. Also if the chip
default is the use that is implemented on the board, it also doesn't
(like lots of optional properties, especially when in most cases a
given chip is used in the default configuration but not always).
To some extent, writing settings in an OTP is similar to producing a
different chip where these values are hard-coded and not configured.
I'm wondering whether Geert has a practical example of a situation
where it is better to have these properties optional.
Best regards.
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
next prev parent reply other threads:[~2023-01-24 8:14 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-11 15:55 [PATCH] dt-bindings: clk: vc5: Make SD/OE pin configuration properties not required Geert Uytterhoeven
2023-01-12 8:43 ` Krzysztof Kozlowski
2023-01-12 10:57 ` Luca Ceresoli
2023-01-19 19:27 ` Sean Anderson
2023-01-24 8:12 ` Luca Ceresoli [this message]
2023-01-24 8:28 ` Geert Uytterhoeven
2023-01-24 16:23 ` Sean Anderson
2023-03-20 21:27 ` Stephen Boyd
2023-03-22 8:39 ` Luca Ceresoli
2024-09-10 22:13 ` Rob Herring
2024-09-13 15:07 ` Luca Ceresoli
2024-09-13 16:41 ` Sean Anderson
2024-09-13 19:45 ` Rob Herring
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=20230124091236.1bf8c6da@booty \
--to=luca.ceresoli@bootlin.com \
--cc=devicetree@vger.kernel.org \
--cc=geert+renesas@glider.be \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-reneas-soc@vger.kernel.org \
--cc=marek.vasut@gmail.com \
--cc=mturquette@baylibre.com \
--cc=robh+dt@kernel.org \
--cc=sboyd@kernel.org \
--cc=sean.anderson@seco.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;
as well as URLs for NNTP newsgroup(s).