[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201104201631.40017.arnd@arndb.de>
Date: Wed, 20 Apr 2011 16:31:39 +0200
From: Arnd Bergmann <arnd@...db.de>
To: Akinobu Mita <akinobu.mita@...il.com>
Cc: linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
linux-arch@...r.kernel.org,
Martin Schwidefsky <schwidefsky@...ibm.com>,
Heiko Carstens <heiko.carstens@...ibm.com>,
linux390@...ibm.com, linux-s390@...r.kernel.org,
Russell King <linux@....linux.org.uk>,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 1/3] bitops: add ifdef CONFIG_GENERIC_FIND_BIT_LE guard
On Wednesday 20 April 2011, Akinobu Mita wrote:
> index 946a21b..bd2253e 100644
> --- a/include/asm-generic/bitops/le.h
> +++ b/include/asm-generic/bitops/le.h
> @@ -30,6 +30,8 @@ static inline unsigned long find_first_zero_bit_le(const void *addr,
>
> #define BITOP_LE_SWIZZLE ((BITS_PER_LONG-1) & ~0x7)
>
> +#ifdef CONFIG_GENERIC_FIND_BIT_LE
> +
> extern unsigned long find_next_zero_bit_le(const void *addr,
> unsigned long size, unsigned long offset);
> extern unsigned long find_next_bit_le(const void *addr,
> @@ -38,6 +40,8 @@ extern unsigned long find_next_bit_le(const void *addr,
> #define find_first_zero_bit_le(addr, size) \
> find_next_zero_bit_le((addr), (size), 0)
>
> +#endif /* CONFIG_GENERIC_FIND_BIT_LE */
> +
> #else
> #error "Please fix <asm/byteorder.h>"
> #endif
The style that we normally use in asm-generic is to test the macro itself
for existence, so in asm-generic, do:
#ifndef find_next_zero_bit_le
extern unsigned long find_next_zero_bit_le(const void *addr,
unsigned long size, unsigned long offset);
#endif
and in the architectures, write
static inline unsigned long find_next_zero_bit_le(const void *addr,
unsigned long size, unsigned long offset)
#define find_next_zero_bit_le find_next_zero_bit_le
I guess we can do the #ifdef separately for each of the three macros,
or choose one of them to use as a key.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists