linux-kernel - Re: [PATCH v1 12/30] dt-bindings: reset: Add starfive,jh7110-reset bindings

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

Date:   Wed, 12 Oct 2022 15:05:04 +0100
From:   Conor Dooley <conor.dooley@...rochip.com>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        Hal Feng <hal.feng@...ux.starfivetech.com>
CC:     Hal Feng <hal.feng@...ux.starfivetech.com>,
        Rob Herring <robh@...nel.org>,
        <linux-riscv@...ts.infradead.org>, <devicetree@...r.kernel.org>,
        <linux-clk@...r.kernel.org>, <linux-gpio@...r.kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Palmer Dabbelt <palmer@...belt.com>,
        Albert Ou <aou@...s.berkeley.edu>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Marc Zyngier <maz@...nel.org>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        Stephen Boyd <sboyd@...nel.org>,
        Michael Turquette <mturquette@...libre.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Emil Renner Berthing <kernel@...il.dk>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v1 12/30] dt-bindings: reset: Add starfive,jh7110-reset
 bindings

Hey Hal Feng,

On Wed, Oct 12, 2022 at 09:33:42AM -0400, Krzysztof Kozlowski wrote:
> >>> These two properties are the key differences among different reset controllers.
> >>
> >> Different as in different compatibles? Please answer the questions..> 
> >>> There are five memory regions for clock and reset in StarFive JH7110 SoC. They
> >>> are "syscrg", "aoncrg", "stgcrg", "ispcrg" and "voutcrg". Each memory region
> >>> has different reset ASSERT/STATUS register offset and different number of reset
> >>> signals. 
> >>
> >> Then these are not exactly the same devices, so using one compatible for
> >> them does not look correct.
> > 
> > One compatible can just be matched by one device? I think this is what
> > confuses me.
> 
> I don't understand the question.

If two SoCs have exactly the same device/peripheral then they _can_ use
the same compatible. If they share some common, viable feature-set then
one can "fall back" to the other depending on what your Venn diagram of
common features looks like. I've not been following this too closely,
but I think what Krzysztof is suggesting is that you have a jh7100 and
a jh7110 compatible. Then in your driver you just "know" that if you
match against jh7110 which values to use for register offsets & vice
versa for a match against the jh7100. There's many examples over the
tree for how to handle this sort of thing rather than including it in
the devicetree.

Maybe Rob and Krzysztof will scream at me for this description, but
devicetree is about how periperhals etc are connected together in the
system not about the internals of a given peripheral.

Following that logic, the devicetree should not contain register offsets
etc that are a known quanitity once you've determined that you are running
on vendor,soc-foo.

Hopefully that helps with your confusion somewhat?
Conor.