[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240528040345.ghw6qkha3cka2pe5@vireshk-i7>
Date: Tue, 28 May 2024 09:33:45 +0530
From: Viresh Kumar <viresh.kumar@...aro.org>
To: Jagadeesh Kona <quic_jkona@...cinc.com>
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 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.
--
viresh
Powered by blists - more mailing lists