* [PATCH 14/15] bitops: Change the bitmap index from int to unsigned long [frv]
@ 2009-02-25 4:52 Justin Chen
2009-02-25 12:37 ` David Howells
0 siblings, 1 reply; 8+ messages in thread
From: Justin Chen @ 2009-02-25 4:52 UTC (permalink / raw)
To: linux-arch; +Cc: bjorn.helgaas, dhowells, justin.chen, linux-kernel
Change the index to unsigned long in all bitops for [frv]
Signed-off-by: Justin Chen <justin.chen@hp.com>
Reviewed-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
---
include/asm-frv/bitops.h | 29 +++++++++++++++--------------
1 file changed, 15 insertions(+), 14 deletions(-)
diff -Nru a/include/asm-frv/bitops.h b/include/asm-frv/bitops.h
--- a/include/asm-frv/bitops.h 2009-02-13 15:31:30.000000000 -0800
+++ b/include/asm-frv/bitops.h 2009-02-15 18:19:39.789134772 -0800
@@ -112,7 +112,7 @@
#define atomic_clear_mask(mask, v) atomic_test_and_ANDNOT_mask((mask), (v))
#define atomic_set_mask(mask, v) atomic_test_and_OR_mask((mask), (v))
-static inline int test_and_clear_bit(int nr, volatile void *addr)
+static inline int test_and_clear_bit(unsigned long nr, volatile void *addr)
{
volatile unsigned long *ptr = addr;
unsigned long mask = 1UL << (nr & 31);
@@ -120,7 +120,7 @@
return (atomic_test_and_ANDNOT_mask(mask, ptr) & mask) != 0;
}
-static inline int test_and_set_bit(int nr, volatile void *addr)
+static inline int test_and_set_bit(unsigned long nr, volatile void *addr)
{
volatile unsigned long *ptr = addr;
unsigned long mask = 1UL << (nr & 31);
@@ -128,7 +128,7 @@
return (atomic_test_and_OR_mask(mask, ptr) & mask) != 0;
}
-static inline int test_and_change_bit(int nr, volatile void *addr)
+static inline int test_and_change_bit(unsigned long nr, volatile void *addr)
{
volatile unsigned long *ptr = addr;
unsigned long mask = 1UL << (nr & 31);
@@ -136,22 +136,22 @@
return (atomic_test_and_XOR_mask(mask, ptr) & mask) != 0;
}
-static inline void clear_bit(int nr, volatile void *addr)
+static inline void clear_bit(unsigned long nr, volatile void *addr)
{
test_and_clear_bit(nr, addr);
}
-static inline void set_bit(int nr, volatile void *addr)
+static inline void set_bit(unsigned long nr, volatile void *addr)
{
test_and_set_bit(nr, addr);
}
-static inline void change_bit(int nr, volatile void * addr)
+static inline void change_bit(unsigned long nr, volatile void *addr)
{
test_and_change_bit(nr, addr);
}
-static inline void __clear_bit(int nr, volatile void * addr)
+static inline void __clear_bit(unsigned long nr, volatile void *addr)
{
volatile unsigned long *a = addr;
int mask;
@@ -161,7 +161,7 @@
*a &= ~mask;
}
-static inline void __set_bit(int nr, volatile void * addr)
+static inline void __set_bit(unsigned long nr, volatile void *addr)
{
volatile unsigned long *a = addr;
int mask;
@@ -171,7 +171,7 @@
*a |= mask;
}
-static inline void __change_bit(int nr, volatile void *addr)
+static inline void __change_bit(unsigned long nr, volatile void *addr)
{
volatile unsigned long *a = addr;
int mask;
@@ -181,7 +181,7 @@
*a ^= mask;
}
-static inline int __test_and_clear_bit(int nr, volatile void * addr)
+static inline int __test_and_clear_bit(unsigned long nr, volatile void *addr)
{
volatile unsigned long *a = addr;
int mask, retval;
@@ -193,7 +193,7 @@
return retval;
}
-static inline int __test_and_set_bit(int nr, volatile void * addr)
+static inline int __test_and_set_bit(unsigned long nr, volatile void *addr)
{
volatile unsigned long *a = addr;
int mask, retval;
@@ -205,7 +205,7 @@
return retval;
}
-static inline int __test_and_change_bit(int nr, volatile void * addr)
+static inline int __test_and_change_bit(unsigned long nr, volatile void *addr)
{
volatile unsigned long *a = addr;
int mask, retval;
@@ -220,12 +220,13 @@
/*
* This routine doesn't need to be atomic.
*/
-static inline int __constant_test_bit(int nr, const volatile void * addr)
+static inline int
+__constant_test_bit(unsigned long nr, const volatile void *addr)
{
return ((1UL << (nr & 31)) & (((const volatile unsigned int *) addr)[nr >> 5])) != 0;
}
-static inline int __test_bit(int nr, const volatile void * addr)
+static inline int __test_bit(unsigned long nr, const volatile void *addr)
{
int * a = (int *) addr;
int mask;
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 14/15] bitops: Change the bitmap index from int to unsigned long [frv]
2009-02-25 4:52 [PATCH 14/15] bitops: Change the bitmap index from int to unsigned long [frv] Justin Chen
@ 2009-02-25 12:37 ` David Howells
2009-02-25 22:33 ` H. Peter Anvin
0 siblings, 1 reply; 8+ messages in thread
From: David Howells @ 2009-02-25 12:37 UTC (permalink / raw)
To: Justin Chen
Cc: dhowells, linux-arch, bjorn.helgaas, justin.chen, linux-kernel
Justin Chen <jchen@hpdst41.cup.hp.com> wrote:
> Change the index to unsigned long in all bitops for [frv]
>
> Signed-off-by: Justin Chen <justin.chen@hp.com>
> Reviewed-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Mostly okay, apart from:
> -static inline int __constant_test_bit(int nr, const volatile void * addr)
> +static inline int
> +__constant_test_bit(unsigned long nr, const volatile void *addr)
Please move the return type onto the next line also. Other than that:
Acked-by: David Howells <dhowells@redhat.com>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 14/15] bitops: Change the bitmap index from int to unsigned long [frv]
2009-02-25 12:37 ` David Howells
@ 2009-02-25 22:33 ` H. Peter Anvin
2009-02-25 23:50 ` David Howells
0 siblings, 1 reply; 8+ messages in thread
From: H. Peter Anvin @ 2009-02-25 22:33 UTC (permalink / raw)
To: David Howells
Cc: Justin Chen, linux-arch, bjorn.helgaas, justin.chen, linux-kernel
David Howells wrote:
>
>> -static inline int __constant_test_bit(int nr, const volatile void * addr)
>> +static inline int
>> +__constant_test_bit(unsigned long nr, const volatile void *addr)
>
> Please move the return type onto the next line also. Other than that:
>
> Acked-by: David Howells <dhowells@redhat.com>
What makes you say that, in particular? A casual grep finds no less
than 3524 instances of "static inline <type>" -- presumably with a
function name following -- and only 447 instances of "static inline"
without a type in the kernel.
-hpa
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 14/15] bitops: Change the bitmap index from int to unsigned long [frv]
2009-02-25 22:33 ` H. Peter Anvin
@ 2009-02-25 23:50 ` David Howells
2009-02-26 0:55 ` H. Peter Anvin
2009-02-26 0:57 ` H. Peter Anvin
0 siblings, 2 replies; 8+ messages in thread
From: David Howells @ 2009-02-25 23:50 UTC (permalink / raw)
To: H. Peter Anvin
Cc: dhowells, Justin Chen, linux-arch, bjorn.helgaas, justin.chen,
linux-kernel
H. Peter Anvin <hpa@zytor.com> wrote:
> What makes you say that, in particular?
I prefer it. Actually, I'd prefer it all to be on one line, but some people
get picky about the 80 char limit.
Besides, that "static inline" is merely a qualifier to the declaration of the
function. The return type, name and args are part of the declaration of the
function and belong together more.
> A casual grep finds no less than 3524 instances of "static inline <type>" --
> presumably with a function name following -- and only 447 instances of
> "static inline" without a type in the kernel.
But how does it break down between "static inline type\nfunction_name" and
"static inline\ntype function_name"? That's more to the point.
David
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 14/15] bitops: Change the bitmap index from int to unsigned long [frv]
2009-02-25 23:50 ` David Howells
@ 2009-02-26 0:55 ` H. Peter Anvin
2009-02-26 1:37 ` David Howells
2009-02-26 0:57 ` H. Peter Anvin
1 sibling, 1 reply; 8+ messages in thread
From: H. Peter Anvin @ 2009-02-26 0:55 UTC (permalink / raw)
To: David Howells
Cc: Justin Chen, linux-arch, bjorn.helgaas, justin.chen, linux-kernel
David Howells wrote:
>
>> A casual grep finds no less than 3524 instances of "static inline <type>" --
>> presumably with a function name following -- and only 447 instances of
>> "static inline" without a type in the kernel.
>
> But how does it break down between "static inline type\nfunction_name" and
> "static inline\ntype function_name"? That's more to the point.
>
I believe that is the breakdown is roughly what you see above, i.e. over
8:1; the pattern I used was looking for "^static inline[^;(]*$", and a
visual examination of the results shows that even if my line count is
slighly off the lopsidedness is still dramatic.
-hpa
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 14/15] bitops: Change the bitmap index from int to unsigned long [frv]
2009-02-25 23:50 ` David Howells
2009-02-26 0:55 ` H. Peter Anvin
@ 2009-02-26 0:57 ` H. Peter Anvin
1 sibling, 0 replies; 8+ messages in thread
From: H. Peter Anvin @ 2009-02-26 0:57 UTC (permalink / raw)
To: David Howells
Cc: Justin Chen, linux-arch, bjorn.helgaas, justin.chen, linux-kernel
David Howells wrote:
>
>> A casual grep finds no less than 3524 instances of "static inline <type>" --
>> presumably with a function name following -- and only 447 instances of
>> "static inline" without a type in the kernel.
>
> But how does it break down between "static inline type\nfunction_name" and
> "static inline\ntype function_name"? That's more to the point.
>
I believe that is the breakdown is roughly what you see above, i.e. over
8:1; the pattern I used was looking for "^static inline[^;(]*$", and a
visual examination of the results shows that even if my line count is
slighly off the lopsidedness is still dramatic.
-hpa
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 14/15] bitops: Change the bitmap index from int to unsigned long [frv]
2009-02-26 0:55 ` H. Peter Anvin
@ 2009-02-26 1:37 ` David Howells
2009-02-26 1:43 ` H. Peter Anvin
0 siblings, 1 reply; 8+ messages in thread
From: David Howells @ 2009-02-26 1:37 UTC (permalink / raw)
To: H. Peter Anvin
Cc: dhowells, Justin Chen, linux-arch, bjorn.helgaas, justin.chen,
linux-kernel
H. Peter Anvin <hpa@zytor.com> wrote:
> > But how does it break down between "static inline type\nfunction_name" and
> > "static inline\ntype function_name"? That's more to the point.
> >
>
> I believe that is the breakdown is roughly what you see above, i.e. over 8:1;
> the pattern I used was looking for "^static inline[^;(]*$", and a visual
> examination of the results shows that even if my line count is slighly off the
> lopsidedness is still dramatic.
Sorry, I meant:
"static inline type\nfunction_name" vs "static inline type function_name"
David
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 14/15] bitops: Change the bitmap index from int to unsigned long [frv]
2009-02-26 1:37 ` David Howells
@ 2009-02-26 1:43 ` H. Peter Anvin
0 siblings, 0 replies; 8+ messages in thread
From: H. Peter Anvin @ 2009-02-26 1:43 UTC (permalink / raw)
To: David Howells
Cc: Justin Chen, linux-arch, bjorn.helgaas, justin.chen, linux-kernel
David Howells wrote:
> H. Peter Anvin <hpa@zytor.com> wrote:
>
>>> But how does it break down between "static inline type\nfunction_name" and
>>> "static inline\ntype function_name"? That's more to the point.
>>>
>> I believe that is the breakdown is roughly what you see above, i.e. over 8:1;
>> the pattern I used was looking for "^static inline[^;(]*$", and a visual
>> examination of the results shows that even if my line count is slighly off the
>> lopsidedness is still dramatic.
>
> Sorry, I meant:
>
> "static inline type\nfunction_name" vs "static inline type function_name"
>
Well, the latter is obviously in vast majority, but that doesn't seem to
have anything to do with anything at all here...
-hpa
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2009-02-26 1:50 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-02-25 4:52 [PATCH 14/15] bitops: Change the bitmap index from int to unsigned long [frv] Justin Chen
2009-02-25 12:37 ` David Howells
2009-02-25 22:33 ` H. Peter Anvin
2009-02-25 23:50 ` David Howells
2009-02-26 0:55 ` H. Peter Anvin
2009-02-26 1:37 ` David Howells
2009-02-26 1:43 ` H. Peter Anvin
2009-02-26 0:57 ` H. Peter Anvin
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox