From: Randy Dunlap <rdunlap@xenotime.net>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: tglx@linutronix.de, nickpiggin@yahoo.com.au, mingo@redhat.com,
hpa@zytor.com, linux-kernel@vger.kernel.org,
torvalds@linux-foundation.org, Andy Whitcroft <apw@shadowen.org>
Subject: [PATCH] x86 bitops: fix code style issues
Date: Thu, 25 Oct 2007 14:27:24 -0700 [thread overview]
Message-ID: <20071025142724.71d184ba.rdunlap@xenotime.net> (raw)
In-Reply-To: <20071025134814.caced2e3.akpm@linux-foundation.org>
From: Randy Dunlap <randy.dunlap@oracle.com>
Coding style cleanups:
- change __inline__ to inline;
- drop space in "* addr" parameters;
- drop space between func. name and '('
The "volatile" keywords are correct according to email from one
Linus Torvalds.
[Several other arches need some of this also.]
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
include/asm-x86/bitops_64.h | 52 ++++++++++++++++++++++----------------------
1 file changed, 26 insertions(+), 26 deletions(-)
--- linux-2.6.24-rc1.orig/include/asm-x86/bitops_64.h
+++ linux-2.6.24-rc1/include/asm-x86/bitops_64.h
@@ -29,7 +29,7 @@
* Note that @nr may be almost arbitrarily large; this function is not
* restricted to acting on a single-word quantity.
*/
-static __inline__ void set_bit(int nr, volatile void * addr)
+static inline void set_bit(int nr, volatile void *addr)
{
__asm__ __volatile__( LOCK_PREFIX
"btsl %1,%0"
@@ -46,7 +46,7 @@ static __inline__ void set_bit(int nr, v
* If it's called on the same region of memory simultaneously, the effect
* may be that only one operation succeeds.
*/
-static __inline__ void __set_bit(int nr, volatile void * addr)
+static inline void __set_bit(int nr, volatile void *addr)
{
__asm__ volatile(
"btsl %1,%0"
@@ -64,7 +64,7 @@ static __inline__ void __set_bit(int nr,
* you should call smp_mb__before_clear_bit() and/or smp_mb__after_clear_bit()
* in order to ensure changes are visible on other processors.
*/
-static __inline__ void clear_bit(int nr, volatile void * addr)
+static inline void clear_bit(int nr, volatile void *addr)
{
__asm__ __volatile__( LOCK_PREFIX
"btrl %1,%0"
@@ -86,7 +86,7 @@ static inline void clear_bit_unlock(unsi
clear_bit(nr, addr);
}
-static __inline__ void __clear_bit(int nr, volatile void * addr)
+static inline void __clear_bit(int nr, volatile void *addr)
{
__asm__ __volatile__(
"btrl %1,%0"
@@ -124,7 +124,7 @@ static inline void __clear_bit_unlock(un
* If it's called on the same region of memory simultaneously, the effect
* may be that only one operation succeeds.
*/
-static __inline__ void __change_bit(int nr, volatile void * addr)
+static inline void __change_bit(int nr, volatile void *addr)
{
__asm__ __volatile__(
"btcl %1,%0"
@@ -141,7 +141,7 @@ static __inline__ void __change_bit(int
* Note that @nr may be almost arbitrarily large; this function is not
* restricted to acting on a single-word quantity.
*/
-static __inline__ void change_bit(int nr, volatile void * addr)
+static inline void change_bit(int nr, volatile void *addr)
{
__asm__ __volatile__( LOCK_PREFIX
"btcl %1,%0"
@@ -157,7 +157,7 @@ static __inline__ void change_bit(int nr
* This operation is atomic and cannot be reordered.
* It also implies a memory barrier.
*/
-static __inline__ int test_and_set_bit(int nr, volatile void * addr)
+static inline int test_and_set_bit(int nr, volatile void *addr)
{
int oldbit;
@@ -175,7 +175,7 @@ static __inline__ int test_and_set_bit(i
*
* This is the same as test_and_set_bit on x86.
*/
-static __inline__ int test_and_set_bit_lock(int nr, volatile void *addr)
+static inline int test_and_set_bit_lock(int nr, volatile void *addr)
{
return test_and_set_bit(nr, addr);
}
@@ -189,7 +189,7 @@ static __inline__ int test_and_set_bit_l
* If two examples of this operation race, one can appear to succeed
* but actually fail. You must protect multiple accesses with a lock.
*/
-static __inline__ int __test_and_set_bit(int nr, volatile void * addr)
+static inline int __test_and_set_bit(int nr, volatile void *addr)
{
int oldbit;
@@ -208,7 +208,7 @@ static __inline__ int __test_and_set_bit
* This operation is atomic and cannot be reordered.
* It also implies a memory barrier.
*/
-static __inline__ int test_and_clear_bit(int nr, volatile void * addr)
+static inline int test_and_clear_bit(int nr, volatile void *addr)
{
int oldbit;
@@ -228,7 +228,7 @@ static __inline__ int test_and_clear_bit
* If two examples of this operation race, one can appear to succeed
* but actually fail. You must protect multiple accesses with a lock.
*/
-static __inline__ int __test_and_clear_bit(int nr, volatile void * addr)
+static inline int __test_and_clear_bit(int nr, volatile void *addr)
{
int oldbit;
@@ -240,7 +240,7 @@ static __inline__ int __test_and_clear_b
}
/* WARNING: non atomic and it can be reordered! */
-static __inline__ int __test_and_change_bit(int nr, volatile void * addr)
+static inline int __test_and_change_bit(int nr, volatile void *addr)
{
int oldbit;
@@ -259,7 +259,7 @@ static __inline__ int __test_and_change_
* This operation is atomic and cannot be reordered.
* It also implies a memory barrier.
*/
-static __inline__ int test_and_change_bit(int nr, volatile void * addr)
+static inline int test_and_change_bit(int nr, volatile void *addr)
{
int oldbit;
@@ -276,15 +276,15 @@ static __inline__ int test_and_change_bi
* @nr: bit number to test
* @addr: Address to start counting from
*/
-static int test_bit(int nr, const volatile void * addr);
+static int test_bit(int nr, const volatile void *addr);
#endif
-static __inline__ int constant_test_bit(int nr, const volatile void * addr)
+static inline int constant_test_bit(int nr, const volatile void *addr)
{
return ((1UL << (nr & 31)) & (((const volatile unsigned int *) addr)[nr >> 5])) != 0;
}
-static __inline__ int variable_test_bit(int nr, volatile const void * addr)
+static inline int variable_test_bit(int nr, volatile const void *addr)
{
int oldbit;
@@ -302,10 +302,10 @@ static __inline__ int variable_test_bit(
#undef ADDR
-extern long find_first_zero_bit(const unsigned long * addr, unsigned long size);
-extern long find_next_zero_bit (const unsigned long * addr, long size, long offset);
-extern long find_first_bit(const unsigned long * addr, unsigned long size);
-extern long find_next_bit(const unsigned long * addr, long size, long offset);
+extern long find_first_zero_bit(const unsigned long *addr, unsigned long size);
+extern long find_next_zero_bit(const unsigned long *addr, long size, long offset);
+extern long find_first_bit(const unsigned long *addr, unsigned long size);
+extern long find_next_bit(const unsigned long *addr, long size, long offset);
/* return index of first bet set in val or max when no bit is set */
static inline long __scanbit(unsigned long val, unsigned long max)
@@ -366,7 +366,7 @@ static inline void __clear_bit_string(un
*
* Undefined if no zero exists, so code should check against ~0UL first.
*/
-static __inline__ unsigned long ffz(unsigned long word)
+static inline unsigned long ffz(unsigned long word)
{
__asm__("bsfq %1,%0"
:"=r" (word)
@@ -380,7 +380,7 @@ static __inline__ unsigned long ffz(unsi
*
* Undefined if no bit exists, so code should check against 0 first.
*/
-static __inline__ unsigned long __ffs(unsigned long word)
+static inline unsigned long __ffs(unsigned long word)
{
__asm__("bsfq %1,%0"
:"=r" (word)
@@ -394,7 +394,7 @@ static __inline__ unsigned long __ffs(un
*
* Undefined if no zero exists, so code should check against ~0UL first.
*/
-static __inline__ unsigned long __fls(unsigned long word)
+static inline unsigned long __fls(unsigned long word)
{
__asm__("bsrq %1,%0"
:"=r" (word)
@@ -414,7 +414,7 @@ static __inline__ unsigned long __fls(un
* the libc and compiler builtin ffs routines, therefore
* differs in spirit from the above ffz (man ffs).
*/
-static __inline__ int ffs(int x)
+static inline int ffs(int x)
{
int r;
@@ -430,7 +430,7 @@ static __inline__ int ffs(int x)
*
* This is defined the same way as fls.
*/
-static __inline__ int fls64(__u64 x)
+static inline int fls64(__u64 x)
{
if (x == 0)
return 0;
@@ -443,7 +443,7 @@ static __inline__ int fls64(__u64 x)
*
* This is defined the same way as ffs.
*/
-static __inline__ int fls(int x)
+static inline int fls(int x)
{
int r;
next prev parent reply other threads:[~2007-10-25 21:27 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-24 5:09 [PATCH] bitops kernel-doc: expand macro Randy Dunlap
2007-10-24 8:00 ` Nick Piggin
2007-10-24 15:38 ` Randy Dunlap
2007-10-25 16:31 ` [PATCH v2] bitops kernel-doc: inline instead of macro Randy Dunlap
2007-10-25 16:42 ` Thomas Gleixner
2007-10-25 16:55 ` Randy Dunlap
2007-10-25 17:05 ` Thomas Gleixner
2007-10-25 20:48 ` Andrew Morton
2007-10-25 21:21 ` [PATCH v3] " Randy Dunlap
2007-10-25 21:27 ` Thomas Gleixner
2007-10-25 21:27 ` Randy Dunlap [this message]
2007-10-27 10:43 ` [PATCH v2] " Andy Whitcroft
2007-10-27 14:30 ` Andy Whitcroft
2007-10-27 18:48 ` H. Peter Anvin
2007-10-25 21:54 ` Nick Piggin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20071025142724.71d184ba.rdunlap@xenotime.net \
--to=rdunlap@xenotime.net \
--cc=akpm@linux-foundation.org \
--cc=apw@shadowen.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=nickpiggin@yahoo.com.au \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®