linux-kernel - Re: [PATCH] cpufreq: mediatek: change transition delay for MT8186

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: <20230828063904.r7huxclehlblkkjx@vireshk-i7>
Date:   Mon, 28 Aug 2023 12:09:04 +0530
From:   Viresh Kumar <viresh.kumar@...aro.org>
To:     Mark Tseng <chun-jen.tseng@...iatek.com>
Cc:     rafael@...nel.org, matthias.bgg@...il.com,
        angelogioacchino.delregno@...labora.com, sumitg@...dia.com,
        sanjayc@...dia.com, rafael.j.wysocki@...el.com,
        linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org,
        linux-mediatek@...ts.infradead.org, devicetree@...r.kernel.org,
        Project_Global_Chrome_Upstream_Group@...iatek.com
Subject: Re: [PATCH] cpufreq: mediatek: change transition delay for MT8186

Hi Mark,

I am not entirely clear by few things in the commit log.

On 18-08-23, 10:06, Mark Tseng wrote:
> For MT8186, it has policy0 and policy6 by different governor thread,so
> it may be call cpufreq->set_target_index() by different core.

Why does this matter ?

> In general
> case, it must check BCPU, LCPU and CCI together then take about 10ms.

BCPU is Big CPU ? LCPU is Little CPU ?

So are you saying that changing the frequency takes roughly 10 ms for
MT8186 ?

> Atfer 44295af5019f this patch, it may call cpufreq_out_of_sync() by
> cpufreq_verify_current_freq() because current frequency is bigger
> than clk_get_rate() ouver 1Mh. By the same time, it may call

s/ouver/over/
s/1Mh/1 MHz/

> cpufreq->set_target_index() again.

Where was it called for the first time ?

> So, the CCI freq may be too lower for
> BCPU cause BCPU kernel panic.

I am not sure how a low frequency causes kernel panic here.

> So, it should change the default transition delay 1ms to 10ms. It can
> promise the next freq setting then governor trigger new freq change.

There are few typos as well here, please fix them.

> Fixes: 44295af5019f ("cpufreq: use correct unit when verify cur freq")

I think you should drop this. The issue at hand may be visible now
after 44295af5019f is applied, but it certainly didn't cause it.

-- 
viresh