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, 29 Aug 2023 14:01:54 +0530
From:   Viresh Kumar <viresh.kumar@...aro.org>
To:     Chun-Jen Tseng (曾俊仁) 
        <Chun-Jen.Tseng@...iatek.com>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-mediatek@...ts.infradead.org" 
        <linux-mediatek@...ts.infradead.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
        "sumitg@...dia.com" <sumitg@...dia.com>,
        "sanjayc@...dia.com" <sanjayc@...dia.com>,
        "rafael.j.wysocki@...el.com" <rafael.j.wysocki@...el.com>,
        Project_Global_Chrome_Upstream_Group 
        <Project_Global_Chrome_Upstream_Group@...iatek.com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "matthias.bgg@...il.com" <matthias.bgg@...il.com>,
        "rafael@...nel.org" <rafael@...nel.org>,
        "angelogioacchino.delregno@...labora.com" 
        <angelogioacchino.delregno@...labora.com>
Subject: Re: [PATCH] cpufreq: mediatek: change transition delay for MT8186

On 29-08-23, 08:25, Chun-Jen Tseng (曾俊仁) wrote:
> Actually, the root cause is the CPU freq setting finish time. If MT8186
> needs 10 ms for two clusters findish setting CPU clock done, I should
> set transition delay 10 ms which avoid call clk_get_rate() get previous
> clock value. If I get previous CPU clock and it over 1 Mhz, the
> cpufreq_out_of_sync() will set CPU freq again but it wrong CPU freq.

Even if another attempt is made to update the frequency, it shouldn't
result in crashing the kernel. If it crashes, then there is something
wrong here.

> Howervery, transition delay seting is by individual SoC , it should not
> force 1 ms for all SoC. So, I wish I can do this patch here.

Its fine if you want to make it 1 second too :), the only thing is
that you should do it for the right reason and I don't think we know
it yet.

Why exactly does the kernel crash here ? Any idea ?

-- 
viresh

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ