| Message ID | 1594892369-28060-1-git-send-email-chenhc@lemote.com (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
| Series | [-stable] MIPS: Fix build for LTS kernel caused by backporting lpj adjustment | expand |
Hi, Serge, Could you please have a look at this patch? Huacai On Thu, Jul 16, 2020 at 5:37 PM Huacai Chen <chenhc@lemote.com> wrote: > > Commit ed26aacfb5f71eecb20a ("mips: Add udelay lpj numbers adjustment") > has backported to 4.4~5.4, but the "struct cpufreq_freqs" (and also the > cpufreq notifier machanism) of 4.4~4.19 are different from the upstream > kernel. These differences cause build errors, and this patch can fix the > build. > > Cc: Serge Semin <Sergey.Semin@baikalelectronics.ru> > Cc: Stable <stable@vger.kernel.org> # 4.4/4.9/4.14/4.19 > Signed-off-by: Huacai Chen <chenhc@lemote.com> > --- > arch/mips/kernel/time.c | 13 ++++--------- > 1 file changed, 4 insertions(+), 9 deletions(-) > > diff --git a/arch/mips/kernel/time.c b/arch/mips/kernel/time.c > index b7f7e08..b15ee12 100644 > --- a/arch/mips/kernel/time.c > +++ b/arch/mips/kernel/time.c > @@ -40,10 +40,8 @@ static unsigned long glb_lpj_ref_freq; > static int cpufreq_callback(struct notifier_block *nb, > unsigned long val, void *data) > { > - struct cpufreq_freqs *freq = data; > - struct cpumask *cpus = freq->policy->cpus; > - unsigned long lpj; > int cpu; > + struct cpufreq_freqs *freq = data; > > /* > * Skip lpj numbers adjustment if the CPU-freq transition is safe for > @@ -64,6 +62,7 @@ static int cpufreq_callback(struct notifier_block *nb, > } > } > > + cpu = freq->cpu; > /* > * Adjust global lpj variable and per-CPU udelay_val number in > * accordance with the new CPU frequency. > @@ -74,12 +73,8 @@ static int cpufreq_callback(struct notifier_block *nb, > glb_lpj_ref_freq, > freq->new); > > - for_each_cpu(cpu, cpus) { > - lpj = cpufreq_scale(per_cpu(pcp_lpj_ref, cpu), > - per_cpu(pcp_lpj_ref_freq, cpu), > - freq->new); > - cpu_data[cpu].udelay_val = (unsigned int)lpj; > - } > + cpu_data[cpu].udelay_val = cpufreq_scale(per_cpu(pcp_lpj_ref, cpu), > + per_cpu(pcp_lpj_ref_freq, cpu), freq->new); > } > > return NOTIFY_OK; > -- > 2.7.0 >
在 2020/7/19 上午11:24, Huacai Chen 写道: > Hi, Serge, > > Could you please have a look at this patch? + Gregkh This is urgent for next stable release, please take a look. Thanks > > Huacai > > On Thu, Jul 16, 2020 at 5:37 PM Huacai Chen <chenhc@lemote.com> wrote: >> Commit ed26aacfb5f71eecb20a ("mips: Add udelay lpj numbers adjustment") >> has backported to 4.4~5.4, but the "struct cpufreq_freqs" (and also the >> cpufreq notifier machanism) of 4.4~4.19 are different from the upstream >> kernel. These differences cause build errors, and this patch can fix the >> build. >> >> Cc: Serge Semin <Sergey.Semin@baikalelectronics.ru> >> Cc: Stable <stable@vger.kernel.org> # 4.4/4.9/4.14/4.19 >> Signed-off-by: Huacai Chen <chenhc@lemote.com> >> --- >> arch/mips/kernel/time.c | 13 ++++--------- >> 1 file changed, 4 insertions(+), 9 deletions(-) >> >> diff --git a/arch/mips/kernel/time.c b/arch/mips/kernel/time.c >> index b7f7e08..b15ee12 100644 >> --- a/arch/mips/kernel/time.c >> +++ b/arch/mips/kernel/time.c >> @@ -40,10 +40,8 @@ static unsigned long glb_lpj_ref_freq; >> static int cpufreq_callback(struct notifier_block *nb, >> unsigned long val, void *data) >> { >> - struct cpufreq_freqs *freq = data; >> - struct cpumask *cpus = freq->policy->cpus; >> - unsigned long lpj; >> int cpu; >> + struct cpufreq_freqs *freq = data; >> >> /* >> * Skip lpj numbers adjustment if the CPU-freq transition is safe for >> @@ -64,6 +62,7 @@ static int cpufreq_callback(struct notifier_block *nb, >> } >> } >> >> + cpu = freq->cpu; >> /* >> * Adjust global lpj variable and per-CPU udelay_val number in >> * accordance with the new CPU frequency. >> @@ -74,12 +73,8 @@ static int cpufreq_callback(struct notifier_block *nb, >> glb_lpj_ref_freq, >> freq->new); >> >> - for_each_cpu(cpu, cpus) { >> - lpj = cpufreq_scale(per_cpu(pcp_lpj_ref, cpu), >> - per_cpu(pcp_lpj_ref_freq, cpu), >> - freq->new); >> - cpu_data[cpu].udelay_val = (unsigned int)lpj; >> - } >> + cpu_data[cpu].udelay_val = cpufreq_scale(per_cpu(pcp_lpj_ref, cpu), >> + per_cpu(pcp_lpj_ref_freq, cpu), freq->new); >> } >> >> return NOTIFY_OK; >> -- >> 2.7.0 >>
On Sun, Jul 19, 2020 at 10:51:11PM +0800, Jiaxun Yang wrote: > > 在 2020/7/19 上午11:24, Huacai Chen 写道: > > Hi, Serge, > > > > Could you please have a look at this patch? > > > + Gregkh > > This is urgent for next stable release, please take a look. Relax, it was only sent 3 days ago, we will get to this... Also, why was this not caught by any of the testing systems that we have? That might be good to determine so we don't mess up again in the future. thanks, greg k-h
Hi, Greg, On Sun, Jul 19, 2020 at 11:13 PM Greg KH <gregkh@linuxfoundation.org> wrote: > > On Sun, Jul 19, 2020 at 10:51:11PM +0800, Jiaxun Yang wrote: > > > > 在 2020/7/19 上午11:24, Huacai Chen 写道: > > > Hi, Serge, > > > > > > Could you please have a look at this patch? > > > > > > + Gregkh > > > > This is urgent for next stable release, please take a look. > > Relax, it was only sent 3 days ago, we will get to this... > > Also, why was this not caught by any of the testing systems that we > have? That might be good to determine so we don't mess up again in the > future. I think that is because CPUFREQ is disabled by default on MIPS. Huacai > > thanks, > > greg k-h
在 2020/7/20 上午9:42, Huacai Chen 写道: > Hi, Greg, > > On Sun, Jul 19, 2020 at 11:13 PM Greg KH <gregkh@linuxfoundation.org> wrote: >> On Sun, Jul 19, 2020 at 10:51:11PM +0800, Jiaxun Yang wrote: >>> 在 2020/7/19 上午11:24, Huacai Chen 写道: >>>> Hi, Serge, >>>> >>>> Could you please have a look at this patch? >>> >>> + Gregkh >>> >>> This is urgent for next stable release, please take a look. >> Relax, it was only sent 3 days ago, we will get to this... Ahh, sorry for the rush~ >> >> Also, why was this not caught by any of the testing systems that we >> have? That might be good to determine so we don't mess up again in the >> future. > I think that is because CPUFREQ is disabled by default on MIPS. Yeah, I'm working with kernel-ci to get more config covered. Thanks. - Jiaxun > > Huacai > >> thanks, >> >> greg k-h
Hello Huacai, Thanks for the fix. The patch looks good to me except a small cleanup comment. On Thu, Jul 16, 2020 at 05:39:29PM +0800, Huacai Chen wrote: > Commit ed26aacfb5f71eecb20a ("mips: Add udelay lpj numbers adjustment") > has backported to 4.4~5.4, but the "struct cpufreq_freqs" (and also the > cpufreq notifier machanism) of 4.4~4.19 are different from the upstream > kernel. These differences cause build errors, and this patch can fix the > build. > > Cc: Serge Semin <Sergey.Semin@baikalelectronics.ru> > Cc: Stable <stable@vger.kernel.org> # 4.4/4.9/4.14/4.19 > Signed-off-by: Huacai Chen <chenhc@lemote.com> > --- > arch/mips/kernel/time.c | 13 ++++--------- > 1 file changed, 4 insertions(+), 9 deletions(-) > > diff --git a/arch/mips/kernel/time.c b/arch/mips/kernel/time.c > index b7f7e08..b15ee12 100644 > --- a/arch/mips/kernel/time.c > +++ b/arch/mips/kernel/time.c > @@ -40,10 +40,8 @@ static unsigned long glb_lpj_ref_freq; > static int cpufreq_callback(struct notifier_block *nb, > unsigned long val, void *data) > { > - struct cpufreq_freqs *freq = data; > - struct cpumask *cpus = freq->policy->cpus; > - unsigned long lpj; > int cpu; > + struct cpufreq_freqs *freq = data; Why do you want to rearrange the cpu and freq variables declarations? IMO the order should be left as before since the change doesn't really make the code looking or working any better. If so the change is unneeded. Moreover reverse xmas tree-like variables declaration looks neater than any other. After fixing that feel free to add Reviewed-by: Serge Semin <fancer.lancer@gmail.com> -Sergey > > /* > * Skip lpj numbers adjustment if the CPU-freq transition is safe for > @@ -64,6 +62,7 @@ static int cpufreq_callback(struct notifier_block *nb, > } > } > > + cpu = freq->cpu; > /* > * Adjust global lpj variable and per-CPU udelay_val number in > * accordance with the new CPU frequency. > @@ -74,12 +73,8 @@ static int cpufreq_callback(struct notifier_block *nb, > glb_lpj_ref_freq, > freq->new); > > - for_each_cpu(cpu, cpus) { > - lpj = cpufreq_scale(per_cpu(pcp_lpj_ref, cpu), > - per_cpu(pcp_lpj_ref_freq, cpu), > - freq->new); > - cpu_data[cpu].udelay_val = (unsigned int)lpj; > - } > + cpu_data[cpu].udelay_val = cpufreq_scale(per_cpu(pcp_lpj_ref, cpu), > + per_cpu(pcp_lpj_ref_freq, cpu), freq->new); > } > > return NOTIFY_OK; > -- > 2.7.0 >
diff --git a/arch/mips/kernel/time.c b/arch/mips/kernel/time.c index b7f7e08..b15ee12 100644 --- a/arch/mips/kernel/time.c +++ b/arch/mips/kernel/time.c @@ -40,10 +40,8 @@ static unsigned long glb_lpj_ref_freq; static int cpufreq_callback(struct notifier_block *nb, unsigned long val, void *data) { - struct cpufreq_freqs *freq = data; - struct cpumask *cpus = freq->policy->cpus; - unsigned long lpj; int cpu; + struct cpufreq_freqs *freq = data; /* * Skip lpj numbers adjustment if the CPU-freq transition is safe for @@ -64,6 +62,7 @@ static int cpufreq_callback(struct notifier_block *nb, } } + cpu = freq->cpu; /* * Adjust global lpj variable and per-CPU udelay_val number in * accordance with the new CPU frequency. @@ -74,12 +73,8 @@ static int cpufreq_callback(struct notifier_block *nb, glb_lpj_ref_freq, freq->new); - for_each_cpu(cpu, cpus) { - lpj = cpufreq_scale(per_cpu(pcp_lpj_ref, cpu), - per_cpu(pcp_lpj_ref_freq, cpu), - freq->new); - cpu_data[cpu].udelay_val = (unsigned int)lpj; - } + cpu_data[cpu].udelay_val = cpufreq_scale(per_cpu(pcp_lpj_ref, cpu), + per_cpu(pcp_lpj_ref_freq, cpu), freq->new); } return NOTIFY_OK;
Commit ed26aacfb5f71eecb20a ("mips: Add udelay lpj numbers adjustment") has backported to 4.4~5.4, but the "struct cpufreq_freqs" (and also the cpufreq notifier machanism) of 4.4~4.19 are different from the upstream kernel. These differences cause build errors, and this patch can fix the build. Cc: Serge Semin <Sergey.Semin@baikalelectronics.ru> Cc: Stable <stable@vger.kernel.org> # 4.4/4.9/4.14/4.19 Signed-off-by: Huacai Chen <chenhc@lemote.com> --- arch/mips/kernel/time.c | 13 ++++--------- 1 file changed, 4 insertions(+), 9 deletions(-)