[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250219054944.4kztb6rtumdt3x7h@vireshk-i7>
Date: Wed, 19 Feb 2025 11:19:44 +0530
From: Viresh Kumar <viresh.kumar@...aro.org>
To: Mark Tseng <chun-jen.tseng@...iatek.com>
Cc: "Rafael J . Wysocki" <rafael@...nel.org>,
MyungJoo Ham <myungjoo.ham@...sung.com>,
Kyungmin Park <kyungmin.park@...sung.com>,
Chanwoo Choi <cw00.choi@...sung.com>,
Matthias Brugger <matthias.bgg@...il.com>,
AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org,
linux-mediatek@...ts.infradead.org,
Project_Global_Chrome_Upstream_Group@...iatek.com
Subject: Re: [PATCH v3 3/3] cpufreq: mediatek: data safety protect
On 14-02-25, 15:43, Mark Tseng wrote:
> get policy data in global lock session avoid get wrong data.
>
> Signed-off-by: Mark Tseng <chun-jen.tseng@...iatek.com>
> ---
> drivers/cpufreq/mediatek-cpufreq.c | 15 ++++++++++-----
> 1 file changed, 10 insertions(+), 5 deletions(-)
I think there is some confusion on why exactly locking is required and where
exactly you need it. This patch is incorrect.
If you really think some locking issue is present here, please explain in
detail how a race can happen between different threads.
--
viresh
Powered by blists - more mailing lists