From: Stephen Rothwell <sfr@canb•auug.org.au>
To: Kees Cook <kees@kernel•org>, Heiko Carstens <hca@linux•ibm.com>,
Vasily Gorbik <gor@linux•ibm.com>,
Christian Borntraeger <borntraeger@de•ibm.com>
Cc: Alexander Gordeev <agordeev@linux•ibm.com>,
Juergen Christ <jchrist@linux•ibm.com>,
Linux Kernel Mailing List <linux-kernel@vger•kernel.org>,
Linux Next Mailing List <linux-next@vger•kernel.org>
Subject: linux-next: manual merge of the kspp tree with the s390 tree
Date: Tue, 26 Aug 2025 17:44:01 +1000 [thread overview]
Message-ID: <20250826174401.37803a3a@canb.auug.org.au> (raw)
[-- Attachment #1: Type: text/plain, Size: 3336 bytes --]
Hi all,
Today's linux-next merge of the kspp tree got a conflict in:
arch/s390/include/asm/bitops.h
between commits:
de88e74889a3 ("s390/bitops: Slightly optimize ffs() and fls64()")
669bc57e7016 ("s390/bitops: Optimize inlining")
from the s390 tree and commit:
5f8ee21b8fb2 ("s390: Add __attribute_const__ to ffs()-family implementations")
from the kspp tree.
I fixed it up (Maybe - 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.
--
Cheers,
diff --cc arch/s390/include/asm/bitops.h
index 9dfb687ba620,fbcc3e1cc776..000000000000
--- a/arch/s390/include/asm/bitops.h
+++ b/arch/s390/include/asm/bitops.h
@@@ -179,7 -179,7 +179,7 @@@ static __always_inline unsigned char __
*
* Undefined if no bit exists, so code should check against 0 first.
*/
- static __always_inline __flatten unsigned long __ffs(unsigned long word)
-static inline __attribute_const__ unsigned long __ffs(unsigned long word)
++static __always_inline __flatten __attribute_const__ unsigned long __ffs(unsigned long word)
{
return __flogr(-word & word) ^ (BITS_PER_LONG - 1);
}
@@@ -191,11 -191,12 +191,11 @@@
* This is defined the same way as the libc and
* compiler builtin ffs routines (man ffs).
*/
- static __always_inline __flatten int ffs(int word)
-static inline __attribute_const__ int ffs(int word)
++static __always_inline __flatten __attribute_const__ int ffs(int word)
{
- unsigned long mask = 2 * BITS_PER_LONG - 1;
unsigned int val = (unsigned int)word;
- return (1 + (__flogr(-val & val) ^ (BITS_PER_LONG - 1))) & mask;
+ return BITS_PER_LONG - __flogr(-val & val);
}
/**
@@@ -204,7 -205,7 +204,7 @@@
*
* Undefined if no set bit exists, so code should check against 0 first.
*/
- static __always_inline __flatten unsigned long __fls(unsigned long word)
-static inline __attribute_const__ unsigned long __fls(unsigned long word)
++static __always_inline __flatten __attribute_const__ unsigned long __fls(unsigned long word)
{
return __flogr(word) ^ (BITS_PER_LONG - 1);
}
@@@ -220,9 -221,11 +220,9 @@@
* set bit if value is nonzero. The last (most significant) bit is
* at position 64.
*/
- static __always_inline __flatten int fls64(unsigned long word)
-static inline __attribute_const__ int fls64(unsigned long word)
++static __always_inline __flatten __attribute_const__ int fls64(unsigned long word)
{
- unsigned long mask = 2 * BITS_PER_LONG - 1;
-
- return (1 + (__flogr(word) ^ (BITS_PER_LONG - 1))) & mask;
+ return BITS_PER_LONG - __flogr(word);
}
/**
@@@ -232,7 -235,7 +232,7 @@@
* This is defined the same way as ffs.
* Note fls(0) = 0, fls(1) = 1, fls(0x80000000) = 32.
*/
- static __always_inline __flatten int fls(unsigned int word)
-static inline __attribute_const__ int fls(unsigned int word)
++static __always_inline __flatten __attribute_const__ int fls(unsigned int word)
{
return fls64(word);
}
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next reply other threads:[~2025-08-26 7:44 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-26 7:44 Stephen Rothwell [this message]
-- strict thread matches above, loose matches on Subject: below --
2025-09-25 14:39 linux-next: manual merge of the kspp tree with the s390 tree Mark Brown
2017-02-08 1:37 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=20250826174401.37803a3a@canb.auug.org.au \
--to=sfr@canb$(echo .)auug.org.au \
--cc=agordeev@linux$(echo .)ibm.com \
--cc=borntraeger@de$(echo .)ibm.com \
--cc=gor@linux$(echo .)ibm.com \
--cc=hca@linux$(echo .)ibm.com \
--cc=jchrist@linux$(echo .)ibm.com \
--cc=kees@kernel$(echo .)org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linux-next@vger$(echo .)kernel.org \
/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