From: Stephen Rothwell <sfr@canb•auug.org.au>
To: Arnd Bergmann <arnd@arndb•de>
Cc: Thomas Gleixner <tglx@linutronix•de>, Ingo Molnar <mingo@elte•hu>,
"H. Peter Anvin" <hpa@zytor•com>,
Peter Zijlstra <peterz@infradead•org>,
Linux Kernel Mailing List <linux-kernel@vger•kernel.org>,
Linux Next Mailing List <linux-next@vger•kernel.org>,
Mark Rutland <mark.rutland@arm•com>,
Vineet Gupta <Vineet.Gupta1@synopsys•com>,
Vineet Gupta <vgupta@synopsys•com>
Subject: Re: linux-next: manual merge of the tip tree with the asm-generic tree
Date: Wed, 1 Sep 2021 13:20:18 +1000 [thread overview]
Message-ID: <20210901132018.1fc8ec5d@canb.auug.org.au> (raw)
In-Reply-To: <20210816114740.77c20b3c@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 4848 bytes --]
Hi all,
On Mon, 16 Aug 2021 11:47:40 +1000 Stephen Rothwell <sfr@canb•auug.org.au> wrote:
>
> Today's linux-next merge of the tip tree got a conflict in:
>
> include/asm-generic/bitops/non-atomic.h
>
> between commit:
>
> 8f76f9c46952 ("bitops/non-atomic: make @nr unsigned to avoid any DIV")
>
> from the asm-generic tree and commit:
>
> cf3ee3c8c29d ("locking/atomic: add generic arch_*() bitops")
>
> from the tip tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> diff --cc include/asm-generic/bitops/non-atomic.h
> index c5a7d8eb9c2b,365377fb104b..000000000000
> --- a/include/asm-generic/bitops/non-atomic.h
> +++ b/include/asm-generic/bitops/non-atomic.h
> @@@ -13,15 -13,18 +13,18 @@@
> * If it's called on the same region of memory simultaneously, the effect
> * may be that only one operation succeeds.
> */
> - static inline void __set_bit(unsigned int nr, volatile unsigned long *addr)
> + static __always_inline void
> -arch___set_bit(int nr, volatile unsigned long *addr)
> ++arch___set_bit(unsigned int nr, volatile unsigned long *addr)
> {
> unsigned long mask = BIT_MASK(nr);
> unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
>
> *p |= mask;
> }
> + #define __set_bit arch___set_bit
>
> - static inline void __clear_bit(unsigned int nr, volatile unsigned long *addr)
> + static __always_inline void
> -arch___clear_bit(int nr, volatile unsigned long *addr)
> ++arch___clear_bit(unsigned int nr, volatile unsigned long *addr)
> {
> unsigned long mask = BIT_MASK(nr);
> unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
> @@@ -38,7 -42,8 +42,8 @@@
> * If it's called on the same region of memory simultaneously, the effect
> * may be that only one operation succeeds.
> */
> - static inline void __change_bit(unsigned int nr, volatile unsigned long *addr)
> + static __always_inline
> -void arch___change_bit(int nr, volatile unsigned long *addr)
> ++void arch___change_bit(unsigned int nr, volatile unsigned long *addr)
> {
> unsigned long mask = BIT_MASK(nr);
> unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
> @@@ -55,7 -61,8 +61,8 @@@
> * If two examples of this operation race, one can appear to succeed
> * but actually fail. You must protect multiple accesses with a lock.
> */
> - static inline int __test_and_set_bit(unsigned int nr, volatile unsigned long *addr)
> + static __always_inline int
> -arch___test_and_set_bit(int nr, volatile unsigned long *addr)
> ++arch___test_and_set_bit(unsigned int nr, volatile unsigned long *addr)
> {
> unsigned long mask = BIT_MASK(nr);
> unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
> @@@ -74,7 -82,8 +82,8 @@@
> * If two examples of this operation race, one can appear to succeed
> * but actually fail. You must protect multiple accesses with a lock.
> */
> - static inline int __test_and_clear_bit(unsigned int nr, volatile unsigned long *addr)
> + static __always_inline int
> -arch___test_and_clear_bit(int nr, volatile unsigned long *addr)
> ++arch___test_and_clear_bit(unsigned int nr, volatile unsigned long *addr)
> {
> unsigned long mask = BIT_MASK(nr);
> unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
> @@@ -83,10 -92,11 +92,11 @@@
> *p = old & ~mask;
> return (old & mask) != 0;
> }
> + #define __test_and_clear_bit arch___test_and_clear_bit
>
> /* WARNING: non atomic and it can be reordered! */
> - static inline int __test_and_change_bit(unsigned int nr,
> - volatile unsigned long *addr)
> + static __always_inline int
> -arch___test_and_change_bit(int nr, volatile unsigned long *addr)
> ++arch___test_and_change_bit(unsigned int nr, volatile unsigned long *addr)
> {
> unsigned long mask = BIT_MASK(nr);
> unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
> @@@ -101,7 -112,8 +112,8 @@@
> * @nr: bit number to test
> * @addr: Address to start counting from
> */
> - static inline int test_bit(unsigned int nr, const volatile unsigned long *addr)
> + static __always_inline int
> -arch_test_bit(int nr, const volatile unsigned long *addr)
> ++arch_test_bit(unsigned int nr, const volatile unsigned long *addr)
> {
> return 1UL & (addr[BIT_WORD(nr)] >> (nr & (BITS_PER_LONG-1)));
> }
This is now a conflict between the asm-generic tree and Linus' tree.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2021-09-01 3:20 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-16 1:47 linux-next: manual merge of the tip tree with the asm-generic tree Stephen Rothwell
2021-09-01 3:20 ` Stephen Rothwell [this message]
-- strict thread matches above, loose matches on Subject: below --
2023-10-12 2:44 Stephen Rothwell
2023-10-15 22:15 ` Stephen Rothwell
2019-04-24 5:10 Stephen Rothwell
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=20210901132018.1fc8ec5d@canb.auug.org.au \
--to=sfr@canb$(echo .)auug.org.au \
--cc=Vineet.Gupta1@synopsys$(echo .)com \
--cc=arnd@arndb$(echo .)de \
--cc=hpa@zytor$(echo .)com \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linux-next@vger$(echo .)kernel.org \
--cc=mark.rutland@arm$(echo .)com \
--cc=mingo@elte$(echo .)hu \
--cc=peterz@infradead$(echo .)org \
--cc=tglx@linutronix$(echo .)de \
--cc=vgupta@synopsys$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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