32-bit Sparc used to only allow usage of 24-bit of it's atomic_t type.
This was corrected with linux 2.6.3 when Keith M Wesolowski changed the
implementation to use the parisc approach of having an array of
spinlocks to protect the atomic_t.
These warnings were also removed from the sparc implementation when the
new implementation was merged in BKrev:402e4949VThdc6D3iaosSFUgabMfvw,
but the warning still remained in some other places without any
24-bit-only atomic_t implementation inside the kernel.
We should remove these warnings to allow users to rely on the full
32-bit range of atomic_t.
Signed-off-by: Peter Fritzsche <[email protected]>
---
This should correct the problem mentioned in http://lkml.org/lkml/2010/4/26/33
arch/mn10300/include/asm/atomic.h | 8 ++------
1 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/arch/mn10300/include/asm/atomic.h b/arch/mn10300/include/asm/atomic.h
index 5bf5be9..5b58ff8 100644
--- a/arch/mn10300/include/asm/atomic.h
+++ b/arch/mn10300/include/asm/atomic.h
@@ -28,8 +28,7 @@
* atomic_read - read atomic variable
* @v: pointer of type atomic_t
*
- * Atomically reads the value of @v. Note that the guaranteed
- * useful range of an atomic_t is only 24 bits.
+ * Atomically reads the value of @v.
*/
#define atomic_read(v) ((v)->counter)
@@ -38,8 +37,7 @@
* @v: pointer of type atomic_t
* @i: required value
*
- * Atomically sets the value of @v to @i. Note that the guaranteed
- * useful range of an atomic_t is only 24 bits.
+ * Atomically sets the value of @v to @i.
*/
#define atomic_set(v, i) (((v)->counter) = (i))
@@ -51,7 +49,6 @@
* @v: pointer of type atomic_t
*
* Atomically adds @i to @v and returns the result
- * Note that the guaranteed useful range of an atomic_t is only 24 bits.
*/
static inline int atomic_add_return(int i, atomic_t *v)
{
@@ -73,7 +70,6 @@ static inline int atomic_add_return(int i, atomic_t *v)
* @v: pointer of type atomic_t
*
* Atomically subtracts @i from @v and returns the result
- * Note that the guaranteed useful range of an atomic_t is only 24 bits.
*/
static inline int atomic_sub_return(int i, atomic_t *v)
{
--
1.7.1
* Arnd Bergmann ([email protected]) wrote:
> On Wednesday 28 April 2010, Peter Fritzsche wrote:
> > 32-bit Sparc used to only allow usage of 24-bit of it's atomic_t type.
> > This was corrected with linux 2.6.3 when Keith M Wesolowski changed the
> > implementation to use the parisc approach of having an array of
> > spinlocks to protect the atomic_t.
> >
> > These warnings were also removed from the sparc implementation when the
> > new implementation was merged in BKrev:402e4949VThdc6D3iaosSFUgabMfvw,
> > but the warning still remained in some other places without any
> > 24-bit-only atomic_t implementation inside the kernel.
> >
> > We should remove these warnings to allow users to rely on the full
> > 32-bit range of atomic_t.
> >
> > Signed-off-by: Peter Fritzsche <[email protected]>
>
> Acked-by: Arnd Bergmann <[email protected]>
AFAIK that was the last architecture imposing limitations below 32 bits
on atomic_t.
Acked-by: Mathieu Desnoyers <[email protected]>
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
Peter Fritzsche <[email protected]> wrote:
> 32-bit Sparc used to only allow usage of 24-bit of it's atomic_t type.
> This was corrected with linux 2.6.3 when Keith M Wesolowski changed the
> implementation to use the parisc approach of having an array of
> spinlocks to protect the atomic_t.
>
> These warnings were also removed from the sparc implementation when the
> new implementation was merged in BKrev:402e4949VThdc6D3iaosSFUgabMfvw,
> but the warning still remained in some other places without any
> 24-bit-only atomic_t implementation inside the kernel.
>
> We should remove these warnings to allow users to rely on the full
> 32-bit range of atomic_t.
>
> Signed-off-by: Peter Fritzsche <[email protected]>
Acked-by: David Howells <[email protected]>
From: Peter Fritzsche <[email protected]>
Date: Wed, 28 Apr 2010 13:10:36 +0200
> 32-bit Sparc used to only allow usage of 24-bit of it's atomic_t type.
> This was corrected with linux 2.6.3 when Keith M Wesolowski changed the
> implementation to use the parisc approach of having an array of
> spinlocks to protect the atomic_t.
>
> These warnings were also removed from the sparc implementation when the
> new implementation was merged in BKrev:402e4949VThdc6D3iaosSFUgabMfvw,
> but the warning still remained in some other places without any
> 24-bit-only atomic_t implementation inside the kernel.
>
> We should remove these warnings to allow users to rely on the full
> 32-bit range of atomic_t.
>
> Signed-off-by: Peter Fritzsche <[email protected]>
Acked-by: David S. Miller <[email protected]>
* Jamie Lokier ([email protected]) wrote:
> Mathieu Desnoyers wrote:
> > * Arnd Bergmann ([email protected]) wrote:
> > > On Wednesday 28 April 2010, Peter Fritzsche wrote:
> > > > 32-bit Sparc used to only allow usage of 24-bit of it's atomic_t type.
> > > > This was corrected with linux 2.6.3 when Keith M Wesolowski changed the
> > > > implementation to use the parisc approach of having an array of
> > > > spinlocks to protect the atomic_t.
> > > >
> > > > These warnings were also removed from the sparc implementation when the
> > > > new implementation was merged in BKrev:402e4949VThdc6D3iaosSFUgabMfvw,
> > > > but the warning still remained in some other places without any
> > > > 24-bit-only atomic_t implementation inside the kernel.
> > > >
> > > > We should remove these warnings to allow users to rely on the full
> > > > 32-bit range of atomic_t.
> > > >
> > > > Signed-off-by: Peter Fritzsche <[email protected]>
> > >
> > > Acked-by: Arnd Bergmann <[email protected]>
> >
> > AFAIK that was the last architecture imposing limitations below 32 bits
> > on atomic_t.
> >
> > Acked-by: Mathieu Desnoyers <[email protected]>
>
> If the comment's getting removed, it should probably go from here too:
>
> linux-2.6$ git grep '24' arch/*/include/*/atomic*
> arch/mn10300/include/asm/atomic.h: * useful range of an atomic_t is only 24 bits
> arch/mn10300/include/asm/atomic.h: * useful range of an atomic_t is only 24 bits
> arch/mn10300/include/asm/atomic.h: * Note that the guaranteed useful range of an
> arch/mn10300/include/asm/atomic.h: * Note that the guaranteed useful range of an
How about simply replacing arch/mn10300/include/asm/atomic.h by:
arch/mn10300/include/asm/atomic.h:
#include <asm-generic/atomic.h>
?
This should have been done a while ago. They are almost the same, except for
added cmpxchg*_local() in the asm-generic version (which would benefit to
mn10300).
Thanks,
Mathieu
>
> -- Jamie
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
On Wednesday 28 April 2010, Peter Fritzsche wrote:
> 32-bit Sparc used to only allow usage of 24-bit of it's atomic_t type.
> This was corrected with linux 2.6.3 when Keith M Wesolowski changed the
> implementation to use the parisc approach of having an array of
> spinlocks to protect the atomic_t.
>
> These warnings were also removed from the sparc implementation when the
> new implementation was merged in BKrev:402e4949VThdc6D3iaosSFUgabMfvw,
> but the warning still remained in some other places without any
> 24-bit-only atomic_t implementation inside the kernel.
>
> We should remove these warnings to allow users to rely on the full
> 32-bit range of atomic_t.
>
> Signed-off-by: Peter Fritzsche <[email protected]>
Acked-by: Arnd Bergmann <[email protected]>
Mathieu Desnoyers wrote:
> * Arnd Bergmann ([email protected]) wrote:
> > On Wednesday 28 April 2010, Peter Fritzsche wrote:
> > > 32-bit Sparc used to only allow usage of 24-bit of it's atomic_t type.
> > > This was corrected with linux 2.6.3 when Keith M Wesolowski changed the
> > > implementation to use the parisc approach of having an array of
> > > spinlocks to protect the atomic_t.
> > >
> > > These warnings were also removed from the sparc implementation when the
> > > new implementation was merged in BKrev:402e4949VThdc6D3iaosSFUgabMfvw,
> > > but the warning still remained in some other places without any
> > > 24-bit-only atomic_t implementation inside the kernel.
> > >
> > > We should remove these warnings to allow users to rely on the full
> > > 32-bit range of atomic_t.
> > >
> > > Signed-off-by: Peter Fritzsche <[email protected]>
> >
> > Acked-by: Arnd Bergmann <[email protected]>
>
> AFAIK that was the last architecture imposing limitations below 32 bits
> on atomic_t.
>
> Acked-by: Mathieu Desnoyers <[email protected]>
If the comment's getting removed, it should probably go from here too:
linux-2.6$ git grep '24' arch/*/include/*/atomic*
arch/mn10300/include/asm/atomic.h: * useful range of an atomic_t is only 24 bits
arch/mn10300/include/asm/atomic.h: * useful range of an atomic_t is only 24 bits
arch/mn10300/include/asm/atomic.h: * Note that the guaranteed useful range of an
arch/mn10300/include/asm/atomic.h: * Note that the guaranteed useful range of an
-- Jamie
32-bit Sparc used to only allow usage of 24-bit of it's atomic_t type.
This was corrected with linux 2.6.3 when Keith M Wesolowski changed the
implementation to use the parisc approach of having an array of
spinlocks to protect the atomic_t.
These warnings were also removed from the sparc implementation when the
new implementation was merged in BKrev:402e4949VThdc6D3iaosSFUgabMfvw,
but the warning still remained in some other places without any
24-bit-only atomic_t implementation inside the kernel.
We should remove these warnings to allow users to rely on the full
32-bit range of atomic_t.
Signed-off-by: Peter Fritzsche <[email protected]>
---
This should correct the problem mentioned in http://lkml.org/lkml/2010/4/26/33
include/asm-generic/atomic.h | 8 ++------
1 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/include/asm-generic/atomic.h b/include/asm-generic/atomic.h
index c99c64d..345bfda 100644
--- a/include/asm-generic/atomic.h
+++ b/include/asm-generic/atomic.h
@@ -30,8 +30,7 @@
* atomic_read - read atomic variable
* @v: pointer of type atomic_t
*
- * Atomically reads the value of @v. Note that the guaranteed
- * useful range of an atomic_t is only 24 bits.
+ * Atomically reads the value of @v.
*/
#define atomic_read(v) ((v)->counter)
@@ -40,8 +39,7 @@
* @v: pointer of type atomic_t
* @i: required value
*
- * Atomically sets the value of @v to @i. Note that the guaranteed
- * useful range of an atomic_t is only 24 bits.
+ * Atomically sets the value of @v to @i.
*/
#define atomic_set(v, i) (((v)->counter) = (i))
@@ -53,7 +51,6 @@
* @v: pointer of type atomic_t
*
* Atomically adds @i to @v and returns the result
- * Note that the guaranteed useful range of an atomic_t is only 24 bits.
*/
static inline int atomic_add_return(int i, atomic_t *v)
{
@@ -75,7 +72,6 @@ static inline int atomic_add_return(int i, atomic_t *v)
* @v: pointer of type atomic_t
*
* Atomically subtracts @i from @v and returns the result
- * Note that the guaranteed useful range of an atomic_t is only 24 bits.
*/
static inline int atomic_sub_return(int i, atomic_t *v)
{
--
1.7.1
On Wednesday 28 April 2010 17:28:15 you wrote:
> If the comment's getting removed, it should probably go from here too:
>
> linux-2.6$ git grep '24' arch/*/include/*/atomic*
> arch/mn10300/include/asm/atomic.h: * useful range of an atomic_t is only 24
> bits arch/mn10300/include/asm/atomic.h: * useful range of an atomic_t is
> only 24 bits arch/mn10300/include/asm/atomic.h: * Note that the guaranteed
> useful range of an arch/mn10300/include/asm/atomic.h: * Note that the
> guaranteed useful range of an
This is part one of the patch - already sent to the mn10300 people. Currently
only got Acked reponses for both patches
Best regards,
Peter Fritzsche
Mathieu Desnoyers <[email protected]> wrote:
> How about simply replacing arch/mn10300/include/asm/atomic.h by:
>
> arch/mn10300/include/asm/atomic.h:
> #include <asm-generic/atomic.h>
>
> ?
>
> This should have been done a while ago. They are almost the same, except for
> added cmpxchg*_local() in the asm-generic version (which would benefit to
> mn10300).
Fine by me.
David
* David Howells ([email protected]) wrote:
> Mathieu Desnoyers <[email protected]> wrote:
>
> > How about simply replacing arch/mn10300/include/asm/atomic.h by:
> >
> > arch/mn10300/include/asm/atomic.h:
> > #include <asm-generic/atomic.h>
> >
> > ?
> >
> > This should have been done a while ago. They are almost the same, except for
> > added cmpxchg*_local() in the asm-generic version (which would benefit to
> > mn10300).
>
> Fine by me.
Then I'll let Peter Fritzsche deal with that. I don't want to conflict with his
current patches.
Thanks,
Mathieu
>
> David
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
Mathieu Desnoyers wrote:
> * David Howells ([email protected]) wrote:
> > Mathieu Desnoyers <[email protected]> wrote:
> > > How about simply replacing arch/mn10300/include/asm/atomic.h by:
> > >
> > > arch/mn10300/include/asm/atomic.h:
> > > #include <asm-generic/atomic.h>
> > >
> > > ?
> > >
> > > This should have been done a while ago. They are almost the same,
> > > except for added cmpxchg*_local() in the asm-generic version (which
> > > would benefit to mn10300).
> >
> > Fine by me.
>
> Then I'll let Peter Fritzsche deal with that. I don't want to conflict with
> his current patches.
No, please go for your solution. It is the right thing to do and definitely
better then my "remove some comments" patch. David Howells as MN10300
maintainer already agreed to your suggestion. So I would like to recall my
patch https://patchwork.kernel.org/patch/95651/ and let you submit a patch
with your idea to the MN10300 maintainers which supersede my patch.
The state of https://patchwork.kernel.org/patch/95652/ hasn't been changed and
I would love to see it merged by Arnd Bergmann in the next merge window.
Kind regards,
Peter Fritzsche