linux-kernel - Re: [PATCH 4.19 04/74] ARM: dts: rockchip: Mark that the rk3288 timer might stop 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>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAD=FV=Vcdq+Z8NQdQrweT0LhzvBiWEd4GQ=QLDEQyGL2=b6r_Q@mail.gmail.com>
Date:   Mon, 12 Aug 2019 17:04:01 -0700
From:   Doug Anderson <dianders@...omium.org>
To:     Pavel Machek <pavel@...x.de>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        LKML <linux-kernel@...r.kernel.org>,
        "# 4.0+" <stable@...r.kernel.org>,
        Heiko Stuebner <heiko@...ech.de>,
        Sasha Levin <sashal@...nel.org>
Subject: Re: [PATCH 4.19 04/74] ARM: dts: rockchip: Mark that the rk3288 timer
 might stop in suspend

Hi,

On Mon, Aug 5, 2019 at 7:47 AM Pavel Machek <pavel@...x.de> wrote:
>
> On Mon 2019-08-05 15:02:17, Greg Kroah-Hartman wrote:
> > [ Upstream commit 8ef1ba39a9fa53d2205e633bc9b21840a275908e ]
> >
> > This is similar to commit e6186820a745 ("arm64: dts: rockchip: Arch
> > counter doesn't tick in system suspend").  Specifically on the rk3288
> > it can be seen that the timer stops ticking in suspend if we end up
> > running through the "osc_disable" path in rk3288_slp_mode_set().  In
> > that path the 24 MHz clock will turn off and the timer stops.
> >
> > To test this, I ran this on a Chrome OS filesystem:
> >   before=$(date); \
> >   suspend_stress_test -c1 --suspend_min=30 --suspend_max=31; \
> >   echo ${before}; date
> >
> > ...and I found that unless I plug in a device that requests USB wakeup
> > to be active that the two calls to "date" would show that fewer than
> > 30 seconds passed.
> >
> > NOTE: deep suspend (where the 24 MHz clock gets disabled) isn't
> > supported yet on upstream Linux so this was tested on a downstream
> > kernel.
>
> I guess this does no harm, but deep sleep is unlikely to be suppored
> in the stable kernels, so ... is it good idea there?

People do merge stable kernels into local trees which have extra
patches (which might enable deep sleep).  Chrome OS is an example of
this.  If the patch does no harm then merging it seems nice.

That being said: we already have this in the Chrome OS tree, so unless
someone else is also mering stable into their tree and trying to
support rk3288 with deep sleep, this patch is unlikely to matter.
...so if everyone doesn't want it then it won't bother me.

-Doug