ARM: 8135/1: Fix in-correct barrier usage in SWP{B} emulation

According to the ARM ARMv7, explicit barriers are necessary when using
synchronisation primitives such as SWP{B}. The use of these
instructions does not automatically imply a barrier and any ordering
requirements by the software must be explicitly expressed with the use
of suitable barriers.

Based on this, remove the barriers from SWP{B} emulation.

Acked-by: Will Deacon <[email protected]>
Signed-off-by: Punit Agrawal <[email protected]>
Signed-off-by: Russell King <[email protected]>

diff --git a/arch/arm/kernel/swp_emulate.c b/arch/arm/kernel/swp_emulate.c
index 67ca8578c6d8fd9adf35cfebbe0d75cdda8d4786..587fdfe1a72cdb6c582ee03d455ec391dd456a83 100644 (file)
--- a/arch/arm/kernel/swp_emulate.c
+++ b/arch/arm/kernel/swp_emulate.c
@@ -142,14 +142,6 @@ static int emulate_swpX(unsigned int address, unsigned int *data,
        while (1) {
                unsigned long temp;
 
-               /*
-                * Barrier required between accessing protected resource and
-                * releasing a lock for it. Legacy code might not have done
-                * this, and we cannot determine that this is not the case
-                * being emulated, so insert always.
-                */
-               smp_mb();
-
                if (type == TYPE_SWPB)
                        __user_swpb_asm(*data, address, res, temp);
                else
@@ -162,13 +154,6 @@ static int emulate_swpX(unsigned int address, unsigned int *data,
        }
 
        if (res == 0) {
-               /*
-                * Barrier also required between acquiring a lock for a
-                * protected resource and accessing the resource. Inserted for
-                * same reason as above.
-                */
-               smp_mb();
-
                if (type == TYPE_SWPB)
                        swpbcounter++;
                else