linux-kernel - About DT binding of reset control

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <CAK7LNAQ29tXAFZaYODFyd4iAx9UhyjhyEtXxk+ZC+yUtXsqMMQ@mail.gmail.com>
Date:   Fri, 6 Dec 2019 17:04:19 +0900
From:   Masahiro Yamada <yamada.masahiro@...ionext.com>
To:     Rob Herring <robh+dt@...nel.org>, DTML <devicetree@...r.kernel.org>
Cc:     Philipp Zabel <p.zabel@...gutronix.de>,
        linux-mtd <linux-mtd@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: About DT binding of reset control

Hello, Rob, DT folks,

I am trying to add the reset control into
the Denali NAND controller driver:
Documentation/devicetree/bindings/mtd/denali-nand.txt
drivers/mtd/nand/raw/denali_dt.c

I'd like to get some advice about the DT binding
before the detailed implementation.

The IP datasheet clearly says
two separate reset lines, like this:

rst_n :           controller core reset
reg_rst_n:     register flip-flop reset

But, in actual SoC integration,
the two reset signals are often tied up together, and
the reset controller only provides 1-bit control.

(The upstream platforms, SoCFPGA, UniPhier,
 both are this case.)

In this case, which is more preferred for the
DT binding?

[1] Define two resets explicitly according to the IP spec

Optional properties:
  reset-names :  contain "nand", "reg"
  resets: phandles to the controller core reset, the register reset

Example:

   nand {
         ....
         reset-names = "nand", "reg";
         resets = <&nand_rst>, <&nand_rst>;
         ...
   };

[2] Allow arbitrary number of reset lines

Optional properties:
     resets: phandle(s) to reset(s)

   The number of reset lines is SoC-dependent.

Examples:

      nand {

               resets = <&nand>;
                ...
       };

I guess [1] is more precise as the hardware specification.
But, DT files will end up with giving the same phandle
to both of the two resets.
I think it is OK, but anyway better to ask
before proceeding.

Thanks.

--
Best Regards
Masahiro Yamada