[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <158349114313.28353.2410503196690088637.tip-bot2@tip-bot2>
Date: Fri, 06 Mar 2020 10:39:03 -0000
From: "tip-bot2 for Will Deacon" <tip-bot2@...utronix.de>
To: linux-tip-commits@...r.kernel.org
Cc: Stefan Asserhall <stefana@...inx.com>,
Will Deacon <will@...nel.org>,
"Peter Zijlstra (Intel)" <peterz@...radead.org>,
x86 <x86@...nel.org>, LKML <linux-kernel@...r.kernel.org>
Subject: [tip: locking/core] asm-generic/bitops: Update stale comment
The following commit has been merged into the locking/core branch of tip:
Commit-ID: 5d0c9b0eb8ab2dd540919174abe75aa3b86b802f
Gitweb: https://git.kernel.org/tip/5d0c9b0eb8ab2dd540919174abe75aa3b86b802f
Author: Will Deacon <will@...nel.org>
AuthorDate: Thu, 13 Feb 2020 09:39:27
Committer: Peter Zijlstra <peterz@...radead.org>
CommitterDate: Fri, 06 Mar 2020 11:06:19 +01:00
asm-generic/bitops: Update stale comment
The comment in 'asm-generic/bitops.h' states that you should "recode
these in the native assembly language, if at all possible". This is
pretty crappy advice now that the generic implementation is defined in
terms of atomic_long_t rather than a spinlock, so update the comment and
hopefully save future architecture maintainers a bit of work.
Reported-by: Stefan Asserhall <stefana@...inx.com>
Signed-off-by: Will Deacon <will@...nel.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@...radead.org>
Link: https://lkml.kernel.org/r/20200213093927.1836-1-will@kernel.org
---
include/asm-generic/bitops.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/include/asm-generic/bitops.h b/include/asm-generic/bitops.h
index bfc96bf..df9b5bc 100644
--- a/include/asm-generic/bitops.h
+++ b/include/asm-generic/bitops.h
@@ -4,8 +4,9 @@
/*
* For the benefit of those who are trying to port Linux to another
- * architecture, here are some C-language equivalents. You should
- * recode these in the native assembly language, if at all possible.
+ * architecture, here are some C-language equivalents. They should
+ * generate reasonable code, so take a look at what your compiler spits
+ * out before rolling your own buggy implementation in assembly language.
*
* C language equivalents written by Theodore Ts'o, 9/26/92
*/
Powered by blists - more mailing lists