Hi Sean, Geert,
On Thu, 19 Jan 2023 14:27:43 -0500
Sean Anderson <sean.anderson@xxxxxxxx> 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
