[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <7d904044-05da-4671-b8de-e752b952b006@quicinc.com>
Date: Fri, 31 May 2024 08:50:30 +0530
From: Jagadeesh Kona <quic_jkona@...cinc.com>
To: Viresh Kumar <viresh.kumar@...aro.org>
CC: Sudeep Holla <sudeep.holla@....com>,
"Rafael J . Wysocki"
<rafael@...nel.org>,
Cristian Marussi <cristian.marussi@....com>,
<linux-arm-kernel@...ts.infradead.org>, <linux-pm@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, Taniya Das <quic_tdas@...cinc.com>,
"Ajit
Pandey" <quic_ajipan@...cinc.com>,
Imran Shaik <quic_imrashai@...cinc.com>,
Vivek Aknurwar <quic_viveka@...cinc.com>,
Mike Tipton
<quic_mdtipton@...cinc.com>
Subject: Re: [PATCH V2] cpufreq: scmi: Avoid overflow of target_freq in fast
switch
On 5/28/2024 9:33 AM, Viresh Kumar wrote:
> On 27-05-24, 15:26, Jagadeesh Kona wrote:
>>
>>
>> On 5/20/2024 2:17 PM, Viresh Kumar wrote:
>>> On 20-05-24, 12:07, Jagadeesh Kona wrote:
>>>> Conversion of target_freq to HZ in scmi_cpufreq_fast_switch()
>>>> can lead to overflow if the multiplied result is greater than
>>>> UINT_MAX, since type of target_freq is unsigned int. Avoid this
>>>> overflow by assigning target_freq to unsigned long variable for
>>>> converting it to HZ.
>>>>
>>>> Signed-off-by: Jagadeesh Kona <quic_jkona@...cinc.com>
>>>> ---
>>>> Changes in V2:
>>>> - Updated freq variable from u64 to unsigned long to keep it
>>>> consistent with the rate parameter in scmi .freq_set() callback
>>>> - Link to v1: https://lore.kernel.org/all/20240517070157.19553-1-quic_jkona@quicinc.com/
>>>> ---
>>>> drivers/cpufreq/scmi-cpufreq.c | 4 ++--
>>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> Applied. Thanks.
>>>
>>
>> Thanks Viresh for the offline update on applying this patch to cpufreq arm
>> tree. Please help share the git tree details of the same, since we need them
>> to pick this change in Google ACK and downstream tree.
>
> git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git cpufreq/arm/linux-next
>
> I have pushed it out now, it will be there in linux-next soon. My
> branch is not fixed, I may end up rebasing it. Ideally, you shouldn't
> backport anything to android unless it end ups in Linus's tree, only
> then the sha id will be fixed and guaranteed not to change.
>
Thanks Viresh!
Powered by blists - more mailing lists