From: Marc Zyngier <maz@kernel.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Phil Edworthy <phil.edworthy@renesas.com>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Biju Das <biju.das.jz@bp.renesas.com>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
Thomas Gleixner <tglx@linutronix.de>,
Mark Rutland <mark.rutland@arm.com>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@vger.kernel.org>,
Linux-Renesas <linux-renesas-soc@vger.kernel.org>
Subject: Re: [PATCH v3 04/12] dt-bindings: timer: arm,arch_timer: Add optional clock and reset
Date: Tue, 03 May 2022 16:56:47 +0100 [thread overview]
Message-ID: <87bkwe8v9c.wl-maz@kernel.org> (raw)
In-Reply-To: <CAMuHMdU4j=Uaz5fAODFrPud0i40TdHUo6bYq0YpdnUzWaM3-Og@mail.gmail.com>
Geert,
On Tue, 03 May 2022 15:22:35 +0100,
Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Marc,
>
> On Tue, May 3, 2022 at 3:12 PM Marc Zyngier <maz@kernel.org> wrote:
> > On 2022-05-03 12:55, Phil Edworthy wrote:
> > > Some SoCs use a gated clock for the timer and the means to reset the
> > > timer.
> > > Hence add these as optional.
> >
> > The architecture is crystal clear on the subject: the counter
> > is in an always-on domain. Why should this be visible to SW?
> > Also, reseting the counter breaks the guaranteed monotonicity
> > we rely on.
>
> The DT bindings do state:
>
> always-on:
> type: boolean
> description: If present, the timer is powered through an always-on power
> domain, therefore it never loses context.
>
> and (surprisingly?) the absence of this property seems to be the
> norm...
*timer* is the key word. And counter != timer. What your HW has is a
gate on the *counter* which is illegal if observable from NS SW.
>
> And:
>
> arm,no-tick-in-suspend:
> type: boolean
> description: The main counter does not tick when the system is in
> low-power system suspend on some SoCs. This behavior does not match the
> Architecture Reference Manual's specification that the system
> counter "must
> be implemented in an always-on power domain."
>
> So there's already precedent for clocks that can be disabled.
No, this is only the case in *suspend*, as the name of the property
vaguely hints at. And that's a property for a bug. In your case, the
clock can be controlled arbitrarily, which is even worse.
>
> > Worse case, this belongs to the boot firmware, not the kernel,
> > and I don't think this should be described in the DT.
>
> "DT describes hardware, not software policy"?
I'm happy to spread "always-on" properties all over the shop, but
that's not helping. The HW spec says it in bold letters: the counter
is always running, and doesn't jump backward. I can't imagine how
secure SW will behave when you reset its counter... :-/
M.
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2022-05-03 15:56 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-03 11:55 [PATCH v3 00/12] Add new Renesas RZ/V2M SoC and Renesas RZ/V2M EVK support Phil Edworthy
2022-05-03 11:55 ` [PATCH v3 01/12] dt-bindings: serial: renesas,em-uart: Add RZ/V2M clock to access the registers Phil Edworthy
2022-05-04 8:06 ` Geert Uytterhoeven
2022-05-04 8:13 ` Phil Edworthy
2022-05-03 11:55 ` [PATCH v3 02/12] dt-bindings: clock: Add r9a09g011 CPG Clock Definitions Phil Edworthy
2022-05-04 8:43 ` Geert Uytterhoeven
2022-05-03 11:55 ` [PATCH v3 03/12] dt-bindings: clock: renesas,rzg2l: Document RZ/V2M SoC Phil Edworthy
2022-05-04 8:43 ` Geert Uytterhoeven
2022-05-03 11:55 ` [PATCH v3 04/12] dt-bindings: timer: arm,arch_timer: Add optional clock and reset Phil Edworthy
2022-05-03 13:11 ` Mark Rutland
2022-05-04 22:33 ` Rob Herring
2022-05-05 6:42 ` Geert Uytterhoeven
2022-05-03 13:12 ` Marc Zyngier
2022-05-03 14:22 ` Geert Uytterhoeven
2022-05-03 14:55 ` Mark Rutland
2022-05-03 15:56 ` Marc Zyngier [this message]
2022-05-04 9:05 ` Phil Edworthy
2022-05-03 11:55 ` [PATCH v3 11/12] arm64: dts: renesas: Add initial DTSI for RZ/V2M SoC Phil Edworthy
2022-05-04 8:47 ` Geert Uytterhoeven
2022-05-03 11:55 ` [PATCH v3 12/12] arm64: dts: renesas: Add initial device tree for RZ/V2M EVK Phil Edworthy
2022-05-04 8:51 ` Geert Uytterhoeven
2022-05-04 9:00 ` Phil Edworthy
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=87bkwe8v9c.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=biju.das.jz@bp.renesas.com \
--cc=daniel.lezcano@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=geert@linux-m68k.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=phil.edworthy@renesas.com \
--cc=robh+dt@kernel.org \
--cc=tglx@linutronix.de \
/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).