On 19. 8. 12. 오전 6:23, Dmitry Osipenko wrote: > We already had few integer overflow bugs, let's limit the freq for > consistency. > > Signed-off-by: Dmitry Osipenko <digetx@xxxxxxxxx> > --- > drivers/devfreq/tegra30-devfreq.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/devfreq/tegra30-devfreq.c b/drivers/devfreq/tegra30-devfreq.c > index 70dce58212a4..ca499368ee81 100644 > --- a/drivers/devfreq/tegra30-devfreq.c > +++ b/drivers/devfreq/tegra30-devfreq.c > @@ -430,7 +430,7 @@ static unsigned long actmon_update_target(struct tegra_devfreq *tegra, > target_freq = dev->avg_count / ACTMON_SAMPLING_PERIOD + dev->boost_freq; > target_freq = tegra_actmon_account_cpu_freq(tegra, dev, target_freq); > > - return target_freq; > + return min(target_freq, tegra->max_freq); Once again, did you meet this case sometimes? Usually, we can prevent the overflow of target_freq when calculating the target frequency or this style. I think that if the overflow of target frequency happen frequently, it might have the problem of calculation way. > } > > static irqreturn_t actmon_thread_isr(int irq, void *data) > -- Best Regards, Chanwoo Choi Samsung Electronics
