devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Sean Anderson <sean.anderson@seco.com>
Cc: Luca Ceresoli <luca@lucaceresoli.net>,
	linux-clk <linux-clk@vger.kernel.org>,
	Adam Ford <aford173@gmail.com>, Stephen Boyd <sboyd@kernel.org>,
	Michael Turquette <mturquette@baylibre.com>,
	Rob Herring <robh@kernel.org>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
	<devicetree@vger.kernel.org>
Subject: Re: [PATCH v3 1/2] dt-bindings: clk: vc5: Add properties for configuring the SD/OE pin
Date: Thu, 1 Jul 2021 18:44:03 +0200	[thread overview]
Message-ID: <CAMuHMdUYwEJ8Jauv1vdou_5kyx7WhMan8Zkme55LJixMqPCqKQ@mail.gmail.com> (raw)
In-Reply-To: <af422b9e-8820-5c43-527a-ca1d9ee413f6@seco.com>

Hi Sean,

On Thu, Jul 1, 2021 at 5:52 PM Sean Anderson <sean.anderson@seco.com> wrote:
> On 6/30/21 5:12 AM, Geert Uytterhoeven wrote:
> > On Wed, Jun 30, 2021 at 9:57 AM Luca Ceresoli <luca@lucaceresoli.net> wrote:
> >> On 29/06/21 23:41, Sean Anderson wrote:
> >> > On 6/29/21 5:23 PM, Luca Ceresoli wrote:
> >> >> On 29/06/21 17:47, Sean Anderson wrote:
> >> >>> These properties allow configuring the SD/OE pin as described in the
> >> >>> datasheet.
> >> >>
> >> >> *Many* thanks for addressing this issue so quickly!
> >> >>
> >> >>> Signed-off-by: Sean Anderson <sean.anderson@seco.com>
> >
> >> >>> a/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml
> >> >>> b/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml
> >> >>> index 28675b0b80f1..51f0f78cc3f4 100644
> >> >>> --- a/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml
> >> >>> +++ b/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml
> >> >>> @@ -30,6 +30,22 @@ description: |
> >> >>>      3 -- OUT3
> >> >>>      4 -- OUT4
> >> >>>
> >> >>> +  The idt,(en|dis)able-shutdown and idt,output-enable-active-(high|low)
> >> >>> +  properties control the SH (en_global_shutdown) and SP bits of the
> >> >>> +  Primary Source and Shutdown Register, respectively. Their behavior is
> >> >>> +  summarized by the following table:
> >> >>> +
> >> >>> +  SH SP Output when the SD/OE pin is Low/High
> >> >>> +  == == =====================================
> >> >>> +   0  0 Active/Inactive
> >> >>> +   0  1 Inactive/Active
> >> >>> +   1  0 Active/Shutdown
> >> >>> +   1  1 Inactive/Shutdown
> >> >>> +
> >> >>> +  If no properties related to these bits are specified, then they will
> >> >>> +  be left in their default state. This may be useful if the SH and SP
> >> >>> +  bits are set to a default value using the OTP memory.
> >> >>
> >> >> This paragraph looks more an implementation description than a hardware
> >> >> description.
> >> >
> >> > It of course *is* an implementation description. As Geert found out, it
> >> > is important to keep the defaults if none of these properties are
> >> > specified.
> >>
> >> DT should describe hardware, not implementation. The difference is
> >> subtle at times, but it is important. Other OSes, bootloaders,
> >> firmwares, whatever can have a totally different implementation but use
> >> the same DT.
> >
> > In general, it's best for a driver not to rely on any preprogramming
> > done by e.g. the bootloader before.
>
> This is part of the reason I wanted to add these properties in the first
> place. I'm working on a board where one version has had the OTP
> programmed, and one version has not. But of course, if we set these bits
> in software then I do not have to worry about whether the OTP has set up
> something sane.
>
> >
> > The concept of "One-Time Programming (OTP) bits" adds yet another
> > dimension to the already complicated boot chain of dependencies.
> > But due to the one-time feature I consider that more stable than
> > other firmware, which can be upgraded, causing changed behavior,
> > unlike OTP bits.
> >
> >> Perhaps these properties might be made mandatory later, after upgrading
> >> all DTs (at least those in mainline Linux). and a grace period.
> >
> > Yes, they should be marked as required.
>
> I don't think I can do that without going through all existing users and
> defining these properties for them. Otherwise, dt_bindings_check will
> complain. I believe (but please correct me if I'm wrong) that patches
> are not to introduce new warnings.
>
> However, setting these propreties is not possible for me to do; I would
> need someone familiar with their board to determine how the SD/OE pin is
> used, and what the correct setting is.

Sure, we can only make them required once all in-tree DTS files have been
fixed.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

  reply	other threads:[~2021-07-01 16:44 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-29 15:47 [PATCH v3 1/2] dt-bindings: clk: vc5: Add properties for configuring the SD/OE pin Sean Anderson
2021-06-29 20:29 ` Stephen Boyd
2021-06-29 21:23 ` Luca Ceresoli
2021-06-29 21:41   ` Sean Anderson
2021-06-30  7:57     ` Luca Ceresoli
2021-06-30  9:12       ` Geert Uytterhoeven
2021-07-01 15:51         ` Sean Anderson
2021-07-01 16:44           ` Geert Uytterhoeven [this message]
2021-07-02 14:12             ` Luca Ceresoli

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=CAMuHMdUYwEJ8Jauv1vdou_5kyx7WhMan8Zkme55LJixMqPCqKQ@mail.gmail.com \
    --to=geert@linux-m68k.org \
    --cc=aford173@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=luca@lucaceresoli.net \
    --cc=mturquette@baylibre.com \
    --cc=robh@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).