Hi Greg,

On Mon, Mar 27, 2017 at 5:10 AM, Greg Ungerer <[email protected]> wrote:
> Compiling for m68k targets will give the following warning:
>
> mm/filemap.c: In function ‘clear_bit_unlock_is_negative_byte’:
> mm/filemap.c:940:30: warning: passing argument 2 of ‘test_bit’ discards 
> ‘volatile’ qualifier from pointer target type [-Wdiscarded-qualifiers]
>   return test_bit(PG_waiters, mem);
>                               ^
> In file included from ./include/linux/bitops.h:36:0,
>                  from ./include/linux/kernel.h:10,
>                  from ./include/linux/list.h:8,
>                  from ./include/linux/wait.h:6,
>                  from ./include/linux/fs.h:5,
>                  from ./include/linux/dax.h:4,
>                  from mm/filemap.c:14:
> ./arch/m68k/include/asm/bitops.h:151:19: note: expected ‘const long unsigned 
> int *’ but argument is of type ‘volatile void *’
>  static inline int test_bit(int nr, const unsigned long *vaddr)
>                    ^
>
> (This is true at least for a gcc-5.4.0 based toolchain).
>
> The problem is that the m68k test_bit() arguments do not match the
> Documemtation/core-api/atomic_ops.rst defined one. (Most other
> architectures define it with "const volatile unsigned long *addr" too).
>
> Change the m68k test_bit() definition to more closely match the documented
> definition. This cleans up the warning.
>
> Signed-off-by: Greg Ungerer <[email protected]>

Already fixed and queued for v4.11, cfr. "[PATCH 2/2] m68k/bitops: Correct
signature of test_bit()" (https://lkml.org/lkml/2017/1/3/505).

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to