linux-kernel - Re: [PATCH v2 2/2] arm64: dts: meson: remove CPU opps below 1GHz for SM1 boards

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]

Message-ID: <3a60384a-b26f-3591-fca9-b10764bd2b24@baylibre.com>
Date:   Fri, 11 Feb 2022 10:25:43 +0100
From:   Neil Armstrong <narmstrong@...libre.com>
To:     Marc Zyngier <maz@...nel.org>,
        Christian Hewitt <christianshewitt@...il.com>
Cc:     Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Kevin Hilman <khilman@...libre.com>,
        devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-amlogic@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/2] arm64: dts: meson: remove CPU opps below 1GHz for
 SM1 boards

Hi Marc,

On 10/02/2022 11:36, Marc Zyngier wrote:
> On 2022-02-10 10:06, Christian Hewitt wrote:
>> Amlogic SM1 devices experience CPU stalls and random board wedges when
>> the system idles and CPU cores clock down to lower opp points. Recent
>> vendor kernels include a change to remove 100-250MHz and other distro
>> sources also remove the 500/667MHz points. Unless all 100-667Mhz opps
>> are removed or the CPU governor forced to performance stalls are still
>> observed, so let's remove them to improve stability and uptime.
>>
>> Fixes: 3d9e76483049 ("arm64: dts: meson-sm1-sei610: enable DVFS")
>> Signed-off-by: Christian Hewitt <christianshewitt@...il.com>
>> ---
>>  arch/arm64/boot/dts/amlogic/meson-sm1.dtsi | 20 --------------------
>>  1 file changed, 20 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-sm1.dtsi
>> b/arch/arm64/boot/dts/amlogic/meson-sm1.dtsi
>> index 3c07a89bfd27..80737731af3f 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-sm1.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-sm1.dtsi
>> @@ -95,26 +95,6 @@
>>          compatible = "operating-points-v2";
>>          opp-shared;
>>
>> -        opp-100000000 {
>> -            opp-hz = /bits/ 64 <100000000>;
>> -            opp-microvolt = <730000>;
>> -        };
>> -
>> -        opp-250000000 {
>> -            opp-hz = /bits/ 64 <250000000>;
>> -            opp-microvolt = <730000>;
>> -        };
>> -
>> -        opp-500000000 {
>> -            opp-hz = /bits/ 64 <500000000>;
>> -            opp-microvolt = <730000>;
>> -        };
>> -
>> -        opp-667000000 {
>> -            opp-hz = /bits/ 64 <666666666>;
>> -            opp-microvolt = <750000>;
>> -        };
>> -
>>          opp-1000000000 {
>>              opp-hz = /bits/ 64 <1000000000>;
>>              opp-microvolt = <770000>;
> 
> That's not nearly enough. If that's an actual issue, the driver
> should be updated not to use these OPPs, and you can't assume
> that people will just update their DT (mine comes from u-boot,
> and it is unlikely I will update it anytime soon).

The driver is the generic cpufreq and a generic clock driver, we do not
filter out the possible OPP frequencies because the possible freq
is large and depends on the die revision.

I don't see why we should filter out these frequencies so far.

Neil

> 
> Thanks,
> 
>          M.