[PATCH v1 12/30] dt-bindings: reset: Add starfive,jh7110-reset bindings
Conor Dooley
conor.dooley at microchip.com
Wed Oct 12 07:05:04 PDT 2022
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.
More information about the linux-riscv
mailing list