linux-kernel - Re: [RFC PATCH 00/10] Add persistent clock support

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:   Tue, 15 May 2018 12:27:15 +0200
From:   Daniel Lezcano <daniel.lezcano@...aro.org>
To:     Baolin Wang <baolin.wang@...aro.org>
Cc:     tglx@...utronix.de, john.stultz@...aro.org, arnd@...db.de,
        tony@...mide.com, aaro.koskinen@....fi, linux@...linux.org.uk,
        mark.rutland@....com, marc.zyngier@....com, broonie@...nel.org,
        paulmck@...ux.vnet.ibm.com, mlichvar@...hat.com,
        rdunlap@...radead.org, kstewart@...uxfoundation.org,
        gregkh@...uxfoundation.org, pombredanne@...b.com,
        thierry.reding@...il.com, jonathanh@...dia.com, heiko@...ech.de,
        linus.walleij@...aro.org, viresh.kumar@...aro.org,
        mingo@...nel.org, hpa@...or.com, peterz@...radead.org,
        douly.fnst@...fujitsu.com, len.brown@...el.com,
        rajvi.jingar@...el.com, alexandre.belloni@...tlin.com,
        x86@...nel.org, linux-arm-kernel@...ts.infradead.org,
        linux-tegra@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-omap@...r.kernel.org
Subject: Re: [RFC PATCH 00/10] Add persistent clock support

On Mon, May 14, 2018 at 04:55:26PM +0800, Baolin Wang wrote:
> Hi,
> 
> We will meet below issues when compensating the suspend time for the timekeeping.
> 
> 1. We have too many different ways of dealing with persistent timekeeping
> across architectures, so it is hard for one driver to compatable with different
> architectures.
> 
> 2. On some platforms (such as Spreadtrum platform), we registered the high
> resolution timer as one clocksource to update the OS time, but the high
> resolution timer will be stopped in suspend state. So we use another one
> always-on timer (but low resolution) to calculate the suspend time to
> compensate the OS time. Though we can register the always-on timer as one
> clocksource, we need re-calculate the mult/shift with one larger conversion
> range to calculate the suspend time and need update the clock in case of
> running over the always-on timer.

First, can you elaborate what you mean by 'suspend state' ? On which power
domain the clocksource belongs to?


-- 

 <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog