luck/tmp_suning_uos_patched
1
0
Fork 1
Code Issues Pull Requests Packages Projects Releases Wiki Activity

locking/atomic, arch/m68k: Remove comment

Browse Source 
I misread the inline asm. It uses a rare construct to provide an input
to a previously declared output to do the atomic_read().

Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Andreas Schwab <schwab@linux-m68k.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Cc: linux-m68k@lists.linux-m68k.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
This commit is contained in:
Peter Zijlstra 2016-06-17 17:05:38 +02:00 committed by Ingo Molnar
parent 4aef66c8ae
commit 86a664d58f
1 changed files with 0 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
arch/m68k/include/asm/atomic.h
View File

@ -38,13 +38,6 @@ static inline void atomic_##op(int i, atomic_t *v) \
#ifdef CONFIG_RMW_INSNS
/*
* Am I reading these CAS loops right in that %2 is the old value and the first
* iteration uses an uninitialized value?
*
* Would it not make sense to add: tmp = atomic_read(v); to avoid this?
*/
#define ATOMIC_OP_RETURN(op, c_op, asm_op) \
static inline int atomic_##op##_return(int i, atomic_t *v) \
{ \