linux-kernel - [RFC PATCH] arm64: dts: mt8183: Add arm,no-tick-in-suspend

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: <20200921121420.RFC.1.I30d6887e950575eb1fd92ee56ab5d50ff64c97f3@changeid>
Date:   Mon, 21 Sep 2020 12:14:24 +0800
From:   Nicolas Boichat <drinkcat@...omium.org>
To:     Matthias Brugger <matthias.bgg@...il.com>
Cc:     Nicolas Boichat <drinkcat@...omium.org>,
        Feng Tang <feng.tang@...el.com>,
        John Stultz <john.stultz@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Stephen Boyd <sboyd@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org, linux-mediatek@...ts.infradead.org
Subject: [RFC PATCH] arm64: dts: mt8183: Add arm,no-tick-in-suspend

The armv8-timer on MT8183 (kukui family) actually ticks in suspend,
but its precision is so low (measured 400+ ppm -- 35 seconds/day)
that it's actually better to use a fallback option (RTC).

Signed-off-by: Nicolas Boichat <drinkcat@...omium.org>
---
We asked MTK if there is anything that can be done to make the
archtimer more precise in suspend, but that does not seem to
be possible.

Ideally we'd like a arm,tick-in-suspend-but-use-something-else-if-possible
property, but the rating in [1] cannot be used, as the RTC
fallback is handled separately [2].

I don't know if this kind of issues happened in the past, one
possible compromise is to add the option to kukui board only,
since we _know_ there is an RTC there (which, technically, may
not be the case on every single MT8183 platform).

A more complete solution would involved quite a bit of
refactoring in the timekeeping/rtc framework.

[1] https://elixir.bootlin.com/linux/v5.8/source/kernel/time/clocksource.c#L486
[2] https://elixir.bootlin.com/linux/v5.8/source/kernel/time/timekeeping.c#L1693

 arch/arm64/boot/dts/mediatek/mt8183.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index f9b60e3d085c..ebcb2309017d 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -219,6 +219,7 @@ timer {
 			     <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW 0>,
 			     <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW 0>,
 			     <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW 0>;
+		arm,no-tick-in-suspend;
 	};

 	soc {
-- 
2.28.0.681.g6f77f65b4e-goog