2012-10-05 14:57:52

by Arnd Bergmann

[permalink] [raw]
Subject: [PATCH 01/16] ARM: warnings in arch/arm/include/asm/uaccess.h

On NOMMU ARM, the __addr_ok() and __range_ok() macros do not evaluate
their arguments, which may lead to harmless build warnings in some
code where the variables are not used otherwise. Adding a cast to void
gets rid of the warning and does not make any semantic changes.

Without this patch, building at91x40_defconfig results in:

fs/read_write.c: In function 'rw_copy_check_uvector':
fs/read_write.c:684:9: warning: unused variable 'buf' [-Wunused-variable]

Signed-off-by: Arnd Bergmann <[email protected]>
Cc: Greg Ungerer <[email protected]>
Cc: Russell King <[email protected]>
---
arch/arm/include/asm/uaccess.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/uaccess.h b/arch/arm/include/asm/uaccess.h
index 77bd79f..7e1f760 100644
--- a/arch/arm/include/asm/uaccess.h
+++ b/arch/arm/include/asm/uaccess.h
@@ -200,8 +200,8 @@ extern int __put_user_8(void *, unsigned long long);
#define USER_DS KERNEL_DS

#define segment_eq(a,b) (1)
-#define __addr_ok(addr) (1)
-#define __range_ok(addr,size) (0)
+#define __addr_ok(addr) ((void)(addr),1)
+#define __range_ok(addr,size) ((void)(addr),0)
#define get_fs() (KERNEL_DS)

static inline void set_fs(mm_segment_t fs)
--
1.7.10


2012-10-08 05:44:12

by Greg Ungerer

[permalink] [raw]
Subject: Re: [PATCH 01/16] ARM: warnings in arch/arm/include/asm/uaccess.h

On 06/10/12 00:55, Arnd Bergmann wrote:
> On NOMMU ARM, the __addr_ok() and __range_ok() macros do not evaluate
> their arguments, which may lead to harmless build warnings in some
> code where the variables are not used otherwise. Adding a cast to void
> gets rid of the warning and does not make any semantic changes.
>
> Without this patch, building at91x40_defconfig results in:
>
> fs/read_write.c: In function 'rw_copy_check_uvector':
> fs/read_write.c:684:9: warning: unused variable 'buf' [-Wunused-variable]
>
> Signed-off-by: Arnd Bergmann <[email protected]>
> Cc: Greg Ungerer <[email protected]>
> Cc: Russell King <[email protected]>

Acked-by: Greg Ungerer <[email protected]>

I can pick it up and push to the arm-soc tree.

Regards
Greg


> ---
> arch/arm/include/asm/uaccess.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/include/asm/uaccess.h b/arch/arm/include/asm/uaccess.h
> index 77bd79f..7e1f760 100644
> --- a/arch/arm/include/asm/uaccess.h
> +++ b/arch/arm/include/asm/uaccess.h
> @@ -200,8 +200,8 @@ extern int __put_user_8(void *, unsigned long long);
> #define USER_DS KERNEL_DS
>
> #define segment_eq(a,b) (1)
> -#define __addr_ok(addr) (1)
> -#define __range_ok(addr,size) (0)
> +#define __addr_ok(addr) ((void)(addr),1)
> +#define __range_ok(addr,size) ((void)(addr),0)
> #define get_fs() (KERNEL_DS)
>
> static inline void set_fs(mm_segment_t fs)
>


--
------------------------------------------------------------------------
Greg Ungerer -- Principal Engineer EMAIL: [email protected]
SnapGear Group, McAfee PHONE: +61 7 3435 2888
8 Gardner Close FAX: +61 7 3217 5323
Milton, QLD, 4064, Australia WEB: http://www.SnapGear.com

2012-10-09 12:09:26

by Arnd Bergmann

[permalink] [raw]
Subject: Re: [PATCH 01/16] ARM: warnings in arch/arm/include/asm/uaccess.h

On Monday 08 October 2012, Greg Ungerer wrote:
> On 06/10/12 00:55, Arnd Bergmann wrote:
> > On NOMMU ARM, the __addr_ok() and __range_ok() macros do not evaluate
> > their arguments, which may lead to harmless build warnings in some
> > code where the variables are not used otherwise. Adding a cast to void
> > gets rid of the warning and does not make any semantic changes.
> >
> > Without this patch, building at91x40_defconfig results in:
> >
> > fs/read_write.c: In function 'rw_copy_check_uvector':
> > fs/read_write.c:684:9: warning: unused variable 'buf' [-Wunused-variable]
> >
> > Signed-off-by: Arnd Bergmann <[email protected]>
> > Cc: Greg Ungerer <[email protected]>
> > Cc: Russell King <[email protected]>
>
> Acked-by: Greg Ungerer <[email protected]>

Thanks!

> I can pick it up and push to the arm-soc tree.

Well, my idea was that I would prefer the patches go through some other tree
besides arm-soc since they are not really the main purpose for this tree.

The core ARM patches in particular should go through Russell's ARM tree.
I have a few more that come in during the merge window and plan to send
him a pull request for those.

Arnd