| Message ID | 20210322123259.2894194-1-unixbhaskar@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | arc: include/asm: Couple of spelling fixes | expand |
On 3/22/21 5:32 AM, Bhaskar Chowdhury wrote: > > s/interrpted/interrupted/ > s/defintion/definition/ > > Signed-off-by: Bhaskar Chowdhury <unixbhaskar@gmail.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> > --- > arch/arc/include/asm/cmpxchg.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/arc/include/asm/cmpxchg.h b/arch/arc/include/asm/cmpxchg.h > index 9b87e162e539..dfeffa25499b 100644 > --- a/arch/arc/include/asm/cmpxchg.h > +++ b/arch/arc/include/asm/cmpxchg.h > @@ -116,7 +116,7 @@ static inline unsigned long __xchg(unsigned long val, volatile void *ptr, > * > * Technically the lock is also needed for UP (boils down to irq save/restore) > * but we can cheat a bit since cmpxchg() atomic_ops_lock() would cause irqs to > - * be disabled thus can't possibly be interrpted/preempted/clobbered by xchg() > + * be disabled thus can't possibly be interrupted/preempted/clobbered by xchg() > * Other way around, xchg is one instruction anyways, so can't be interrupted > * as such > */ > @@ -143,7 +143,7 @@ static inline unsigned long __xchg(unsigned long val, volatile void *ptr, > /* > * "atomic" variant of xchg() > * REQ: It needs to follow the same serialization rules as other atomic_xxx() > - * Since xchg() doesn't always do that, it would seem that following defintion > + * Since xchg() doesn't always do that, it would seem that following definition > * is incorrect. But here's the rationale: > * SMP : Even xchg() takes the atomic_ops_lock, so OK. > * LLSC: atomic_ops_lock are not relevant at all (even if SMP, since LLSC > --
diff --git a/arch/arc/include/asm/cmpxchg.h b/arch/arc/include/asm/cmpxchg.h index 9b87e162e539..dfeffa25499b 100644 --- a/arch/arc/include/asm/cmpxchg.h +++ b/arch/arc/include/asm/cmpxchg.h @@ -116,7 +116,7 @@ static inline unsigned long __xchg(unsigned long val, volatile void *ptr, * * Technically the lock is also needed for UP (boils down to irq save/restore) * but we can cheat a bit since cmpxchg() atomic_ops_lock() would cause irqs to - * be disabled thus can't possibly be interrpted/preempted/clobbered by xchg() + * be disabled thus can't possibly be interrupted/preempted/clobbered by xchg() * Other way around, xchg is one instruction anyways, so can't be interrupted * as such */ @@ -143,7 +143,7 @@ static inline unsigned long __xchg(unsigned long val, volatile void *ptr, /* * "atomic" variant of xchg() * REQ: It needs to follow the same serialization rules as other atomic_xxx() - * Since xchg() doesn't always do that, it would seem that following defintion + * Since xchg() doesn't always do that, it would seem that following definition * is incorrect. But here's the rationale: * SMP : Even xchg() takes the atomic_ops_lock, so OK. * LLSC: atomic_ops_lock are not relevant at all (even if SMP, since LLSC
s/interrpted/interrupted/ s/defintion/definition/ Signed-off-by: Bhaskar Chowdhury <unixbhaskar@gmail.com> --- arch/arc/include/asm/cmpxchg.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- 2.31.0