From: gang.chen@asianux.com (Chen Gang)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/3] arm: include: asm: atomic.h: use 'unsigned int' and 'atomic' instead of 'unsigned long' for atomic_clear_mask()
Date: Thu, 10 Oct 2013 19:02:33 +0800 [thread overview]
Message-ID: <52568949.7070603@asianux.com> (raw)
In-Reply-To: <20131010095841.GG3817@mudshark.cambridge.arm.com>
On 10/10/2013 05:58 PM, Will Deacon wrote:
> On Thu, Oct 10, 2013 at 03:34:02AM +0100, Chen Gang wrote:
>> In current kernel wide source, for arm, only s390 scsi drivers use
>> atomic_clear_mask(), now, s390 itself need use 'unsigned int' and
>> 'atomic_t', so need match s390's atomic_clear_mask().
>>
>>
>> Signed-off-by: Chen Gang <gang.chen@asianux.com>
>> ---
>> arch/arm/include/asm/atomic.h | 13 +++++++------
>> 1 files changed, 7 insertions(+), 6 deletions(-)
>>
>> diff --git a/arch/arm/include/asm/atomic.h b/arch/arm/include/asm/atomic.h
>> index da1c77d..0832a7f 100644
>> --- a/arch/arm/include/asm/atomic.h
>> +++ b/arch/arm/include/asm/atomic.h
>> @@ -134,9 +134,10 @@ static inline int atomic_cmpxchg(atomic_t *ptr, int old, int new)
>> return oldval;
>> }
>>
>> -static inline void atomic_clear_mask(unsigned long mask, unsigned long *addr)
>> +static inline void atomic_clear_mask(unsigned int mask, atomic_t *ptr)
>> {
>> - unsigned long tmp, tmp2;
>> + unsigned int tmp;
>
> I reckon this should be int (the mask parameter is unsigned, but
> atomic_t.counter is signed).
For 'ldrex' and 'strex' (loading/storing instruction), it is really
better to match 'atomic_t.counter', but for 'bic' (operating
instruction), it is better to match 'mask'.
In my opinion, for signed/unsigned, 'operating' has higher priority than
'loading/storing' (especially for *mask functions, by default, suggest
using unsigned).
Commonly, for loading/storing (e.g. 'ldrex', 'strex'), must be sure of
bits wide (signed/unsigned will not cause real issues), but for
operating, signed/unsigned may cause real issues.
>
>> + unsigned long tmp2;
>>
>> __asm__ __volatile__("@ atomic_clear_mask\n"
>> "1: ldrex %0, [%3]\n"
>> @@ -144,8 +145,8 @@ static inline void atomic_clear_mask(unsigned long mask, unsigned long *addr)
>> " strex %1, %0, [%3]\n"
>> " teq %1, #0\n"
>> " bne 1b"
>> - : "=&r" (tmp), "=&r" (tmp2), "+Qo" (*addr)
>> - : "r" (addr), "Ir" (mask)
>> + : "=&r" (tmp), "=&r" (tmp2), "+Qo" (ptr->counter)
>> + : "r" (&ptr->counter), "Ir" (mask)
>> : "cc");
>> }
>>
>> @@ -197,12 +198,12 @@ static inline int atomic_cmpxchg(atomic_t *v, int old, int new)
>> return ret;
>> }
>>
>> -static inline void atomic_clear_mask(unsigned long mask, unsigned long *addr)
>> +static inline void atomic_clear_mask(unsigned int mask, atomic_t *v)
>> {
>> unsigned long flags;
>>
>> raw_local_irq_save(flags);
>> - *addr &= ~mask;
>> + v->counter &= ~mask;
>> raw_local_irq_restore(flags);
>> }
>
> This is now identical to asm-generic/atomic.h. I wonder whether we could
> just #include that file for the ARMv6 case? You'd need to check the
> differences carefully.
>
If most of functions for ARMv6 case can use "asm-generic/atomic.h", your
idea sounds good to me, although we don't need 'atomic_set_mask' (it is
inconsistent with 'atomic_clear_mask' in "asm-generic/atomic.h").
> Finally, I still question the need for the clear_mask function anyway. We
> don't implement set_mask, and these functions are only used by either other
> arch code or in drivers that don't work on ARM anyway.
>
Hmm... can we remove atomic_*_mask() for both arm and arm64?
It seems before get a conclusion, it is necessary to let arm and arm64
pass 'allmodconfig' firstly (and then try to remove these functions to
see the compiling result).
I will/should try 'allmodconfig' for them, but excuse me, it needs
waiting (I am just trying 'arc' architecture with 'allmodconfig', and
already delayed, because I have no enough time resources on it :-( ).
> Will
>
>
Thanks.
--
Chen Gang
next prev parent reply other threads:[~2013-10-10 11:02 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-10 2:30 [PATCH 0/3] s390/arm/arm64: include: asm: atomic.h: use 'unsigned int' and 'atomic_t' instead of 'unsigned long' for atomic_*_mask() Chen Gang
2013-10-10 2:31 ` [PATCH 1/3] s390: include: asm: atomic.h: use 'unsigned int' " Chen Gang
2013-10-10 2:34 ` [PATCH 2/3] arm: include: asm: atomic.h: use 'unsigned int' and 'atomic' instead of 'unsigned long' for atomic_clear_mask() Chen Gang
2013-10-10 2:35 ` [PATCH 3/3] arm64: include: asm: atomic.h: use 'unsigned int' and 'atomic_t' " Chen Gang
2013-10-10 10:07 ` Will Deacon
2013-10-10 11:03 ` Chen Gang
2013-10-10 14:23 ` Will Deacon
2013-10-11 1:18 ` Chen Gang
2013-10-11 10:44 ` Will Deacon
2013-10-11 11:25 ` Chen Gang
2013-10-11 11:47 ` [PATCH] arm/arm64: remove atomic_clear_mask() in "include/asm/atomic.h" Chen Gang
2013-10-11 12:08 ` Richard Weinberger
2013-10-11 12:28 ` Will Deacon
2013-10-11 13:03 ` Richard Weinberger
2013-10-12 1:36 ` Chen Gang
2013-10-12 2:09 ` Chen Gang
2013-10-11 16:55 ` Will Deacon
2013-10-12 1:46 ` Chen Gang
2013-10-12 22:28 ` Catalin Marinas
2013-11-04 7:36 ` Chen Gang
2013-11-04 10:07 ` Will Deacon
2013-11-04 10:15 ` Chen Gang
2013-10-10 9:58 ` [PATCH 2/3] arm: include: asm: atomic.h: use 'unsigned int' and 'atomic' instead of 'unsigned long' for atomic_clear_mask() Will Deacon
2013-10-10 11:02 ` Chen Gang [this message]
2013-10-10 7:25 ` [PATCH 1/3] s390: include: asm: atomic.h: use 'unsigned int' instead of 'unsigned long' for atomic_*_mask() Heiko Carstens
2013-10-10 7:34 ` Chen Gang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52568949.7070603@asianux.com \
--to=gang.chen@asianux.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).