From: Luca Ceresoli <luca.ceresoli@bootlin.com>
To: Rob Herring <robh+dt@kernel.org>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Sean Anderson <sean.anderson@seco.com>
Cc: Stephen Boyd <sboyd@kernel.org>,
Michael Turquette <mturquette@baylibre.com>,
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: Fri, 13 Sep 2024 17:07:01 +0200 [thread overview]
Message-ID: <20240913170701.156d8e82@booty> (raw)
In-Reply-To: <CAL_JsqKj6A=GvgaZCd9jiF71YPGuQSKJ9Ob6erHT45q8vRR13w@mail.gmail.com>
Hello Sean, Geert,
On Tue, 10 Sep 2024 17:13:55 -0500
Rob Herring <robh+dt@kernel.org> wrote:
> On Wed, Mar 22, 2023 at 3:39 AM Luca Ceresoli <luca.ceresoli@bootlin.com> wrote:
> >
> > Hello Stephen,
> >
> > On Mon, 20 Mar 2023 14:27:56 -0700
> > Stephen Boyd <sboyd@kernel.org> wrote:
> >
> > > Quoting Sean Anderson (2023-01-24 08:23:45)
> > > > On 1/24/23 03:28, Geert Uytterhoeven wrote:
> > > > > Hi Luca,
> > > > >
> > > > > On Tue, Jan 24, 2023 at 9:12 AM Luca Ceresoli <luca.ceresoli@bootlin.com> wrote:
> > > > >> 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:
> > > > >
> > > > >> I'm wondering whether Geert has a practical example of a situation
> > > > >> where it is better to have these properties optional.
> > > > >
> > > > > My issue was that these properties were introduced long after the
> > > > > initial bindings, hence pre-existing DTS does not have them.
> > > > > Yes, we can add them, but then we have to read out the OTP-programmed
> > > > > settings first. If that's the way to go, I can look into that, though...
> > > >
> > > > FWIW I think there's no need to update existing bindings which don't
> > > > have this property. The required aspect is mainly a reminder for new
> > > > device trees.
> > > >
> > >
> > > Is there any resolution on this thread? I'm dropping this patch from my
> > > queue.
> >
> > IIRC Geert kind of accepted the idea that these properties should stay
> > required. Which is a bit annoying but it's the safest option, so unless
> > there are new complaints with solid use cases for making them optionalm,
> > I think it's OK to drop the patch.
>
> The warnings related to this are now at the top of the list (by number
> of occurrences):
>
> 50 clock-generator@6a: 'idt,shutdown' is a required property
> 50 clock-generator@6a: 'idt,output-enable-active' is a required property
>
> IMO, if these properties haven't been needed for years, then they
> obviously aren't really required.
I think Rob's point adds to Geert's observation that there are other
"idt,*" properties in the output nodes that may also be important to
have correctly set, and are optional.
So, Sean, I understand when you state it's safer to have these set.
However this is valid for lots of other optional properties in any
binding. Optional properties _can_ be set if that's important, just
it's not mandatory to set them in all cases.
As a matter of fact, we have been having for a long time some in-tree
device trees which don't set these properties, which I believe implies
it's OK for those cases to not set them, and to let them be set for the
device trees where it is important.
Finally, there is a maintenance/legacy issue: if we wanted to keep these
properties optional, who would chase all the boards defined in existing
device trees to discover the correct values?
Bottom line, my Reviewed-by tag is still valid.
What is your opinion given these last few discussion point Sean?
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
next prev parent reply other threads:[~2024-09-13 15:07 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
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 [this message]
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=20240913170701.156d8e82@booty \
--to=luca.ceresoli@bootlin.com \
--cc=devicetree@vger.kernel.org \
--cc=geert@linux-m68k.org \
--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 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.