[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20190522132250.26499-17-mark.rutland@arm.com>
Date: Wed, 22 May 2019 14:22:48 +0100
From: Mark Rutland <mark.rutland@....com>
To: linux-kernel@...r.kernel.org, peterz@...radead.org,
will.deacon@....com
Cc: aou@...s.berkeley.edu, arnd@...db.de, bp@...en8.de,
catalin.marinas@....com, davem@...emloft.net, fenghua.yu@...el.com,
heiko.carstens@...ibm.com, herbert@...dor.apana.org.au,
ink@...assic.park.msu.ru, jhogan@...nel.org, linux@...linux.org.uk,
mark.rutland@....com, mattst88@...il.com, mingo@...nel.org,
mpe@...erman.id.au, palmer@...ive.com, paul.burton@...s.com,
paulus@...ba.org, ralf@...ux-mips.org, rth@...ddle.net,
stable@...r.kernel.org, tglx@...utronix.de, tony.luck@...el.com,
vgupta@...opsys.com
Subject: [PATCH 16/18] locking/atomic: use s64 for atomic64_t on 64-bit
Now that all architectures use 64 consistently as the base type for the
atomic64 API, let's have the CONFIG_64BIT definition of atomic64_t use
s64 as the underlying type for atomic64_t, rather than long, matching
the generated headers.
On architectures where atomic64_read(v) is READ_ONCE(v->counter), this
patch will cause the return type of atomic64_read() to be s64.
As of this patch, the atomic64 API can be relied upon to consistently
return s64 where a value rather than boolean condition is returned. This
should make code more robust, and simpler, allowing for the removal of
casts previously required to ensure consistent types.
Signed-off-by: Mark Rutland <mark.rutland@....com>
Cc: Peter Zijlstra <peterz@...radead.org>
Cc: Will Deacon <will.deacon@....com>
---
include/linux/types.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/types.h b/include/linux/types.h
index 231114ae38f4..05030f608be3 100644
--- a/include/linux/types.h
+++ b/include/linux/types.h
@@ -174,7 +174,7 @@ typedef struct {
#ifdef CONFIG_64BIT
typedef struct {
- long counter;
+ s64 counter;
} atomic64_t;
#endif
--
2.11.0
Powered by blists - more mailing lists