Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit 8a449718 authored by Alexander Duyck's avatar Alexander Duyck Committed by David S. Miller
Browse files

arch: Cleanup read_barrier_depends() and comments 



This patch is meant to cleanup the handling of read_barrier_depends and
smp_read_barrier_depends.  In multiple spots in the kernel headers
read_barrier_depends is defined as "do {} while (0)", however we then go
into the SMP vs non-SMP sections and have the SMP version reference
read_barrier_depends, and the non-SMP define it as yet another empty
do/while.

With this commit I went through and cleaned out the duplicate definitions
and reduced the number of definitions down to 2 per header.  In addition I
moved the 50 line comments for the macro from the x86 and mips headers that
defined it as an empty do/while to those that were actually defining the
macro, alpha and blackfin.

Signed-off-by: default avatarAlexander Duyck <alexander.h.duyck@redhat.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
parent c11a9009

arch/alpha/include/asm/barrier.h

+51 −0
Original line number Diff line number Diff line
@@ -7,6 +7,57 @@ 
#define rmb()	__asm__ __volatile__("mb": : :"memory")

#define wmb()	__asm__ __volatile__("wmb": : :"memory")



/**

 * read_barrier_depends - Flush all pending reads that subsequents reads

 * depend on.

 *

 * No data-dependent reads from memory-like regions are ever reordered

 * over this barrier.  All reads preceding this primitive are guaranteed

 * to access memory (but not necessarily other CPUs' caches) before any

 * reads following this primitive that depend on the data return by

 * any of the preceding reads.  This primitive is much lighter weight than

 * rmb() on most CPUs, and is never heavier weight than is

 * rmb().

 *

 * These ordering constraints are respected by both the local CPU

 * and the compiler.

 *

 * Ordering is not guaranteed by anything other than these primitives,

 * not even by data dependencies.  See the documentation for

 * memory_barrier() for examples and URLs to more information.

 *

 * For example, the following code would force ordering (the initial

 * value of "a" is zero, "b" is one, and "p" is "&a"):

 *

 * <programlisting>

 *	CPU 0				CPU 1

 *

 *	b = 2;

 *	memory_barrier();

 *	p = &b;				q = p;

 *					read_barrier_depends();

 *					d = *q;

 * </programlisting>

 *

 * because the read of "*q" depends on the read of "p" and these

 * two reads are separated by a read_barrier_depends().  However,

 * the following code, with the same initial values for "a" and "b":

 *

 * <programlisting>

 *	CPU 0				CPU 1

 *

 *	a = 2;

 *	memory_barrier();

 *	b = 3;				y = b;

 *					read_barrier_depends();

 *					x = a;

 * </programlisting>

 *

 * does not enforce ordering, since there is no data dependency between

 * the read of "a" and the read of "b".  Therefore, on some CPUs, such

 * as Alpha, "y" could be set to 3 and "x" to 0.  Use rmb()

 * in cases like this where there are no data dependencies.

 */

#define read_barrier_depends() __asm__ __volatile__("mb": : :"memory")



#ifdef CONFIG_SMP

arch/blackfin/include/asm/barrier.h

+51 −0
Original line number Diff line number Diff line
@@ -22,6 +22,57 @@ 
# define mb()	do { barrier(); smp_check_barrier(); smp_mark_barrier(); } while (0)

# define rmb()	do { barrier(); smp_check_barrier(); } while (0)

# define wmb()	do { barrier(); smp_mark_barrier(); } while (0)

/*

 * read_barrier_depends - Flush all pending reads that subsequents reads

 * depend on.

 *

 * No data-dependent reads from memory-like regions are ever reordered

 * over this barrier.  All reads preceding this primitive are guaranteed

 * to access memory (but not necessarily other CPUs' caches) before any

 * reads following this primitive that depend on the data return by

 * any of the preceding reads.  This primitive is much lighter weight than

 * rmb() on most CPUs, and is never heavier weight than is

 * rmb().

 *

 * These ordering constraints are respected by both the local CPU

 * and the compiler.

 *

 * Ordering is not guaranteed by anything other than these primitives,

 * not even by data dependencies.  See the documentation for

 * memory_barrier() for examples and URLs to more information.

 *

 * For example, the following code would force ordering (the initial

 * value of "a" is zero, "b" is one, and "p" is "&a"):

 *

 * <programlisting>

 *	CPU 0				CPU 1

 *

 *	b = 2;

 *	memory_barrier();

 *	p = &b;				q = p;

 *					read_barrier_depends();

 *					d = *q;

 * </programlisting>

 *

 * because the read of "*q" depends on the read of "p" and these

 * two reads are separated by a read_barrier_depends().  However,

 * the following code, with the same initial values for "a" and "b":

 *

 * <programlisting>

 *	CPU 0				CPU 1

 *

 *	a = 2;

 *	memory_barrier();

 *	b = 3;				y = b;

 *					read_barrier_depends();

 *					x = a;

 * </programlisting>

 *

 * does not enforce ordering, since there is no data dependency between

 * the read of "a" and the read of "b".  Therefore, on some CPUs, such

 * as Alpha, "y" could be set to 3 and "x" to 0.  Use rmb()

 * in cases like this where there are no data dependencies.

 */

# define read_barrier_depends()	do { barrier(); smp_check_barrier(); } while (0)

#endif

arch/ia64/include/asm/barrier.h

+9 −13
Original line number Diff line number Diff line
@@ -38,23 +38,19 @@ 
#define mb()		ia64_mf()

#define rmb()		mb()

#define wmb()		mb()

#define read_barrier_depends()	do { } while(0)



#ifdef CONFIG_SMP

# define smp_mb()	mb()

# define smp_rmb()	rmb()

# define smp_wmb()	wmb()

# define smp_read_barrier_depends()	read_barrier_depends()



#else



# define smp_mb()	barrier()

# define smp_rmb()	barrier()

# define smp_wmb()	barrier()

# define smp_read_barrier_depends()	do { } while(0)



#endif



#define smp_rmb()	smp_mb()

#define smp_wmb()	smp_mb()



#define read_barrier_depends()		do { } while (0)

#define smp_read_barrier_depends()	do { } while (0)



#define smp_mb__before_atomic()	barrier()

#define smp_mb__after_atomic()	barrier()

arch/metag/include/asm/barrier.h

+4 −3
Original line number Diff line number Diff line
@@ -47,8 +47,6 @@ static inline void wmb(void) 
	wr_fence();

}



#define read_barrier_depends()  do { } while (0)



#ifndef CONFIG_SMP

#define fence()		do { } while (0)

#define smp_mb()        barrier()
@@ -82,7 +80,10 @@ static inline void fence(void) 
#define smp_wmb()       barrier()

#endif

#endif



#define read_barrier_depends()		do { } while (0)

#define smp_read_barrier_depends()	do { } while (0)



#define set_mb(var, value) do { var = value; smp_mb(); } while (0)



#define smp_store_release(p, v)						\

arch/mips/include/asm/barrier.h

+0 −52
Original line number Diff line number Diff line
@@ -10,58 +10,6 @@ 


#include <asm/addrspace.h>



/*

 * read_barrier_depends - Flush all pending reads that subsequents reads

 * depend on.

 *

 * No data-dependent reads from memory-like regions are ever reordered

 * over this barrier.  All reads preceding this primitive are guaranteed

 * to access memory (but not necessarily other CPUs' caches) before any

 * reads following this primitive that depend on the data return by

 * any of the preceding reads.  This primitive is much lighter weight than

 * rmb() on most CPUs, and is never heavier weight than is

 * rmb().

 *

 * These ordering constraints are respected by both the local CPU

 * and the compiler.

 *

 * Ordering is not guaranteed by anything other than these primitives,

 * not even by data dependencies.  See the documentation for

 * memory_barrier() for examples and URLs to more information.

 *

 * For example, the following code would force ordering (the initial

 * value of "a" is zero, "b" is one, and "p" is "&a"):

 *

 * <programlisting>

 *	CPU 0				CPU 1

 *

 *	b = 2;

 *	memory_barrier();

 *	p = &b;				q = p;

 *					read_barrier_depends();

 *					d = *q;

 * </programlisting>

 *

 * because the read of "*q" depends on the read of "p" and these

 * two reads are separated by a read_barrier_depends().  However,

 * the following code, with the same initial values for "a" and "b":

 *

 * <programlisting>

 *	CPU 0				CPU 1

 *

 *	a = 2;

 *	memory_barrier();

 *	b = 3;				y = b;

 *					read_barrier_depends();

 *					x = a;

 * </programlisting>

 *

 * does not enforce ordering, since there is no data dependency between

 * the read of "a" and the read of "b".  Therefore, on some CPUs, such

 * as Alpha, "y" could be set to 3 and "x" to 0.  Use rmb()

 * in cases like this where there are no data dependencies.

 */



#define read_barrier_depends()		do { } while(0)

#define smp_read_barrier_depends()	do { } while(0)