linux-kernel - Re: [PATCHv2 2/2] clk: meson: g12a: set cpub_clk flags to CLK_IS

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:   Fri, 20 Mar 2020 00:39:17 +0100
From:   Martin Blumenstingl <martin.blumenstingl@...glemail.com>
To:     Kevin Hilman <khilman@...libre.com>
Cc:     Anand Moon <linux.amoon@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Neil Armstrong <narmstrong@...libre.com>,
        Jerome Brunet <jbrunet@...libre.com>,
        Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...nel.org>, devicetree@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org,
        linux-amlogic@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-clk@...r.kernel.org
Subject: Re: [PATCHv2 2/2] clk: meson: g12a: set cpub_clk flags to CLK_IS_CRITICAL

Hi Kevin,

On Mon, Mar 2, 2020 at 6:01 PM Kevin Hilman <khilman@...libre.com> wrote:
[...]
> > updating flags to CLK_IS_CRITICAL which help enable all the parent for
> > cpub_clk.
>
> With current mainline, I've tested DVFS using CPUfreq on both clusters
> on odroid-n2, and both clusters are booting, so I don't understand the
> need for this patch.
I *think* there is a race condition at kernel boot between cpufreq and
disabling orphaned clocks
I'm not sure I fully understand it though and I don't have any G12B
board to verify it

my understanding is that u-boot runs Linux off CPU0 which is clocked by cpub_clk
this means we need to keep cpub_clk enabled as long as Linux wants the
CPU0 processor to be enabled (on 32-bit ARM platforms that would be
smp_operations.cpu_{kill,die})
cpufreq does not call clk_prepare_enable on the CPU clocks so this
means that the orphaned clock cleanup mechanism can disable it "at any
time", killing everything running on CPU0 and CPU1 (which are both
clocked by cpub_clk)

I have no explanation why this depends on booting from SD or eMMC.

for the 32-bit SoCs we have CLK_IS_CRITICAL on the CPU clock as well
since commit 0dad1ec65bc30a
on G12A we have CLK_IS_CRITICAL on the sys_pll clocks, however my
understanding is that cpub_clk could also be fed by one of the
fixed_pll derived clocks (which have a gate as well, which may or may
not be turned off by the orphaned clock cleanup - that is pure
speculation from my side though).


Martin