netdev - Re: [PATCH v2 1/5] dt-bindings: net: can: renesas,rcar-canfd: Document RZ/G2L SoC

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>] [<thread-prev] [day] [month] [year] [list]

Date:   Tue, 20 Jul 2021 18:33:41 +0200
From:   Philipp Zabel <p.zabel@...gutronix.de>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>,
        "Lad, Prabhakar" <prabhakar.csengg@...il.com>
Cc:     Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>,
        Rob Herring <robh+dt@...nel.org>,
        Fabrizio Castro <fabrizio.castro.jz@...esas.com>,
        Wolfgang Grandegger <wg@...ndegger.com>,
        Marc Kleine-Budde <mkl@...gutronix.de>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...nel.org>, linux-can@...r.kernel.org,
        netdev <netdev@...r.kernel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        linux-clk <linux-clk@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Linux-Renesas <linux-renesas-soc@...r.kernel.org>,
        Biju Das <biju.das.jz@...renesas.com>
Subject: Re: [PATCH v2 1/5] dt-bindings: net: can: renesas,rcar-canfd:
 Document RZ/G2L SoC

Hi Geert,

On Tue, 2021-07-20 at 17:11 +0200, Geert Uytterhoeven wrote:
[...]
> I wouldn't bother with reset-names on R-Car, as there is only a
> single reset.
> 
> BTW, does there exist a generally-accepted reset-equivalent of "fck"
> ("Functional ClocK")?

Not really. There is "rst", which seems to be slightly more popular than
"reset". Some bindings use "core" to differentiate between the
functional reset and peripheral resets like bus or phy resets.

Ideally the reset-names would match the names of the reset inputs in the
IP core documentation (not the global names of the reset signals in the
SoC documentation). But more often than not they are not known.

regards
Philipp