These patches fix some build warnings that occur on linux-linaro-lsk-v3.10-android but don't occur on LSK proper.
The first (drivers/base: cpu: fix merge problem) is the one that Ryan already mailed around on April 4th.
Jon Medhurst (2): cgroup: Fix build warnings when CGROUP not defined. tcp: Silence warning: 'in6' may be used uninitialized
Mark Hambleton (1): cpuidle: governor: menu: comment out unused variable
Ryan Harkin (1): drivers/base: cpu: fix merge problem
drivers/base/cpu.c | 2 +- drivers/cpuidle/governors/menu.c | 3 ++- include/linux/cgroup.h | 5 ----- net/ipv4/tcp.c | 2 +- 4 files changed, 4 insertions(+), 8 deletions(-)
From: Ryan Harkin ryan.harkin@linaro.org
In LSK's linux-linaro-lsk-android branch, this merge
bb0dddf6157bc679de9143507375fce3f13fcd00
broke drivers/base/cpu.c
Because this patch appears twice: 197028d 2014-02-08 cpu: add generic support for CPU feature based module autoloading [Ard Biesheuvel] 126ef42 2014-02-08 cpu: add generic support for CPU feature based module autoloading [Ard Biesheuvel]
And the merge edited the file to the old contents.
Signed-off-by: Ryan Harkin ryan.harkin@linaro.org Signed-off-by: Jon Medhurst tixy@linaro.org --- drivers/base/cpu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c index ac292ee..607efe6 100644 --- a/drivers/base/cpu.c +++ b/drivers/base/cpu.c @@ -319,7 +319,7 @@ int __cpuinit register_cpu(struct cpu *cpu, int num) cpu->dev.id = num; cpu->dev.bus = &cpu_subsys; cpu->dev.release = cpu_device_release; -#ifdef CONFIG_ARCH_HAS_CPU_AUTOPROBE +#ifdef CONFIG_HAVE_CPU_AUTOPROBE cpu->dev.bus->uevent = cpu_uevent; #endif error = device_register(&cpu->dev);
From: Mark Hambleton mark.hambleton@arm.com
Remove unused variable referenced from commented out code.
Fixes warning caused by commit df99953c42c6 ("cpuidle: governor: menu: don't use loadavg")
Signed-off-by: Mark Hambleton mark.hambleton@arm.com Signed-off-by: Jon Medhurst tixy@linaro.org --- drivers/cpuidle/governors/menu.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/cpuidle/governors/menu.c b/drivers/cpuidle/governors/menu.c index 33305fb..9924ea20 100644 --- a/drivers/cpuidle/governors/menu.c +++ b/drivers/cpuidle/governors/menu.c @@ -126,6 +126,7 @@ struct menu_device { #define LOAD_INT(x) ((x) >> FSHIFT) #define LOAD_FRAC(x) LOAD_INT(((x) & (FIXED_1-1)) * 100)
+#if 0 static int get_loadavg(void) { unsigned long this = this_cpu_load(); @@ -133,7 +134,7 @@ static int get_loadavg(void)
return LOAD_INT(this) * 10 + LOAD_FRAC(this) / 10; } - +#endif static inline int which_bucket(unsigned int duration) { int bucket = 0;
On 14 April 2015 at 21:33, Jon Medhurst tixy@linaro.org wrote:
From: Mark Hambleton mark.hambleton@arm.com
Remove unused variable referenced from commented out code.
Fixes warning caused by commit df99953c42c6 ("cpuidle: governor: menu: don't use loadavg")
Signed-off-by: Mark Hambleton mark.hambleton@arm.com Signed-off-by: Jon Medhurst tixy@linaro.org
drivers/cpuidle/governors/menu.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/cpuidle/governors/menu.c b/drivers/cpuidle/governors/menu.c index 33305fb..9924ea20 100644 --- a/drivers/cpuidle/governors/menu.c +++ b/drivers/cpuidle/governors/menu.c @@ -126,6 +126,7 @@ struct menu_device { #define LOAD_INT(x) ((x) >> FSHIFT) #define LOAD_FRAC(x) LOAD_INT(((x) & (FIXED_1-1)) * 100)
+#if 0 static int get_loadavg(void)
How about using __maybe_unused attribute here instead?
{ unsigned long this = this_cpu_load(); @@ -133,7 +134,7 @@ static int get_loadavg(void)
return LOAD_INT(this) * 10 + LOAD_FRAC(this) / 10;}
+#endif static inline int which_bucket(unsigned int duration) { int bucket = 0; -- 2.1.4
On Thu, 2015-04-16 at 14:56 +0530, Amit Pundir wrote:
On 14 April 2015 at 21:33, Jon Medhurst tixy@linaro.org wrote:
From: Mark Hambleton mark.hambleton@arm.com
Remove unused variable referenced from commented out code.
Fixes warning caused by commit df99953c42c6 ("cpuidle: governor: menu: don't use loadavg")
Signed-off-by: Mark Hambleton mark.hambleton@arm.com Signed-off-by: Jon Medhurst tixy@linaro.org
drivers/cpuidle/governors/menu.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/cpuidle/governors/menu.c b/drivers/cpuidle/governors/menu.c index 33305fb..9924ea20 100644 --- a/drivers/cpuidle/governors/menu.c +++ b/drivers/cpuidle/governors/menu.c @@ -126,6 +126,7 @@ struct menu_device { #define LOAD_INT(x) ((x) >> FSHIFT) #define LOAD_FRAC(x) LOAD_INT(((x) & (FIXED_1-1)) * 100)
+#if 0 static int get_loadavg(void)
How about using __maybe_unused attribute here instead?
Does that work for function definitions? Anyway, it's definitely unused because the Android patch referenced in the commit message comments out the only caller of the function. I would say that neither patch should be commenting out of #if 0'ing code, if it's not wanted, it should be deleted. But, in the end, I guess nobody really cares how it's done, and I don't have a preference as to how the warning is silenced.
On 16 April 2015 at 16:47, Jon Medhurst (Tixy) tixy@linaro.org wrote:
On Thu, 2015-04-16 at 14:56 +0530, Amit Pundir wrote:
On 14 April 2015 at 21:33, Jon Medhurst tixy@linaro.org wrote:
From: Mark Hambleton mark.hambleton@arm.com
Remove unused variable referenced from commented out code.
Fixes warning caused by commit df99953c42c6 ("cpuidle: governor: menu: don't use loadavg")
Signed-off-by: Mark Hambleton mark.hambleton@arm.com Signed-off-by: Jon Medhurst tixy@linaro.org
drivers/cpuidle/governors/menu.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/cpuidle/governors/menu.c b/drivers/cpuidle/governors/menu.c index 33305fb..9924ea20 100644 --- a/drivers/cpuidle/governors/menu.c +++ b/drivers/cpuidle/governors/menu.c @@ -126,6 +126,7 @@ struct menu_device { #define LOAD_INT(x) ((x) >> FSHIFT) #define LOAD_FRAC(x) LOAD_INT(((x) & (FIXED_1-1)) * 100)
+#if 0 static int get_loadavg(void)
How about using __maybe_unused attribute here instead?
Does that work for function definitions?
Yes it apparently does.
Anyway, it's definitely unused because the Android patch referenced in the commit message comments out the only caller of the function. I would say that neither patch should be commenting out of #if 0'ing code, if it's not wanted, it should be deleted.
Agreed. I'd have happily deleted it, if it wasn't a part of mainline tree. So I'm a bit hesitant to do that.
But, in the end, I guess nobody really cares how it's done, and I don't have a preference as to how the warning is silenced.
I'm sticking with __maybe_unused attribute then. Also I'll try to verify if we still need this Android commit df99953c42c6 ("cpuidle: governor: menu: don't use loadavg").
Regards, Amit Pundir
-- Tixy
On Thu, 2015-04-16 at 17:17 +0530, Amit Pundir wrote:
I'm sticking with __maybe_unused attribute then.
Fair enough.
Also I'll try to verify if we still need this Android commit df99953c42c6 ("cpuidle: governor: menu: don't use loadavg").
I see loadavg is still in Linux 4.0, so if for whatever reason the Android guys think it's a bad idea, that though hasn't made it's way upstream in the intervening years.
Commit 57114e95e8 ("cgroup: refactor allow_attach function into common code") unnecessarily added a dummy definition for subsys_cgroup_allow_attach when CONFIG_CGROUP is not set, so remove it to prevent warnings like...
include/linux/cgroup.h:907:18: warning: 'struct cgroup_taskset' declared inside parameter list struct cgroup_taskset *tset) ^ include/linux/cgroup.h:907:18: warning: its scope is only this definition or declaration, which is probably not what you want include/linux/cgroup.h:907:18: warning: 'struct cgroup' declared inside parameter list CC kernel/events/core.o In file included from kernel/events/core.c:41:0: include/linux/cgroup.h:907:18: warning: 'struct cgroup_taskset' declared inside parameter list struct cgroup_taskset *tset)
Signed-off-by: Jon Medhurst tixy@linaro.org --- include/linux/cgroup.h | 5 ----- 1 file changed, 5 deletions(-)
diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h index a6fc777..a3997d5 100644 --- a/include/linux/cgroup.h +++ b/include/linux/cgroup.h @@ -903,11 +903,6 @@ static inline int cgroup_attach_task_all(struct task_struct *from, return 0; }
-static inline int subsys_cgroup_allow_attach(struct cgroup *cgrp, - struct cgroup_taskset *tset) -{ - return 0; -} #endif /* !CONFIG_CGROUPS */
#endif /* _LINUX_CGROUP_H */
Initialise in6 to avoid...
In file included from include/net/inetpeer.h:15:0, from include/net/route.h:28, from include/net/inet_hashtables.h:32, from include/net/tcp.h:37, from net/ipv4/tcp.c:275: net/ipv4/tcp.c: In function ‘tcp_nuke_addr’: include/net/ipv6.h:417:34: warning: ‘in6’ may be used uninitialized in this function [-Wmaybe-uninitialized] return ((ul1[0] ^ ul2[0]) | (ul1[1] ^ ul2[1])) == 0UL; ^ net/ipv4/tcp.c:3513:19: note: ‘in6’ was declared here struct in6_addr *in6;
Signed-off-by: Jon Medhurst tixy@linaro.org --- net/ipv4/tcp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c index aabb528..8cc9b54 100644 --- a/net/ipv4/tcp.c +++ b/net/ipv4/tcp.c @@ -3510,7 +3510,7 @@ int tcp_nuke_addr(struct net *net, struct sockaddr *addr)
struct in_addr *in; #if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) - struct in6_addr *in6; + struct in6_addr *in6 = NULL; #endif if (family == AF_INET) { in = &((struct sockaddr_in *)addr)->sin_addr;
All looks fine.
Does this patchset suppose to be merged into LSK directly? or via your hands or android part?
Thanks Alex
On 04/15/2015 12:03 AM, Jon Medhurst wrote:
These patches fix some build warnings that occur on linux-linaro-lsk-v3.10-android but don't occur on LSK proper.
The first (drivers/base: cpu: fix merge problem) is the one that Ryan already mailed around on April 4th.
Jon Medhurst (2): cgroup: Fix build warnings when CGROUP not defined. tcp: Silence warning: 'in6' may be used uninitialized
Mark Hambleton (1): cpuidle: governor: menu: comment out unused variable
Ryan Harkin (1): drivers/base: cpu: fix merge problem
drivers/base/cpu.c | 2 +- drivers/cpuidle/governors/menu.c | 3 ++- include/linux/cgroup.h | 5 ----- net/ipv4/tcp.c | 2 +- 4 files changed, 4 insertions(+), 8 deletions(-)
On 15 April 2015 at 13:31, Alex Shi alex.shi@linaro.org wrote:
All looks fine.
Does this patchset suppose to be merged into LSK directly? or via your hands or android part?
Hi, I'm thinking of applying these fixes in Android topic branches first and then send it to LSK 3.10 and 3.14 via monthly pull requests which I'm preparing for 15.04 anyway. Make sense right?
Regards, Amit Pundir
Thanks Alex
On 04/15/2015 12:03 AM, Jon Medhurst wrote:
These patches fix some build warnings that occur on linux-linaro-lsk-v3.10-android but don't occur on LSK proper.
The first (drivers/base: cpu: fix merge problem) is the one that Ryan already mailed around on April 4th.
Jon Medhurst (2): cgroup: Fix build warnings when CGROUP not defined. tcp: Silence warning: 'in6' may be used uninitialized
Mark Hambleton (1): cpuidle: governor: menu: comment out unused variable
Ryan Harkin (1): drivers/base: cpu: fix merge problem
drivers/base/cpu.c | 2 +- drivers/cpuidle/governors/menu.c | 3 ++- include/linux/cgroup.h | 5 ----- net/ipv4/tcp.c | 2 +- 4 files changed, 4 insertions(+), 8 deletions(-)
On Wed, 2015-04-15 at 13:46 +0530, Amit Pundir wrote:
On 15 April 2015 at 13:31, Alex Shi alex.shi@linaro.org wrote:
All looks fine.
Does this patchset suppose to be merged into LSK directly? or via your hands or android part?
Hi, I'm thinking of applying these fixes in Android topic branches first and then send it to LSK 3.10 and 3.14 via monthly pull requests which I'm preparing for 15.04 anyway. Make sense right?
Makes sense to me, except for patch 1. That fixes a bad merge of the android topic into linux-linaro-lsk-android, so I assume it should be applied directly to linux-linaro-lsk-android?
On 04/15/2015 04:52 PM, Jon Medhurst (Tixy) wrote:
On Wed, 2015-04-15 at 13:46 +0530, Amit Pundir wrote:
On 15 April 2015 at 13:31, Alex Shi alex.shi@linaro.org wrote:
All looks fine.
Does this patchset suppose to be merged into LSK directly? or via your hands or android part?
Hi, I'm thinking of applying these fixes in Android topic branches first and then send it to LSK 3.10 and 3.14 via monthly pull requests which I'm preparing for 15.04 anyway. Make sense right?
Makes sense to me, except for patch 1. That fixes a bad merge of the android topic into linux-linaro-lsk-android, so I assume it should be applied directly to linux-linaro-lsk-android?
Yes, this solution seems better. Is this OK, Amit?
Thanks Alex
On 15 April 2015 at 14:33, Alex Shi alex.shi@linaro.org wrote:
On 04/15/2015 04:52 PM, Jon Medhurst (Tixy) wrote:
On Wed, 2015-04-15 at 13:46 +0530, Amit Pundir wrote:
On 15 April 2015 at 13:31, Alex Shi alex.shi@linaro.org wrote:
All looks fine.
Does this patchset suppose to be merged into LSK directly? or via your hands or android part?
Hi, I'm thinking of applying these fixes in Android topic branches first and then send it to LSK 3.10 and 3.14 via monthly pull requests which I'm preparing for 15.04 anyway. Make sense right?
Makes sense to me, except for patch 1. That fixes a bad merge of the android topic into linux-linaro-lsk-android, so I assume it should be applied directly to linux-linaro-lsk-android?
Yes, this solution seems better. Is this OK, Amit?
Works for me. Thanks.
Regards, Amit Pundir
Thanks Alex
Thanks Alex
On 04/15/2015 05:42 PM, Amit Pundir wrote:
On 15 April 2015 at 14:33, Alex Shi alex.shi@linaro.org wrote:
On 04/15/2015 04:52 PM, Jon Medhurst (Tixy) wrote:
On Wed, 2015-04-15 at 13:46 +0530, Amit Pundir wrote:
On 15 April 2015 at 13:31, Alex Shi alex.shi@linaro.org wrote:
All looks fine.
Does this patchset suppose to be merged into LSK directly? or via your hands or android part?
Hi, I'm thinking of applying these fixes in Android topic branches first and then send it to LSK 3.10 and 3.14 via monthly pull requests which I'm preparing for 15.04 anyway. Make sense right?
Makes sense to me, except for patch 1. That fixes a bad merge of the android topic into linux-linaro-lsk-android, so I assume it should be applied directly to linux-linaro-lsk-android?
Yes, this solution seems better. Is this OK, Amit?
Works for me. Thanks.
pulled on lsk-android. Thanks!
linaro-kernel@lists.linaro.org
-
Alex Shi -
Amit Pundir -
Jon Medhurst -
Jon Medhurst (Tixy)