Currently there is an incoherent mess of atomic_{set,clear}_mask() and
atomic_or() (but no atomic_{and,nand,xor}()) in the tree.
Those archs that implement atomic_{set,clear}_mask() are not even consistent on
its signature.
Implement atomic_{or,and,xor}() on all archs and deprecate
atomic_{set,clear}_mask().
The series has been compile tested by the build-bot, no known failures at this time.
I would like to take this through tip; I'll ask Ingo to put it in a separate
branch such that people can pull in that branch if there is conflicting work
elsewhere (Will has some for Argh64).
Changes since lst time:
- Quite a few build fails fixed, most notable would be that each arch
now defines CONFIG_ARCH_HAS_ATOMIC_OR for a little while -- we take it
out again later.
- FRV has some extra magic that allows the inline assembly to correctly
work as inline functions.
- TILE patch contributed by Chris -- Thanks!
- A little extention to lib/atomic64_test.c that compile tests the new
primitives.
- Alpha, fixed ASM due to fallout from actually trying to compile things.
- H8300, somehow I had overlooked it previously.
- Added atomic_andnot() to a few archs that have that instruction to test that.
On Thu, Jul 16, 2015 at 06:21:10PM +0100, Peter Zijlstra wrote:
> Currently there is an incoherent mess of atomic_{set,clear}_mask() and
> atomic_or() (but no atomic_{and,nand,xor}()) in the tree.
>
> Those archs that implement atomic_{set,clear}_mask() are not even consistent on
> its signature.
>
> Implement atomic_{or,and,xor}() on all archs and deprecate
> atomic_{set,clear}_mask().
>
> The series has been compile tested by the build-bot, no known failures at this time.
>
> I would like to take this through tip; I'll ask Ingo to put it in a separate
> branch such that people can pull in that branch if there is conflicting work
> elsewhere (Will has some for Argh64).
Cheers, Peter. FWIW, the ARM/arm64 bits look fine to me:
Acked-by: Will Deacon <[email protected]>
Will
On Thu, Jul 16, 2015 at 07:21:10PM +0200, Peter Zijlstra wrote:
> Currently there is an incoherent mess of atomic_{set,clear}_mask() and
> atomic_or() (but no atomic_{and,nand,xor}()) in the tree.
>
> Those archs that implement atomic_{set,clear}_mask() are not even consistent on
> its signature.
>
> Implement atomic_{or,and,xor}() on all archs and deprecate
> atomic_{set,clear}_mask().
>
> The series has been compile tested by the build-bot, no known failures at this time.
>
> I would like to take this through tip; I'll ask Ingo to put it in a separate
> branch such that people can pull in that branch if there is conflicting work
> elsewhere (Will has some for Argh64).
>
>
> Changes since lst time:
>
> - Quite a few build fails fixed, most notable would be that each arch
> now defines CONFIG_ARCH_HAS_ATOMIC_OR for a little while -- we take it
> out again later.
>
> - FRV has some extra magic that allows the inline assembly to correctly
> work as inline functions.
>
> - TILE patch contributed by Chris -- Thanks!
>
> - A little extention to lib/atomic64_test.c that compile tests the new
> primitives.
>
> - Alpha, fixed ASM due to fallout from actually trying to compile things.
>
> - H8300, somehow I had overlooked it previously.
>
> - Added atomic_andnot() to a few archs that have that instruction to test that.
>
Hexagon parts built and tested fine; thanks!
Acked-by: Richard Kuo <[email protected]>
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Hi Peter, Ingo,
On Thu, Jul 16, 2015 at 06:21:10PM +0100, Peter Zijlstra wrote:
> Currently there is an incoherent mess of atomic_{set,clear}_mask() and
> atomic_or() (but no atomic_{and,nand,xor}()) in the tree.
>
> Those archs that implement atomic_{set,clear}_mask() are not even consistent on
> its signature.
>
> Implement atomic_{or,and,xor}() on all archs and deprecate
> atomic_{set,clear}_mask().
>
> The series has been compile tested by the build-bot, no known failures at this time.
>
> I would like to take this through tip; I'll ask Ingo to put it in a separate
> branch such that people can pull in that branch if there is conflicting work
> elsewhere (Will has some for Argh64).
Any joy with this branch? I'd like to put the new arm64 atomics into
-next, but it would probably be easier for everybody if I merged in this
lot first.
Cheers,
Will