On Thu, Jan 21, 2021 at 2:18 AM Andy Shevchenko
wrote:
>
> On Wed, Jan 20, 2021 at 04:06:26PM -0800, Yury Norov wrote:
> > In the following patches of the series they are used by
> > find_bit subsystem.
>
> s/subsystem/API/
>
> ...
>
> > --- a/include
On Wed, Jan 20, 2021 at 04:06:26PM -0800, Yury Norov wrote:
> In the following patches of the series they are used by
> find_bit subsystem.
s/subsystem/API/
...
> --- a/include/linux/bitops.h
> +++ b/include/linux/bitops.h
> @@ -7,6 +7,17 @@
>
> #in
In the following patches of the series they are used by
find_bit subsystem.
Signed-off-by: Yury Norov
---
include/linux/bitmap.h | 11 ---
include/linux/bitops.h | 11 +++
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/include/linux/bitmap.h b/include/linux
---
include/linux/bitops.h | 37 +
1 file changed, 25 insertions(+), 12 deletions(-)
diff --git a/include/linux/bitops.h b/include/linux/bitops.h
index 5b74bdf159d6..f6ab611ca732 100644
--- a/include/linux/bitops.h
+++ b/include/linux/bitops.h
@@ -50,6 +50,31 @@ extern
hweight_long()
on 32-bit targets:
include/linux/bitops.h:75:41: error: shift count >= width of type
[-Werror,-Wshift-count-overflow]
return sizeof(w) == 4 ? hweight32(w) : hweight64(w);
^~~~
include/asm-generic/bitops/const_hweigh
hweight_long()
on 32-bit targets:
include/linux/bitops.h:75:41: error: shift count >= width of type
[-Werror,-Wshift-count-overflow]
return sizeof(w) == 4 ? hweight32(w) : hweight64(w);
^~~~
include/asm-generic/bitops/const_hweigh
hweight_long()
on 32-bit targets:
include/linux/bitops.h:75:41: error: shift count >= width of type
[-Werror,-Wshift-count-overflow]
return sizeof(w) == 4 ? hweight32(w) : hweight64(w);
^~~~
include/asm-generic/bitops/const_hweigh
hweight_long()
on 32-bit targets:
include/linux/bitops.h:75:41: error: shift count >= width of type
[-Werror,-Wshift-count-overflow]
return sizeof(w) == 4 ? hweight32(w) : hweight64(w);
^~~~
include/asm-generic/bitops/const_hweigh
hweight_long()
on 32-bit targets:
include/linux/bitops.h:75:41: error: shift count >= width of type
[-Werror,-Wshift-count-overflow]
return sizeof(w) == 4 ? hweight32(w) : hweight64(w);
^~~~
include/asm-generic/bitops/const_hweigh
hweight_long()
on 32-bit targets:
include/linux/bitops.h:75:41: error: shift count >= width of type
[-Werror,-Wshift-count-overflow]
return sizeof(w) == 4 ? hweight32(w) : hweight64(w);
^~~~
include/asm-generic/bitops/const_hweigh
hweight_long()
on 32-bit targets:
include/linux/bitops.h:75:41: error: shift count >= width of type
[-Werror,-Wshift-count-overflow]
return sizeof(w) == 4 ? hweight32(w) : hweight64(w);
^~~~
include/asm-generic/bitops/const_hweigh
hweight_long()
on 32-bit targets:
include/linux/bitops.h:75:41: error: shift count >= width of type
[-Werror,-Wshift-count-overflow]
return sizeof(w) == 4 ? hweight32(w) : hweight64(w);
^~~~
include/asm-generic/bitops/const_hweigh
hweight_long()
on 32-bit targets:
include/linux/bitops.h:75:41: error: shift count >= width of type
[-Werror,-Wshift-count-overflow]
return sizeof(w) == 4 ? hweight32(w) : hweight64(w);
^~~~
include/asm-generic/bitops/const_hweigh
hweight_long()
on 32-bit targets:
include/linux/bitops.h:75:41: error: shift count >= width of type
[-Werror,-Wshift-count-overflow]
return sizeof(w) == 4 ? hweight32(w) : hweight64(w);
^~~~
include/asm-generic/bitops/const_hweigh
hweight_long()
on 32-bit targets:
include/linux/bitops.h:75:41: error: shift count >= width of type
[-Werror,-Wshift-count-overflow]
return sizeof(w) == 4 ? hweight32(w) : hweight64(w);
^~~~
include/asm-generic/bitops/const_hweigh
hweight_long()
on 32-bit targets:
include/linux/bitops.h:75:41: error: shift count >= width of type
[-Werror,-Wshift-count-overflow]
return sizeof(w) == 4 ? hweight32(w) : hweight64(w);
^~~~
include/asm-generic/bitops/const_hweigh
d-off-by: Matthias Kaehlcke
Signed-off-by: Greg Kroah-Hartman
---
include/linux/bitops.h | 16
1 file changed, 8 insertions(+), 8 deletions(-)
--- a/include/linux/bitops.h
+++ b/include/linux/bitops.h
@@ -68,7 +68,7 @@ static __always_inline unsigned long hwe
*/
static i
d-off-by: Matthias Kaehlcke
Signed-off-by: Greg Kroah-Hartman
---
include/linux/bitops.h | 16
1 file changed, 8 insertions(+), 8 deletions(-)
--- a/include/linux/bitops.h
+++ b/include/linux/bitops.h
@@ -58,7 +58,7 @@ static __always_inline unsigned long hwe
*/
static i
-off-by: Greg Kroah-Hartman
---
include/linux/bitops.h | 16
1 file changed, 8 insertions(+), 8 deletions(-)
--- a/include/linux/bitops.h
+++ b/include/linux/bitops.h
@@ -60,7 +60,7 @@ static __always_inline unsigned long hwe
*/
static inline __u64 rol64(__u64 word, unsi
d-off-by: Matthias Kaehlcke
Signed-off-by: Greg Kroah-Hartman
---
include/linux/bitops.h | 16
1 file changed, 8 insertions(+), 8 deletions(-)
--- a/include/linux/bitops.h
+++ b/include/linux/bitops.h
@@ -60,7 +60,7 @@ static __always_inline unsigned long hwe
*/
static i
d-off-by: Matthias Kaehlcke
Signed-off-by: Greg Kroah-Hartman
---
include/linux/bitops.h | 16
1 file changed, 8 insertions(+), 8 deletions(-)
--- a/include/linux/bitops.h
+++ b/include/linux/bitops.h
@@ -59,7 +59,7 @@ static __always_inline unsigned long hwe
*/
static i
t; wrote:
> > >
> > > > In preparation for implementing the asm-generic atomic bitops in terms
> > > > of atomic_long_*, we need to prevent asm/atomic.h implementations from
> > > > pulling in linux/bitops.h. A common reason for this include is for the
> &g
in terms
> > > of atomic_long_*, we need to prevent asm/atomic.h implementations from
> > > pulling in linux/bitops.h. A common reason for this include is for the
> > > BITS_PER_BYTE definition, so move this and some other BIT() and masking
> > > macros int
s from
> > pulling in linux/bitops.h. A common reason for this include is for the
> > BITS_PER_BYTE definition, so move this and some other BIT() and masking
> > macros into a new header file, linux/bits.h
> >
> > --- a/include/linux/bitops.h
> > +++ b/in
On Tue, 19 Jun 2018 13:53:08 +0100 Will Deacon wrote:
> In preparation for implementing the asm-generic atomic bitops in terms
> of atomic_long_*, we need to prevent asm/atomic.h implementations from
> pulling in linux/bitops.h. A common reason for this include is for the
> B
The sh implementation of asm/cmpxchg-xchg.h pulls in linux/bitops.h
so that it can refer to BITS_PER_BYTE. It also transitively relies on
this pulling in linux/compiler.h for READ_ONCE().
Replace the #include with linux/bits.h and linux/compiler.h
Acked-by: Peter Zijlstra (Intel)
Signed-off-by
The openrisc implementation of asm/cmpxchg.h pulls in linux/bitops.h
so that it can refer to BITS_PER_BYTE. It also transitively relies on
this pulling in linux/compiler.h for READ_ONCE().
Replace the #include with linux/bits.h and linux/compiler.h
Acked-by: Peter Zijlstra (Intel)
Signed-off-by
In preparation for implementing the asm-generic atomic bitops in terms
of atomic_long_*, we need to prevent asm/atomic.h implementations from
pulling in linux/bitops.h. A common reason for this include is for the
BITS_PER_BYTE definition, so move this and some other BIT() and masking
macros into a
The openrisc implementation of asm/cmpxchg.h pulls in linux/bitops.h
so that it can refer to BITS_PER_BYTE. It also transitively relies on
this pulling in linux/compiler.h for READ_ONCE.
Replace the #include with linux/bits.h and linux/compiler.h
Signed-off-by: Will Deacon
---
arch/openrisc
In preparation for implementing the asm-generic atomic bitops in terms
of atomic_long_*, we need to prevent asm/atomic.h implementations from
pulling in linux/bitops.h. A common reason for this include is for the
BITS_PER_BYTE definition, so move this and some other BIT and masking
macros into a
The sh implementation of asm/cmpxchg-xchg.h pulls in linux/bitops.h
so that it can refer to BITS_PER_BYTE. It also transitively relies on
this pulling in linux/compiler.h for READ_ONCE.
Replace the #include with linux/bits.h and linux/compiler.h
Signed-off-by: Will Deacon
---
arch/sh/include
The sh implementation of asm/cmpxchg-xchg.h pulls in linux/bitops.h
so that it can refer to BITS_PER_BYTE. It also transitively relies on
this pulling in linux/compiler.h for READ_ONCE.
Replace the #include with linux/bits.h and linux/compiler.h
Signed-off-by: Will Deacon
---
arch/sh/include
In preparation for implementing the asm-generic atomic bitops in terms
of atomic_long_*, we need to prevent asm/atomic.h implementations from
pulling in linux/bitops.h. A common reason for this include is for the
BITS_PER_BYTE definition, so move this and some other BIT and masking
macros into a
The openrisc implementation of asm/cmpxchg.h pulls in linux/bitops.h
so that it can refer to BITS_PER_BYTE. It also transitively relies on
this pulling in linux/compiler.h for READ_ONCE.
Replace the #include with linux/bits.h and linux/compiler.h
Signed-off-by: Will Deacon
---
arch/openrisc
The openrisc implementation of asm/cmpxchg.h pulls in linux/bitops.h
so that it can refer to BITS_PER_BYTE. It also transitively relies on
this pulling in linux/compiler.h for READ_ONCE.
Replace the #include with asm-generic/bits.h and linux/compiler.h
Signed-off-by: Will Deacon
---
arch
The sh implementation of asm/cmpxchg-xchg.h pulls in linux/bitops.h
so that it can refer to BITS_PER_BYTE. It also transitively relies on
this pulling in linux/compiler.h for READ_ONCE.
Replace the #include with asm-generic/bits.h and linux/compiler.h
Signed-off-by: Will Deacon
---
arch/sh
In preparation for implementing the asm-generic atomic bitops in terms
of atomic_long_*, we need to prevent asm/atomic.h implementations from
pulling in linux/bitops.h. A common reason for this include is for the
BITS_PER_BYTE definition, so move this and some other BIT and masking
macros into a
("bitops: Add clear/set_bit32() to linux/bitops.h")
Reported-by: Peter Zijlstra
Signed-off-by: Thomas Gleixner
Cc: Andi Kleen
Signed-off-by: Greg Kroah-Hartman
---
include/linux/bitops.h | 26 --
1 file changed, 26 deletions(-)
--- a/include/linux/bito
in all callers.
Signed-off-by: Andi Kleen
Reviewed-by: Thomas Gleixner
Cc: Linus Torvalds
Cc: Peter Zijlstra
Link: http://lkml.kernel.org/r/20171013215645.23166-2-a...@firstfloor.org
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman
---
include/linux/bitops.h | 26
On Sun, Nov 5, 2017 at 7:53 AM, Heiko Carstens
wrote:
> On Tue, Oct 17, 2017 at 09:21:46AM -0700, tip-bot for Andi Kleen wrote:
>>
>> bitops: Add clear/set_bit32() to linux/bitops.h
>
> This does not work at all on 64 bit big endian machines. If e.g. the array
> would
en
> > AuthorDate: Fri, 13 Oct 2017 14:56:41 -0700
> > Committer: Ingo Molnar
> > CommitDate: Tue, 17 Oct 2017 17:14:56 +0200
> >
> > bitops: Add clear/set_bit32() to linux/bitops.h
> >
> > Add two simple wrappers around set_bit/clear_bit() that accept
700
> Committer: Ingo Molnar
> CommitDate: Tue, 17 Oct 2017 17:14:56 +0200
>
> bitops: Add clear/set_bit32() to linux/bitops.h
>
> Add two simple wrappers around set_bit/clear_bit() that accept
> the common case of an u32 array. This avoids writing
> casts in all
() to linux/bitops.h
Add two simple wrappers around set_bit/clear_bit() that accept
the common case of an u32 array. This avoids writing
casts in all callers.
Signed-off-by: Andi Kleen
Reviewed-by: Thomas Gleixner
Cc: Linus Torvalds
Cc: Peter Zijlstra
Link: http://lkml.kernel.org/r
On Fri, 13 Oct 2017, Andi Kleen wrote:
> From: Andi Kleen
>
> Add two simple wrappers around set_bit/clear_bit that accept
> the common case of an u32 array. This avoids writing
> casts in all callers.
Nice.
Reviewed-by: Thomas Gleixner
From: Andi Kleen
Add two simple wrappers around set_bit/clear_bit that accept
the common case of an u32 array. This avoids writing
casts in all callers.
Signed-off-by: Andi Kleen
---
include/linux/bitops.h | 26 ++
1 file changed, 26 insertions(+)
diff --git a/include
On May 6, 2016 1:07:13 PM PDT, Sasha Levin wrote:
>On 05/04/2016 08:30 PM, H. Peter Anvin wrote:
>> On 05/04/16 15:06, John Denker wrote:
>>> On 05/04/2016 02:56 PM, H. Peter Anvin wrote:
> Beware that shifting by an amount >= the number of bits in the
> word remains Undefined Behavior.
>>
On May 6, 2016 1:07:13 PM PDT, Sasha Levin wrote:
>On 05/04/2016 08:30 PM, H. Peter Anvin wrote:
>> On 05/04/16 15:06, John Denker wrote:
>>> On 05/04/2016 02:56 PM, H. Peter Anvin wrote:
> Beware that shifting by an amount >= the number of bits in the
> word remains Undefined Behavior.
>>
On 05/04/2016 08:48 PM, Linus Torvalds wrote:
> That said, the fact that the other cases weren't changed
> (rol64/ror64/ror32) does make that argument less interesting. Unless
> there was some particular code that actively ended up using
> "rol32(..0)" but not the other cases.
Right, the others se
On 05/04/2016 08:30 PM, H. Peter Anvin wrote:
> On 05/04/16 15:06, John Denker wrote:
>> On 05/04/2016 02:56 PM, H. Peter Anvin wrote:
Beware that shifting by an amount >= the number of bits in the
word remains Undefined Behavior.
>>
>>> This construct has been supported as a rotate since
>-- Perhaps the compiler guys could be persuaded to support
> the needed features explicitly, perhaps via a command-line
> option: -std=vanilla
> This should be a no-cost option as things stand today, but
> it helps to prevent nasty surprises in the future.
It looks LLVM has th
On 05/05/2016 03:18 PM, ty...@mit.edu wrote:
>
> So this is why I tend to take a much more pragmatic viewpoint on
> things. Sure, it makes sense to pay attention to what the C standard
> writers are trying to do to us; but if we need to suppress certain
> optimizations to write sane kernel code -
On May 5, 2016 3:18:09 PM PDT, ty...@mit.edu wrote:
>On Thu, May 05, 2016 at 05:34:50PM -0400, Sandy Harris wrote:
>>
>> I completely fail to see why tests or compiler versions should be
>> part of the discussion. The C standard says the behaviour in
>> certain cases is undefined, so a standard-co
On 05/05/2016 03:18 PM, ty...@mit.edu wrote:
> On Thu, May 05, 2016 at 05:34:50PM -0400, Sandy Harris wrote:
>>
>> I completely fail to see why tests or compiler versions should be
>> part of the discussion. The C standard says the behaviour in
>> certain cases is undefined, so a standard-compliant
On Thu, May 05, 2016 at 05:34:50PM -0400, Sandy Harris wrote:
>
> I completely fail to see why tests or compiler versions should be
> part of the discussion. The C standard says the behaviour in
> certain cases is undefined, so a standard-compliant compiler
> can generate more-or-less any code the
On Wed, May 4, 2016 at 11:50 PM, Theodore Ts'o wrote:
> Instead of arguing over who's "sane" or "insane", can we come up with
> a agreed upon set of tests, and a set of compiler and compiler
> versions ...
I completely fail to see why tests or compiler versions should be
part of the discussion.
> Suggestions:
>
> a) Going forward, I suggest that UB should not be invoked
> unless there is a good solid reason.
Good luck rewriting most of the kernel source.
This discussion is insane!
-Andi
- undefined behavior (UB)
The sizeof() example is LSO not UB. One could easily check
the sizes at compile time, so that no looseness remains.
The result is perfectly reasonable, efficient, reliable code.
Similarly, the kernel assumes two's complement arithmetic
"all over the place&quo
On 05/04/16 21:03, Jeffrey Walton wrote:
On Wed, May 4, 2016 at 11:50 PM, Theodore Ts'o wrote:
...
But instead of arguing over what works and doesn't, let's just create
the the test set and just try it on a wide range of compilers and
architectures, hmmm?
What are the requirements? Here's a s
On Wed, May 4, 2016 at 11:50 PM, Theodore Ts'o wrote:
> ...
> But instead of arguing over what works and doesn't, let's just create
> the the test set and just try it on a wide range of compilers and
> architectures, hmmm?
What are the requirements? Here's a short list:
* No undefined behavior
Instead of arguing over who's "sane" or "insane", can we come up with
a agreed upon set of tests, and a set of compiler and compiler
versions for which these tests must achieve at least *working* code?
Bonus points if they achieve optimal code, but what's important is
that for a wide range of GCC v
>>> So you are actually saying outright that we should sacrifice *actual*
>>portability in favor of *theoretical* portability? What kind of
>>twilight zone did we just step into?!
>>
>>I'm not sure what you mean. It will be well defined on all platforms.
>>Clang may not recognize the pattern, whic
On May 4, 2016 7:54:12 PM PDT, Jeffrey Walton wrote:
>On Wed, May 4, 2016 at 10:41 PM, H. Peter Anvin wrote:
>> On May 4, 2016 6:35:44 PM PDT, Jeffrey Walton
>wrote:
>>>On Wed, May 4, 2016 at 5:52 PM, John Denker wrote:
On 05/04/2016 02:42 PM, I wrote:
> I find it very odd that th
On Wed, May 4, 2016 at 10:41 PM, H. Peter Anvin wrote:
> On May 4, 2016 6:35:44 PM PDT, Jeffrey Walton wrote:
>>On Wed, May 4, 2016 at 5:52 PM, John Denker wrote:
>>> On 05/04/2016 02:42 PM, I wrote:
>>>
I find it very odd that the other seven functions were not
upgraded. I suggest the
On May 4, 2016 6:35:44 PM PDT, Jeffrey Walton wrote:
>On Wed, May 4, 2016 at 5:52 PM, John Denker wrote:
>> On 05/04/2016 02:42 PM, I wrote:
>>
>>> I find it very odd that the other seven functions were not
>>> upgraded. I suggest the attached fix-others.diff would make
>>> things more consistent
On Wed, May 4, 2016 at 5:52 PM, John Denker wrote:
> On 05/04/2016 02:42 PM, I wrote:
>
>> I find it very odd that the other seven functions were not
>> upgraded. I suggest the attached fix-others.diff would make
>> things more consistent.
>
> Here's a replacement patch.
> ...
+1, commit it.
Its
On May 4, 2016 6:20:32 PM PDT, Jeffrey Walton wrote:
>On Wed, May 4, 2016 at 7:06 PM, Andi Kleen wrote:
>> On Wed, May 04, 2016 at 03:06:04PM -0700, John Denker wrote:
>>> On 05/04/2016 02:56 PM, H. Peter Anvin wrote:
>>> >> Beware that shifting by an amount >= the number of bits in the
>>> >> wo
On Wed, May 4, 2016 at 7:06 PM, Andi Kleen wrote:
> On Wed, May 04, 2016 at 03:06:04PM -0700, John Denker wrote:
>> On 05/04/2016 02:56 PM, H. Peter Anvin wrote:
>> >> Beware that shifting by an amount >= the number of bits in the
>> >> word remains Undefined Behavior.
>>
>> > This construct has b
On Wed, May 4, 2016 at 5:30 PM, H. Peter Anvin wrote:
>
> Yes. d7e35dfa is baloney IMNSHO. All it does is produce worse code, and the
> description even says so.
>
> As I said, gcc has treated the former code as idiomatic since gcc 2, so that
> support is beyond ancient.
Well, we're *trying* to
On 05/04/16 15:06, John Denker wrote:
On 05/04/2016 02:56 PM, H. Peter Anvin wrote:
Beware that shifting by an amount >= the number of bits in the
word remains Undefined Behavior.
This construct has been supported as a rotate since at least gcc2.
How then should we understand the story told
On 05/04/2016 04:06 PM, Andi Kleen wrote:
> gcc always converts it before it could
[make a difference].
At the moment, current versions of gcc treat the idiomatic
ror/rol code as something they support ... but older versions
do not, and future version may not.
The gcc guys have made it very clea
On Wed, May 04, 2016 at 03:06:04PM -0700, John Denker wrote:
> On 05/04/2016 02:56 PM, H. Peter Anvin wrote:
> >> Beware that shifting by an amount >= the number of bits in the
> >> word remains Undefined Behavior.
>
> > This construct has been supported as a rotate since at least gcc2.
>
> How t
On 05/04/2016 02:56 PM, H. Peter Anvin wrote:
>> Beware that shifting by an amount >= the number of bits in the
>> word remains Undefined Behavior.
> This construct has been supported as a rotate since at least gcc2.
How then should we understand the story told in commit d7e35dfa?
Is the story wr
tently applied.
Beware that shifting by an amount >= the number of bits in the
word remains Undefined Behavior. This should be either documented
or fixed. It could be fixed easily enough.
diff --git a/include/linux/bitops.h b/include/linux/bitops.h
index defeaac..90f389b 100644
--
On 05/20/2015 01:50 PM, Jagan Teki wrote:
On 21 May 2015 at 01:13, Jens Axboe wrote:
On 05/20/2015 01:41 PM, Jagan Teki wrote:
On 21 May 2015 at 00:52, Jens Axboe wrote:
On 05/18/2015 01:14 PM, Jagan Teki wrote:
Replace (1 << nr) to BIT(nr) where nr = 0, 1, 2 31
I don't like it
On 21 May 2015 at 01:13, Jens Axboe wrote:
> On 05/20/2015 01:41 PM, Jagan Teki wrote:
>>
>> On 21 May 2015 at 00:52, Jens Axboe wrote:
>>>
>>> On 05/18/2015 01:14 PM, Jagan Teki wrote:
Replace (1 << nr) to BIT(nr) where nr = 0, 1, 2 31
>>>
>>>
>>>
>>> I don't like it, I think
On 05/20/2015 01:41 PM, Jagan Teki wrote:
On 21 May 2015 at 00:52, Jens Axboe wrote:
On 05/18/2015 01:14 PM, Jagan Teki wrote:
Replace (1 << nr) to BIT(nr) where nr = 0, 1, 2 31
I don't like it, I think it hurts readability.
What do you mean by don't like, using kernel defined macro
On 21 May 2015 at 00:52, Jens Axboe wrote:
> On 05/18/2015 01:14 PM, Jagan Teki wrote:
>>
>> Replace (1 << nr) to BIT(nr) where nr = 0, 1, 2 31
>
>
> I don't like it, I think it hurts readability.
What do you mean by don't like, using kernel defined macro instead of
numerical assignments hut
On 05/18/2015 01:14 PM, Jagan Teki wrote:
Replace (1 << nr) to BIT(nr) where nr = 0, 1, 2 31
I don't like it, I think it hurts readability.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More
Ping!
On 19 May 2015 at 00:44, Jagan Teki wrote:
> Replace (1 << nr) to BIT(nr) where nr = 0, 1, 2 31
>
> Signed-off-by: Jagan Teki
> Cc: Wolfram Sang
> Cc: Jens Axboe
> ---
> drivers/block/mg_disk.c | 10 +-
> drivers/block/mtip32xx/mtip32xx.c | 14 +++---
> dr
Replace (1 << nr) to BIT(nr) where nr = 0, 1, 2 31
Signed-off-by: Jagan Teki
Cc: Wolfram Sang
Cc: Jens Axboe
---
drivers/block/mg_disk.c | 10 +-
drivers/block/mtip32xx/mtip32xx.c | 14 +++---
drivers/block/ps3vram.c | 4 ++--
drivers/block/skd_main.c
80 matches
Mail list logo
