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;
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
linux-stable-mirror@lists.linaro.org
-
Greg KH -
Huacai Chen -
Huacai Chen -
Jiaxun Yang -
Serge Semin