* Linux 5.18-rc1
@ 2022-04-03 22:14 Linus Torvalds
2022-04-04 2:22 ` Guenter Roeck
2022-04-04 7:47 ` Build regressions/improvements in v5.18-rc1 Geert Uytterhoeven
0 siblings, 2 replies; 36+ messages in thread
From: Linus Torvalds @ 2022-04-03 22:14 UTC (permalink / raw)
To: Linux Kernel Mailing List
So here we are, two weeks later, and the merge window is closed.
The full diffstat isn't useful, because this is another of those
occasional releases where the AMD drm driver adds those generated
register definitions, so the diff is absolutely dominated by register
definitions for DCN 3.1.x and MP 13.0.x register definitions. Don't
even go look - you'll go blind.
Another fairly big chunk of it (but nowhere _near_ the AMD GPU
register definitions) is the updates for various Intel performance
monitoring event tables.
But if you ignore those two areas, things look fairly normal. At that
point, it's about 60%driver updates - with GPU updates are still
fairly sizable, but now no longer so dominant as to hide everything
else. And all the other usual suspects too: networking, sound, media,
scsi, pinctrl, clk, etc..
The rest is fairly spread out documentation and devicetree bindings
(maybe I should just count that against drivers), architecture updates
(biggest part of the diff: nds32 is gone, but there's all the usual
x86, arm, arm64, powerpc, parisc, mips and riscv updates). Tooling
updates (perf and selftests), and of course all the core kernel
updates (filesystem, core, networking, VM).
As always, there's _way_ too many changes to list individually, and
you're just getting the usual mergelog appended.
In fact, at least in pure commits, this has been a bigger merge window
than we've had in some time. But let's hope it's all smooth sailing
this release.
Sure, that will happen.
Go test, please,
Linus
---
Al Viro (1):
vfs updates
Alex Williamson (1):
VFIO updates
Alexandre Belloni (2):
i3c updates
RTC updates
Andreas Gruenbacher (2):
iomap fixlet
gfs2 fixes
Andrew Morton (4):
updates
more updates
yet more updates
still more updates
Arnaldo Carvalho de Melo (2):
perf tools updates
more perf tools updates
Arnd Bergmann (6):
asm-generic updates
ARM defconfig updates
ARM SoC updates
ARM driver updates
ARM devicetree updates
ARM SoC fixes
Bartosz Golaszewski (2):
gpio updates
gpio fixes
Benson Leung (1):
chrome platform updates
Bjorn Andersson (3):
rpmsg updates
hwspinlock updates
remoteproc updates
Bjorn Helgaas (2):
pci updates
pci fix
Borislav Petkov (10):
EDAC updates
x86 cpu feature updates
misc x86 updates
x86 Kconfig fix
x86 paravirt improvement
x86 SEV fix
x86 SGX updates
x86 confidential computing updates
x86 cleanups
RAS updates
Brian Cain (1):
hexagon update
Casey Schaufler (1):
smack update
Christian Brauner (2):
mount_setattr updates
mount attributes PREEMPT_RT update
Christoph Hellwig (2):
dma-mapping updates
more dma-mapping updates
Chuck Lever (1):
nfsd updates
Corey Minyard (1):
IPMI updates
Damien Le Moal (1):
ata updates
Dan Williams (3):
CXL (Compute Express Link) updates
DAX updates
libnvdimm updates
Daniel Thompson (1):
kgdb update
Darrick Wong (3):
xfs updates
xfs fixes
vfs fix
Dave Airlie (2):
drm updates
drm fixes
Dave Kleikamp (1):
jfs updates
David Howells (2):
watch_queue fixes
netfs updates
David Sterba (1):
btrfs updates
Dmitry Torokhov (1):
input updates
Eric Biederman (3):
tasklist_lock optimizations
shm ucounts fix
ptrace cleanups
Eric Biggers (1):
fscrypt updates
Gao Xiang (1):
erofs updates
Geert Uytterhoeven (1):
m68k updates
Greg KH (5):
USB/Thunderbolt updates
char/misc and other driver updates
driver core updates
staging driver updates
tty/serial driver updates
Greg Ungerer (1):
m68knommu updates
Guenter Roeck (1):
hwmon updates
Gustavo Silva (1):
flexible-array transformations
Hans de Goede (1):
x86 platform driver updates
Helge Deller (3):
parisc architecture updates
fbdev updates
more parisc architecture updates
Herbert Xu (2):
crypto updates
crypto fixes
Ilya Dryomov (1):
ceph updates
Ingo Molnar (3):
x86 perf event updates
locking updates
scheduler updates
Jaegeuk Kim (1):
f2fs updates
Jakub Kicinski (3):
networking updates
networking fixes
more networking updates
James Bottomley (1):
SCSI updates
Jan Kara (2):
fsnotify updates
reiserfs updates
Jarkko Sakkinen (1):
tpm updates
Jason Donenfeld (2):
random number generator updates
random number generator fixes
Jason Gunthorpe (1):
rdma updates
Jassi Brar (1):
mailbox updates
Jens Axboe (12):
io_uring updates
io_uring statx fixes
block updates
block driver updates
bio_alloc() cleanups
NVMe write streams removal
bio allocation fix
block layer 64-bit data integrity support
io_uring fixes
block fixes
block driver fixes
block driver fix
Jiri Kosina (1):
HID updates
Joerg Roedel (1):
iommu updates
Jonathan Corbet (2):
documentation updates
more documentation updates
Juergen Gross (1):
xen updates
Kees Cook (8):
execve updates
pstore updates
kernel hardening updates
overflow updates
bounds fixes
FORTIFY_SOURCE updates
array-bounds updates
hardening updates
Lee Jones (2):
MFD updates
backlight updates
Linus Walleij (1):
pin control updates
Luis Chamberlain (1):
module update
Mark Brown (4):
regmap updates
regulator updates
spi updates
regulator fixes
Masahiro Yamada (3):
Kbuild update for C11 language base
Kbuild updates
Kbuild fixes
Matthew Wilcox (4):
folio updates
filesystem folio updates
XArray updates
more filesystem folio updates
Mauro Carvalho Chehab (1):
media updates
Max Filippov (1):
Xtensa updates
Michael Ellerman (1):
powerpc updates
Michael Tsirkin (1):
virtio updates
Michal Simek (1):
microblaze updates
Mickaël Salaün (1):
landlock updates
Miguel Ojeda (1):
auxdisplay updates
Mike Rapoport (1):
memblock updates
Mike Snitzer (2):
device mapper updates
device mapper fixes
Mimi Zohar (1):
integrity subsystem updates
Miquel Raynal (1):
MTD updates
Namjae Jeon (1):
exfat updates
Palmer Dabbelt (3):
RISC-V updates
more RISC-V updates
RISC-V fix
Paolo Bonzini (2):
kvm updates
kvm fixes
Paul McKenney (2):
RCU updates
memory model doc update
Paul Moore (2):
selinux updates
audit update
Pavel Machek (1):
LED updates
Peter Zijlstra (1):
x86 CET-IBT (Control-Flow-Integrity) support
Petr Mladek (2):
printk updates
livepatching updates
Rafael Wysocki (7):
ACPI updates
power management updates
thermal control updates
PnP update
more power management updates
device properties code update
more ACPI updates
Richard Weinberger (2):
JFFS2, UBI and UBIFS updates
UML updates
Rob Herring (2):
devicetree updates
devicetree fixes
Russell King (3):
ARM updates
ARM updates
ARM fixes
Sebastian Reichel (1):
power supply and reset updates
Shuah Khan (2):
Kselftest updates
KUnit updates
Stafford Horne (1):
OpenRISC updates
Stephen Boyd (2):
clk updates
clk fix
Steve French (3):
cfis updates
more cifs updates
ksmbd updates
Steven Rostedt (4):
RTLA tracing tool updates
tracing updates
trace event string verifier fix
more tracing updates
Takashi Iwai (2):
sound updates
sound fixes
Ted Ts'o (1):
ext4 updates
Tejun Heo (2):
workqueue updates
cgroup updates
Tetsuo Handa (1):
tomoyo update
Thierry Reding (1):
pwm updates
Thomas Bogendoerfer (2):
MIPS updates
MIPS fixes
Thomas Gleixner (6):
x86 PASID support
core process handling RT latency updates
timer and timekeeping updates
interrupt updates
RT signal fix
x86 fixes
Trond Myklebust (1):
NFS client updates
Ulf Hansson (1):
MMC updates
Vasily Gorbik (2):
s390 updates
more s390 updates
Vinod Koul (1):
dmaengine updates
Vlastimil Babka (1):
slab updates
Wei Liu (1):
hyperv updates
Will Deacon (1):
arm64 updates
Wim Van Sebroeck (1):
watchdog updates
Wolfram Sang (1):
i2c updates
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Linux 5.18-rc1
2022-04-03 22:14 Linux 5.18-rc1 Linus Torvalds
@ 2022-04-04 2:22 ` Guenter Roeck
2022-04-04 3:29 ` Linus Torvalds
2022-04-05 12:19 ` Sudip Mukherjee
2022-04-04 7:47 ` Build regressions/improvements in v5.18-rc1 Geert Uytterhoeven
1 sibling, 2 replies; 36+ messages in thread
From: Guenter Roeck @ 2022-04-04 2:22 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel Mailing List
On Sun, Apr 03, 2022 at 03:14:19PM -0700, Linus Torvalds wrote:
> So here we are, two weeks later, and the merge window is closed.
>
> The full diffstat isn't useful, because this is another of those
> occasional releases where the AMD drm driver adds those generated
> register definitions, so the diff is absolutely dominated by register
> definitions for DCN 3.1.x and MP 13.0.x register definitions. Don't
> even go look - you'll go blind.
>
> Another fairly big chunk of it (but nowhere _near_ the AMD GPU
> register definitions) is the updates for various Intel performance
> monitoring event tables.
>
> But if you ignore those two areas, things look fairly normal. At that
> point, it's about 60%driver updates - with GPU updates are still
> fairly sizable, but now no longer so dominant as to hide everything
> else. And all the other usual suspects too: networking, sound, media,
> scsi, pinctrl, clk, etc..
>
> The rest is fairly spread out documentation and devicetree bindings
> (maybe I should just count that against drivers), architecture updates
> (biggest part of the diff: nds32 is gone, but there's all the usual
> x86, arm, arm64, powerpc, parisc, mips and riscv updates). Tooling
> updates (perf and selftests), and of course all the core kernel
> updates (filesystem, core, networking, VM).
>
> As always, there's _way_ too many changes to list individually, and
> you're just getting the usual mergelog appended.
>
> In fact, at least in pure commits, this has been a bigger merge window
> than we've had in some time. But let's hope it's all smooth sailing
> this release.
>
> Sure, that will happen.
>
> Go test, please,
Build results:
total: 151 pass: 142 fail: 9
Failed builds:
alpha:allmodconfig
arm:allmodconfig
csky:allmodconfig
i386:allyesconfig
i386:allmodconfig
mips:allmodconfig
parisc:allmodconfig
powerpc:ppc32_allmodconfig
xtensa:allmodconfig
Qemu test results:
total: 488 pass: 488 fail: 0
Details below.
Guenter
---
Building alpha:allmodconfig ... failed
--------------
Error log:
<stdin>:1517:2: warning: #warning syscall clone3 not implemented [-Wcpp]
In file included from include/linux/string.h:20,
from include/linux/bitmap.h:11,
from include/linux/cpumask.h:12,
from include/linux/smp.h:13,
from include/linux/lockdep.h:14,
from include/linux/spinlock.h:62,
from include/linux/wait.h:9,
from include/linux/wait_bit.h:8,
from include/linux/fs.h:6,
from include/linux/highmem.h:5,
from include/linux/bvec.h:10,
from include/linux/skbuff.h:17,
from include/../include/linux/if_arp.h:22,
from drivers/staging/r8188eu/core/rtw_br_ext.c:6:
In function '__nat25_add_pppoe_tag',
inlined from 'nat25_db_handle' at drivers/staging/r8188eu/core/rtw_br_ext.c:479:11:
arch/alpha/include/asm/string.h:22:16: error: '__builtin_memcpy' forming offset [40, 2051] is out of the bounds [0, 40] of object 'tag_buf' with type 'unsigned char[40]'
Exposed by commit e6148767825c ("Makefile: Enable -Warray-bounds").
Fix at https://lore.kernel.org/lkml/20220403123628.3113382-1-linux@roeck-us.net/
--------------
Building arm:allmodconfig ... failed
Building csky:allmodconfig ... failed
Building i386:allyesconfig ... failed
Building mips:allmodconfig ... failed
Building parisc:allmodconfig ... failed
Building powerpc:ppc32_allmodconfig ... failed
Building xtensa:allmodconfig ... failed
--------------
Error log:
drivers/misc/habanalabs/common/memory.c: In function 'alloc_device_memory':
drivers/misc/habanalabs/common/memory.c:153:49: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
153 | (u64) gen_pool_dma_alloc_align(vm->dram_pg_pool,
Fix at https://lore.kernel.org/lkml/20220401151450.3414694-1-linux@roeck-us.net/
--------------
Building powerpc:ppc32_allmodconfig ... failed
--------------
Error log:
drivers/tty/serial/mpc52xx_uart.c:967:23: error: initialization of 'unsigned int (*)(struct uart_port *)' from incompatible pointer type 'int (*)(struct uart_port *)' [-Werror=incompatible-pointer-types]
967 | .raw_rx_rdy = mpc5125_psc_raw_rx_rdy,
and many similar errors.
Caused by commit 18662a1d8f35 ("tty: serial: mpc52xx_uart: make rx/tx
hooks return unsigned"). Reported at
https://lore.kernel.org/lkml/20220403153607.GA3644508@roeck-us.net/
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Linux 5.18-rc1
2022-04-04 2:22 ` Guenter Roeck
@ 2022-04-04 3:29 ` Linus Torvalds
2022-04-04 4:23 ` Guenter Roeck
2022-04-04 6:01 ` Jiri Slaby
2022-04-05 12:19 ` Sudip Mukherjee
1 sibling, 2 replies; 36+ messages in thread
From: Linus Torvalds @ 2022-04-04 3:29 UTC (permalink / raw)
To: Guenter Roeck, Larry Finger, Oded Gabbay, Jiri Slaby
Cc: Linux Kernel Mailing List, Greg Kroah-Hartman
On Sun, Apr 3, 2022 at 7:22 PM Guenter Roeck <linux@roeck-us.net> wrote:
>
> In function '__nat25_add_pppoe_tag',
> inlined from 'nat25_db_handle' at drivers/staging/r8188eu/core/rtw_br_ext.c:479:11:
> arch/alpha/include/asm/string.h:22:16: error: '__builtin_memcpy' forming offset [40, 2051] is out of the bounds [0, 40] of object 'tag_buf' with type 'unsigned char[40]'
>
> Exposed by commit e6148767825c ("Makefile: Enable -Warray-bounds").
> Fix at https://lore.kernel.org/lkml/20220403123628.3113382-1-linux@roeck-us.net/
Funky. Apparently nobody else does that pppoe_tag thing, and this
driver does it wrong on little-endian, which is the common thing to
test.
Your email that you point to is a bit confused, though, in how it says
"when building the driver on a big endian system such as alpha".
Alpha is little-endian, not big-endian.
Now, why it apparently only warns on alpha, I have absolutely no idea.
It should warn on other things too afaik, since that
tag->tag_len = htons(MAGIC_CODE_LEN+RTL_RELAY_TAG_LEN+old_tag_len);
should be visible not just on alpha.
Weird. But your patch looks correct.
> Building arm:allmodconfig ... failed
> Building csky:allmodconfig ... failed
> Building i386:allyesconfig ... failed
> Building mips:allmodconfig ... failed
> Building parisc:allmodconfig ... failed
> Building powerpc:ppc32_allmodconfig ... failed
> Building xtensa:allmodconfig ... failed
> --------------
> Error log:
> drivers/misc/habanalabs/common/memory.c: In function 'alloc_device_memory':
> drivers/misc/habanalabs/common/memory.c:153:49: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
> 153 | (u64) gen_pool_dma_alloc_align(vm->dram_pg_pool,
>
> Fix at https://lore.kernel.org/lkml/20220401151450.3414694-1-linux@roeck-us.net/
Gaah - both of those "(u64)" look pointless.
Either the thing is a pointer, in which case that (uinptr_t) - or just
(unsigned long) - is the right thing to do, or it's already an integer
type, in which case castring it to (u64) just do do that
phys_pg_pack->pages[i] = ...
assignment seems entirely pointless.
So I think the patch should also remove those pointless (u64) casts.
Yes, yes, the pages[] array in 'struct hl_vm_phys_pg_pack' 'pages[]'
is of u64's, but casting integers like that is just silly.
> Error log:
> drivers/tty/serial/mpc52xx_uart.c:967:23: error: initialization of 'unsigned int (*)(struct uart_port *)' from incompatible pointer type 'int (*)(struct uart_port *)' [-Werror=incompatible-pointer-types]
> 967 | .raw_rx_rdy = mpc5125_psc_raw_rx_rdy,
>
> and many similar errors.
>
> Caused by commit 18662a1d8f35 ("tty: serial: mpc52xx_uart: make rx/tx
> hooks return unsigned"). Reported at
> https://lore.kernel.org/lkml/20220403153607.GA3644508@roeck-us.net/
Jiri - apparently you didn't convert the cases under CONFIG_PPC_MPC512x.
Please, people, let's get these silly problems fixed asap, and not
have people unaware of them and fixes pending until much later in the
rc series? It was painful last release, let's not repeat that
mistake.
Linus
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Linux 5.18-rc1
2022-04-04 3:29 ` Linus Torvalds
@ 2022-04-04 4:23 ` Guenter Roeck
2022-04-04 7:30 ` Ron Economos
2022-04-04 15:32 ` Linus Torvalds
2022-04-04 6:01 ` Jiri Slaby
1 sibling, 2 replies; 36+ messages in thread
From: Guenter Roeck @ 2022-04-04 4:23 UTC (permalink / raw)
To: Linus Torvalds, Larry Finger, Oded Gabbay, Jiri Slaby
Cc: Linux Kernel Mailing List, Greg Kroah-Hartman
On 4/3/22 20:29, Linus Torvalds wrote:
> On Sun, Apr 3, 2022 at 7:22 PM Guenter Roeck <linux@roeck-us.net> wrote:
>>
>> In function '__nat25_add_pppoe_tag',
>> inlined from 'nat25_db_handle' at drivers/staging/r8188eu/core/rtw_br_ext.c:479:11:
>> arch/alpha/include/asm/string.h:22:16: error: '__builtin_memcpy' forming offset [40, 2051] is out of the bounds [0, 40] of object 'tag_buf' with type 'unsigned char[40]'
>>
>> Exposed by commit e6148767825c ("Makefile: Enable -Warray-bounds").
>> Fix at https://lore.kernel.org/lkml/20220403123628.3113382-1-linux@roeck-us.net/
>
> Funky. Apparently nobody else does that pppoe_tag thing, and this
> driver does it wrong on little-endian, which is the common thing to
> test.
>
> Your email that you point to is a bit confused, though, in how it says
> "when building the driver on a big endian system such as alpha".
>
> Alpha is little-endian, not big-endian.
>
Oops. Sorry, I thought it was big endian. No idea why. I'll update
subject and description and resend.
> Now, why it apparently only warns on alpha, I have absolutely no idea.
> It should warn on other things too afaik, since that
>
> tag->tag_len = htons(MAGIC_CODE_LEN+RTL_RELAY_TAG_LEN+old_tag_len);
>
> should be visible not just on alpha.
>
Maybe htons() and ntohs() are modeled differently on other architectures,
and the compiler doesn't see the context ?
> Weird. But your patch looks correct.
>
>> Building arm:allmodconfig ... failed
>> Building csky:allmodconfig ... failed
>> Building i386:allyesconfig ... failed
>> Building mips:allmodconfig ... failed
>> Building parisc:allmodconfig ... failed
>> Building powerpc:ppc32_allmodconfig ... failed
>> Building xtensa:allmodconfig ... failed
>> --------------
>> Error log:
>> drivers/misc/habanalabs/common/memory.c: In function 'alloc_device_memory':
>> drivers/misc/habanalabs/common/memory.c:153:49: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
>> 153 | (u64) gen_pool_dma_alloc_align(vm->dram_pg_pool,
>>
>> Fix at https://lore.kernel.org/lkml/20220401151450.3414694-1-linux@roeck-us.net/
>
> Gaah - both of those "(u64)" look pointless.
>
> Either the thing is a pointer, in which case that (uinptr_t) - or just
> (unsigned long) - is the right thing to do, or it's already an integer
> type, in which case castring it to (u64) just do do that
>
> phys_pg_pack->pages[i] = ...
>
> assignment seems entirely pointless.
>
> So I think the patch should also remove those pointless (u64) casts.
>
> Yes, yes, the pages[] array in 'struct hl_vm_phys_pg_pack' 'pages[]'
> is of u64's, but casting integers like that is just silly.
>
Double casts are quite common, though. Try 'git grep "(u64)(uintptr_t)"'.
But I think you are right, a cast to (uintptr_t) should be sufficient here.
I'll resend that patch as well.
Guenter
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Linux 5.18-rc1
2022-04-04 3:29 ` Linus Torvalds
2022-04-04 4:23 ` Guenter Roeck
@ 2022-04-04 6:01 ` Jiri Slaby
1 sibling, 0 replies; 36+ messages in thread
From: Jiri Slaby @ 2022-04-04 6:01 UTC (permalink / raw)
To: Linus Torvalds, Guenter Roeck, Larry Finger, Oded Gabbay
Cc: Linux Kernel Mailing List, Greg Kroah-Hartman
On 04. 04. 22, 5:29, Linus Torvalds wrote:
>> Error log:
>> drivers/tty/serial/mpc52xx_uart.c:967:23: error: initialization of 'unsigned int (*)(struct uart_port *)' from incompatible pointer type 'int (*)(struct uart_port *)' [-Werror=incompatible-pointer-types]
>> 967 | .raw_rx_rdy = mpc5125_psc_raw_rx_rdy,
>>
>> and many similar errors.
>>
>> Caused by commit 18662a1d8f35 ("tty: serial: mpc52xx_uart: make rx/tx
>> hooks return unsigned"). Reported at
>> https://lore.kernel.org/lkml/20220403153607.GA3644508@roeck-us.net/
>
> Jiri - apparently you didn't convert the cases under CONFIG_PPC_MPC512x.
>
> Please, people, let's get these silly problems fixed asap, and not
> have people unaware of them and fixes pending until much later in the
> rc series? It was painful last release, let's not repeat that
> mistake.
Sure, I wasn't aware of the issue until yesterday -- when Guenter
dropped me an e-mail. It passed through all the testing machinery which
is unfortunate. (I have a script to cross-compile most of the peculiar
tty drivers [1]. That indeed contains "mpc52xx_uart.o powerpc_mpc5200".)
The fix was posted as 20220404055122.31194-1-jslaby@suse.cz .
[1] https://pastebin.com/UDTsBAaY
thanks,
--
js
suse labs
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Linux 5.18-rc1
2022-04-04 4:23 ` Guenter Roeck
@ 2022-04-04 7:30 ` Ron Economos
2022-04-04 15:32 ` Linus Torvalds
1 sibling, 0 replies; 36+ messages in thread
From: Ron Economos @ 2022-04-04 7:30 UTC (permalink / raw)
To: linux; +Cc: Larry.Finger, gregkh, jslaby, linux-kernel, ogabbay, torvalds
> On 4/3/22 20:29, Linus Torvalds wrote:
> > On Sun, Apr 3, 2022 at 7:22 PM Guenter Roeck <linux@roeck-us.net> wrote:
> >>
> >> In function '__nat25_add_pppoe_tag',
> >> inlined from 'nat25_db_handle' at drivers/staging/r8188eu/core/rtw_br_ext.c:479:11:
> >> arch/alpha/include/asm/string.h:22:16: error: '__builtin_memcpy' forming offset [40, 2051] is out of the bounds [0, 40] of object 'tag_buf' with type 'unsigned char[40]'
> >>
> >> Exposed by commit e6148767825c ("Makefile: Enable -Warray-bounds").
> >> Fix at https://lore.kernel.org/lkml/20220403123628.3113382-1-linux@roeck-us.net/
> >
> > Funky. Apparently nobody else does that pppoe_tag thing, and this
> > driver does it wrong on little-endian, which is the common thing to
> > test.
> >
> > Your email that you point to is a bit confused, though, in how it says
> > "when building the driver on a big endian system such as alpha".
> >
> > Alpha is little-endian, not big-endian.
> >
>
> Oops. Sorry, I thought it was big endian. No idea why. I'll update
> subject and description and resend.
>
> > Now, why it apparently only warns on alpha, I have absolutely no idea.
> > It should warn on other things too afaik, since that
> >
> > tag->tag_len = htons(MAGIC_CODE_LEN+RTL_RELAY_TAG_LEN+old_tag_len);
> >
> > should be visible not just on alpha.
> >
> Maybe htons() and ntohs() are modeled differently on other architectures,
> and the compiler doesn't see the context ?
>
> > Weird. But your patch looks correct.
This warning also appears on RISC-V RV64 with gcc 11.2.0. The patch
works good.
Ron
^ permalink raw reply [flat|nested] 36+ messages in thread
* Build regressions/improvements in v5.18-rc1
2022-04-03 22:14 Linux 5.18-rc1 Linus Torvalds
2022-04-04 2:22 ` Guenter Roeck
@ 2022-04-04 7:47 ` Geert Uytterhoeven
2022-04-04 8:16 ` Geert Uytterhoeven
1 sibling, 1 reply; 36+ messages in thread
From: Geert Uytterhoeven @ 2022-04-04 7:47 UTC (permalink / raw)
To: linux-kernel
Below is the list of build error/warning regressions/improvements in
v5.18-rc1[1] compared to v5.17[2].
Summarized:
- build errors: +36/-15
- build warnings: +5/-38
Happy fixing! ;-)
Thanks to the linux-next team for providing the build service.
[1] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/3123109284176b1532874591f7c81f3837bbdc17/ (all 96 configs)
[2] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/f443e374ae131c168a065ea1748feac6b2e76613/ (all 96 configs)
*** ERRORS ***
36 error regressions:
+ /kisskb/src/arch/m68k/include/asm/bitops.h: error: array subscript 2 is above array bounds of 'long unsigned int[1]' [-Werror=array-bounds]: => 329:20
+ /kisskb/src/arch/parisc/kernel/vdso32/restart_syscall.S: Error: .cfi_endproc without corresponding .cfi_startproc: => 32
+ /kisskb/src/arch/parisc/kernel/vdso32/restart_syscall.S: Error: bad or irreducible absolute expression: => 16
+ /kisskb/src/arch/parisc/kernel/vdso32/restart_syscall.S: Error: junk at end of line, first unrecognized character is `:': => 16
+ /kisskb/src/arch/parisc/kernel/vdso32/restart_syscall.S: Error: no such instruction: `be 0x100(%sr2,%r0)': => 29
+ /kisskb/src/arch/parisc/kernel/vdso32/restart_syscall.S: Error: no such instruction: `ldi 0,%r20': => 30
+ /kisskb/src/arch/parisc/kernel/vdso32/restart_syscall.S: Error: no such instruction: `ldw 0(%sp),%r31': => 26
+ /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: no such instruction: `ble 0x100(%sr2,%r0)': => 51, 46
+ /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: no such instruction: `ldi 0,%r25': => 44
+ /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: no such instruction: `ldi 1,%r25': => 49
+ /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: no such instruction: `ldi 173,%r20': => 45, 50
+ /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: unknown pseudo-op: `.callinfo': => 40
+ /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: unknown pseudo-op: `.entry': => 41
+ /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: unknown pseudo-op: `.exit': => 54
+ /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: unknown pseudo-op: `.proc': => 39
+ /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: unknown pseudo-op: `.procend': => 55
+ /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: unknown pseudo-op: `.stringz': => 76
+ /kisskb/src/arch/sparc/kernel/irq_32.c: error: array subscript [16, 79] is outside array bounds of 'struct tt_entry[1]' [-Werror=array-bounds]: => 262:14, 261:46, 259:14, 258:14, 263:14
+ /kisskb/src/drivers/gpu/drm/r128/r128_cce.c: error: case label does not reduce to an integer constant: => 417:2, 418:2
+ /kisskb/src/drivers/infiniband/hw/qib/qib_wc_x86_64.c: error: 'X86_VENDOR_AMD' undeclared (first use in this function): => 149:37
+ /kisskb/src/drivers/infiniband/hw/qib/qib_wc_x86_64.c: error: 'struct cpuinfo_um' has no member named 'x86_vendor': => 149:22
+ /kisskb/src/drivers/infiniband/hw/qib/qib_wc_x86_64.c: error: control reaches end of non-void function [-Werror=return-type]: => 150:1
+ /kisskb/src/drivers/infiniband/sw/rdmavt/qp.c: error: 'struct cpuinfo_um' has no member named 'x86_cache_size': => 88:22
+ /kisskb/src/drivers/infiniband/sw/rdmavt/qp.c: error: control reaches end of non-void function [-Werror=return-type]: => 89:1
+ /kisskb/src/drivers/infiniband/sw/rdmavt/qp.c: error: implicit declaration of function '__copy_user_nocache' [-Werror=implicit-function-declaration]: => 100:2
+ /kisskb/src/drivers/media/platform/nxp/imx-pxp.h: error: initializer element is not constant: => 582:38
+ /kisskb/src/drivers/misc/habanalabs/common/memory.c: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]: => 153:49, 153:7
+ /kisskb/src/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c: error: case label does not reduce to an integer constant: => 4917:4
+ /kisskb/src/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c: error: case label does not reduce to an integer constant: => 3798:2, 3809:2
+ /kisskb/src/drivers/scsi/aacraid/commsup.c: error: case label does not reduce to an integer constant: => 1983:2
+ /kisskb/src/drivers/tty/serial/mpc52xx_uart.c: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]: => 1004:12, 1005:12, 1006:14, 970:12, 968:16, 971:14, 969:12, 1002:16, 1003:16, 967:16
+ /kisskb/src/drivers/usb/typec/tcpm/tcpm.c: error: case label does not reduce to an integer constant: => 4724:3
+ /kisskb/src/fs/xfs/xfs_buf.h: error: initializer element is not constant: => 46:23
+ /kisskb/src/include/linux/compiler_types.h: error: call to '__compiletime_assert_402' declared with attribute error: FIELD_PREP: mask is not constant: => 352:38
+ /kisskb/src/include/linux/compiler_types.h: error: call to '__compiletime_assert_404' declared with attribute error: FIELD_PREP: mask is not constant: => 352:38
+ /kisskb/src/sound/usb/midi.c: error: case label does not reduce to an integer constant: => 1389:2
15 error improvements:
- /kisskb/src/arch/sparc/mm/srmmu.c: error: cast between incompatible function types from 'void (*)(long unsigned int)' to 'void (*)(long unsigned int, long unsigned int, long unsigned int, long unsigned int, long unsigned int)' [-Werror=cast-function-type]: 1756:13, 1639:13 =>
- /kisskb/src/arch/sparc/mm/srmmu.c: error: cast between incompatible function types from 'void (*)(struct mm_struct *)' to 'void (*)(long unsigned int, long unsigned int, long unsigned int, long unsigned int, long unsigned int)' [-Werror=cast-function-type]: 1674:29, 1662:29 =>
- /kisskb/src/arch/sparc/mm/srmmu.c: error: cast between incompatible function types from 'void (*)(struct mm_struct *, long unsigned int)' to 'void (*)(long unsigned int, long unsigned int, long unsigned int, long unsigned int, long unsigned int)' [-Werror=cast-function-type]: 1767:21 =>
- /kisskb/src/arch/sparc/mm/srmmu.c: error: cast between incompatible function types from 'void (*)(struct vm_area_struct *, long unsigned int)' to 'void (*)(long unsigned int, long unsigned int, long unsigned int, long unsigned int, long unsigned int)' [-Werror=cast-function-type]: 1741:29, 1726:29 =>
- /kisskb/src/arch/sparc/mm/srmmu.c: error: cast between incompatible function types from 'void (*)(struct vm_area_struct *, long unsigned int, long unsigned int)' to 'void (*)(long unsigned int, long unsigned int, long unsigned int, long unsigned int, long unsigned int)' [-Werror=cast-function-type]: 1694:29, 1711:29 =>
- /kisskb/src/crypto/blake2b_generic.c: error: the frame size of 2288 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]: 109:1 =>
- /kisskb/src/drivers/vfio/pci/vfio_pci_rdwr.c: error: assignment makes pointer from integer without a cast [-Werror=int-conversion]: 317:9, 324:9 =>
- /kisskb/src/drivers/vfio/pci/vfio_pci_rdwr.c: error: implicit declaration of function 'ioport_map' [-Werror=implicit-function-declaration]: 317:11 =>
- /kisskb/src/drivers/vfio/pci/vfio_pci_rdwr.c: error: implicit declaration of function 'ioport_unmap' [-Werror=implicit-function-declaration]: 338:15 =>
- error: arch/powerpc/kvm/book3s_64_entry.o: relocation truncated to fit: R_PPC64_REL14 (stub) against symbol `machine_check_common' defined in .text section in arch/powerpc/kernel/head_64.o: (.text+0x3e4) =>
- error: arch/powerpc/kvm/book3s_64_entry.o: relocation truncated to fit: R_PPC64_REL14 (stub) against symbol `system_reset_common' defined in .text section in arch/powerpc/kernel/head_64.o: (.text+0x3ec) =>
- error: arch/sparc/kernel/head_32.o: relocation truncated to fit: R_SPARC_WDISP22 against `.init.text': (.head.text+0x5100), (.head.text+0x5040) =>
- error: arch/sparc/kernel/head_32.o: relocation truncated to fit: R_SPARC_WDISP22 against symbol `leon_smp_cpu_startup' defined in .text section in arch/sparc/kernel/trampoline_32.o: (.init.text+0xa4) =>
- error: arch/sparc/kernel/process_32.o: relocation truncated to fit: R_SPARC_WDISP22 against `.text': (.fixup+0xc), (.fixup+0x4) =>
- error: arch/sparc/kernel/signal_32.o: relocation truncated to fit: R_SPARC_WDISP22 against `.text': (.fixup+0x10), (.fixup+0x34), (.fixup+0x28), (.fixup+0x4), (.fixup+0x1c) =>
*** WARNINGS ***
5 warning regressions:
+ /kisskb/src/arch/m68k/include/asm/string.h: warning: '__builtin_memset' offset [0, 11] is out of the bounds [0, 0] [-Warray-bounds]: => 68:25
+ /kisskb/src/arch/s390/kernel/machine_kexec.c: warning: 'memcpy' offset [0, 511] is out of the bounds [0, 0] [-Warray-bounds]: => 57:9
+ /kisskb/src/drivers/net/ethernet/i825xx/sun3_82586.c: warning: array subscript 1 is above array bounds of 'volatile struct transmit_cmd_struct *[1]' [-Warray-bounds]: => 989:108, 989:122
+ /kisskb/src/drivers/scsi/mpt3sas/mpt3sas_base.c: warning: array subscript 'Mpi2SasIOUnitPage1_t {aka struct _MPI2_CONFIG_PAGE_SASIOUNIT_1}[0]' is partly outside array bounds of 'unsigned char[20]' [-Warray-bounds]: => 5400:40, 5403:43, 5396:40
+ modpost: WARNING: modpost: EXPORT symbol "_mcount" [vmlinux] version generation failed, symbol will not be versioned.: => N/A
38 warning improvements:
- modpost: WARNING: modpost: EXPORT symbol "___rw_read_enter" [vmlinux] version ...: N/A =>
- modpost: WARNING: modpost: EXPORT symbol "___rw_read_exit" [vmlinux] version ...: N/A =>
- modpost: WARNING: modpost: EXPORT symbol "___rw_read_try" [vmlinux] version ...: N/A =>
- modpost: WARNING: modpost: EXPORT symbol "___rw_write_enter" [vmlinux] version ...: N/A =>
- modpost: WARNING: modpost: EXPORT symbol "__ashldi3" [vmlinux] version ...: N/A =>
- modpost: WARNING: modpost: EXPORT symbol "__ashrdi3" [vmlinux] version ...: N/A =>
- modpost: WARNING: modpost: EXPORT symbol "__copy_1page" [vmlinux] version ...: N/A =>
- modpost: WARNING: modpost: EXPORT symbol "__divdi3" [vmlinux] version ...: N/A =>
- modpost: WARNING: modpost: EXPORT symbol "__lshrdi3" [vmlinux] version ...: N/A =>
- modpost: WARNING: modpost: EXPORT symbol "__muldi3" [vmlinux] version ...: N/A =>
- modpost: WARNING: modpost: EXPORT symbol "__ndelay" [vmlinux] version ...: N/A =>
- modpost: WARNING: modpost: EXPORT symbol "__udelay" [vmlinux] version ...: N/A =>
- modpost: WARNING: modpost: EXPORT symbol "_mcount" [vmlinux] version ...: N/A =>
- modpost: WARNING: modpost: EXPORT symbol "bzero_1page" [vmlinux] version ...: N/A =>
- modpost: WARNING: modpost: EXPORT symbol "empty_zero_page" [vmlinux] version ...: N/A =>
- modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x14410): Section mismatch in reference from the variable qed_mfw_legacy_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: N/A =>
- modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x14428): Section mismatch in reference from the variable qed_mfw_legacy_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: N/A =>
- modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x14440): Section mismatch in reference from the variable qed_mfw_legacy_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: N/A =>
- modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x14458): Section mismatch in reference from the variable qed_mfw_legacy_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: N/A =>
- modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x14470): Section mismatch in reference from the variable qed_mfw_legacy_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: N/A =>
- modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x14488): Section mismatch in reference from the variable qed_mfw_legacy_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: N/A =>
- modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x144a0): Section mismatch in reference from the variable qed_mfw_legacy_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: N/A =>
- modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x144f0): Section mismatch in reference from the variable qed_mfw_ext_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: N/A =>
- modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x14508): Section mismatch in reference from the variable qed_mfw_ext_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: N/A =>
- modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x14520): Section mismatch in reference from the variable qed_mfw_ext_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: N/A =>
- modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x14538): Section mismatch in reference from the variable qed_mfw_ext_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: N/A =>
- modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x14550): Section mismatch in reference from the variable qed_mfw_ext_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: N/A =>
- modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x14568): Section mismatch in reference from the variable qed_mfw_ext_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: N/A =>
- modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x14580): Section mismatch in reference from the variable qed_mfw_ext_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: N/A =>
- modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x14598): Section mismatch in reference from the variable qed_mfw_ext_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: N/A =>
- modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qede/qede.o(.data+0x4790): Section mismatch in reference from the variable qede_forced_speed_maps to the variable .init.rodata:qede_forced_speed_100000: N/A =>
- modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qede/qede.o(.data+0x47a8): Section mismatch in reference from the variable qede_forced_speed_maps to the variable .init.rodata:qede_forced_speed_100000: N/A =>
- modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qede/qede.o(.data+0x47c0): Section mismatch in reference from the variable qede_forced_speed_maps to the variable .init.rodata:qede_forced_speed_100000: N/A =>
- modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qede/qede.o(.data+0x47d8): Section mismatch in reference from the variable qede_forced_speed_maps to the variable .init.rodata:qede_forced_speed_100000: N/A =>
- modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qede/qede.o(.data+0x47f0): Section mismatch in reference from the variable qede_forced_speed_maps to the variable .init.rodata:qede_forced_speed_100000: N/A =>
- modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qede/qede.o(.data+0x4808): Section mismatch in reference from the variable qede_forced_speed_maps to the variable .init.rodata:qede_forced_speed_100000: N/A =>
- modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qede/qede.o(.data+0x4820): Section mismatch in reference from the variable qede_forced_speed_maps to the variable .init.rodata:qede_forced_speed_100000: N/A =>
- modpost: WARNING: modpost: vmlinux.o(.text.unlikely+0x4530): Section mismatch in reference from the function __trace_event_discard_commit() to the variable .init.data:initcall_level_names: N/A =>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Build regressions/improvements in v5.18-rc1
2022-04-04 7:47 ` Build regressions/improvements in v5.18-rc1 Geert Uytterhoeven
2022-04-04 8:16 ` Geert Uytterhoeven
@ 2022-04-04 8:16 ` Geert Uytterhoeven
0 siblings, 0 replies; 36+ messages in thread
From: Geert Uytterhoeven @ 2022-04-04 8:16 UTC (permalink / raw)
To: linux-kernel
Cc: linux-m68k, linux-parisc, sparclinux, dri-devel,
Dennis Dalessandro, Mike Marciniszyn, linux-rdma, linux-um,
linux-media, netdev, linux-wireless, linux-scsi, linux-serial,
linux-usb, linux-xfs, alsa-devel, linux-s390
On Mon, 4 Apr 2022, Geert Uytterhoeven wrote:
> Below is the list of build error/warning regressions/improvements in
> v5.18-rc1[1] compared to v5.17[2].
>
> Summarized:
> - build errors: +36/-15
> - build warnings: +5/-38
>
> Happy fixing! ;-)
>
> Thanks to the linux-next team for providing the build service.
>
> [1] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/3123109284176b1532874591f7c81f3837bbdc17/ (all 96 configs)
> [2] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/f443e374ae131c168a065ea1748feac6b2e76613/ (all 96 configs)
>
>
> *** ERRORS ***
>
> 36 error regressions:
> + /kisskb/src/arch/m68k/include/asm/bitops.h: error: array subscript 2 is above array bounds of 'long unsigned int[1]' [-Werror=array-bounds]: => 329:20
m68k-gcc8/m68k-allmodconfig (assumed gcc8 bug)
> + /kisskb/src/arch/parisc/kernel/vdso32/restart_syscall.S: Error: .cfi_endproc without corresponding .cfi_startproc: => 32
> + /kisskb/src/arch/parisc/kernel/vdso32/restart_syscall.S: Error: bad or irreducible absolute expression: => 16
> + /kisskb/src/arch/parisc/kernel/vdso32/restart_syscall.S: Error: junk at end of line, first unrecognized character is `:': => 16
> + /kisskb/src/arch/parisc/kernel/vdso32/restart_syscall.S: Error: no such instruction: `be 0x100(%sr2,%r0)': => 29
> + /kisskb/src/arch/parisc/kernel/vdso32/restart_syscall.S: Error: no such instruction: `ldi 0,%r20': => 30
> + /kisskb/src/arch/parisc/kernel/vdso32/restart_syscall.S: Error: no such instruction: `ldw 0(%sp),%r31': => 26
> + /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: no such instruction: `ble 0x100(%sr2,%r0)': => 51, 46
> + /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: no such instruction: `ldi 0,%r25': => 44
> + /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: no such instruction: `ldi 1,%r25': => 49
> + /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: no such instruction: `ldi 173,%r20': => 45, 50
> + /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: unknown pseudo-op: `.callinfo': => 40
> + /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: unknown pseudo-op: `.entry': => 41
> + /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: unknown pseudo-op: `.exit': => 54
> + /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: unknown pseudo-op: `.proc': => 39
> + /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: unknown pseudo-op: `.procend': => 55
> + /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: unknown pseudo-op: `.stringz': => 76
parisc64-gcc8/generic-64bit_defconfig
parisc-gcc8/generic-32bit_defconfig
parisc-gcc8/parisc-allmodconfig
parisc-gcc8/parisc-allnoconfig
> + /kisskb/src/arch/sparc/kernel/irq_32.c: error: array subscript [16, 79] is outside array bounds of 'struct tt_entry[1]' [-Werror=array-bounds]: => 262:14, 261:46, 259:14, 258:14, 263:14
sparc64-gcc11/sparc-allmodconfig
> + /kisskb/src/drivers/gpu/drm/r128/r128_cce.c: error: case label does not reduce to an integer constant: => 417:2, 418:2
arm64-gcc5.4/arm64-allmodconfig
mipsel/mips-allmodconfig
powerpc-gcc5/powerpc-allmodconfig
powerpc-gcc5/powerpc-allyesconfig
powerpc-gcc5/ppc32_allmodconfig
powerpc-gcc5/ppc64_book3e_allmodconfig
powerpc-gcc5/ppc64le_allmodconfig
> + /kisskb/src/drivers/infiniband/hw/qib/qib_wc_x86_64.c: error: 'X86_VENDOR_AMD' undeclared (first use in this function): => 149:37
> + /kisskb/src/drivers/infiniband/hw/qib/qib_wc_x86_64.c: error: 'struct cpuinfo_um' has no member named 'x86_vendor': => 149:22
> + /kisskb/src/drivers/infiniband/hw/qib/qib_wc_x86_64.c: error: control reaches end of non-void function [-Werror=return-type]: => 150:1
> + /kisskb/src/drivers/infiniband/sw/rdmavt/qp.c: error: 'struct cpuinfo_um' has no member named 'x86_cache_size': => 88:22
> + /kisskb/src/drivers/infiniband/sw/rdmavt/qp.c: error: control reaches end of non-void function [-Werror=return-type]: => 89:1
> + /kisskb/src/drivers/infiniband/sw/rdmavt/qp.c: error: implicit declaration of function '__copy_user_nocache' [-Werror=implicit-function-declaration]: => 100:2
um-x86_64/um-allmodconfig
um-x86_64/um-allyesconfig
> + /kisskb/src/drivers/media/platform/nxp/imx-pxp.h: error: initializer element is not constant: => 582:38
arm64-gcc5.4/arm64-allmodconfig
powerpc-gcc5/powerpc-allmodconfig
> + /kisskb/src/drivers/misc/habanalabs/common/memory.c: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]: => 153:49, 153:7
mipsel/mips-allmodconfig
mips-gcc8/mips-allmodconfig
sparc64/sparc-allmodconfig
xtensa-gcc11/xtensa-allmodconfig
> + /kisskb/src/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c: error: case label does not reduce to an integer constant: => 4917:4
> + /kisskb/src/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c: error: case label does not reduce to an integer constant: => 3798:2, 3809:2
arm64-gcc5.4/arm64-allmodconfig
powerpc-gcc5/powerpc-allmodconfig
powerpc-gcc5/ppc64_book3e_allmodconfig
> + /kisskb/src/drivers/scsi/aacraid/commsup.c: error: case label does not reduce to an integer constant: => 1983:2
arm64-gcc5.4/arm64-allmodconfig
powerpc-gcc5/powerpc-allmodconfig
powerpc-gcc5/ppc64_book3e_allmodconfig
powerpc-gcc5/ppc64le_allmodconfig
> + /kisskb/src/drivers/tty/serial/mpc52xx_uart.c: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]: => 1004:12, 1005:12, 1006:14, 970:12, 968:16, 971:14, 969:12, 1002:16, 1003:16, 967:16
powerpc-gcc5/ppc32_allmodconfig
> + /kisskb/src/drivers/usb/typec/tcpm/tcpm.c: error: case label does not reduce to an integer constant: => 4724:3
arm64-gcc5.4/arm64-allmodconfig
powerpc-gcc5/powerpc-allmodconfig
powerpc-gcc5/ppc64_book3e_allmodconfig
> + /kisskb/src/fs/xfs/xfs_buf.h: error: initializer element is not constant: => 46:23
> + /kisskb/src/sound/usb/midi.c: error: case label does not reduce to an integer constant: => 1389:2
arm64-gcc5.4/arm64-allmodconfig
mipsel/mips-allmodconfig
powerpc-gcc5/powerpc-allmodconfig
powerpc-gcc5/powerpc-allyesconfig
powerpc-gcc5/ppc32_allmodconfig
powerpc-gcc5/ppc64_book3e_allmodconfig
powerpc-gcc5/ppc64le_allmodconfig
> + /kisskb/src/include/linux/compiler_types.h: error: call to '__compiletime_assert_402' declared with attribute error: FIELD_PREP: mask is not constant: => 352:38
> + /kisskb/src/include/linux/compiler_types.h: error: call to '__compiletime_assert_404' declared with attribute error: FIELD_PREP: mask is not constant: => 352:38
powerpc-gcc5/powerpc-allmodconfig
> *** WARNINGS ***
>
> 5 warning regressions:
> + /kisskb/src/arch/m68k/include/asm/string.h: warning: '__builtin_memset' offset [0, 11] is out of the bounds [0, 0] [-Warray-bounds]: => 68:25
m68k-gcc11/sun3_defconfig
> + /kisskb/src/arch/s390/kernel/machine_kexec.c: warning: 'memcpy' offset [0, 511] is out of the bounds [0, 0] [-Warray-bounds]: => 57:9
s390x-gcc11/s390-defconfig
> + /kisskb/src/drivers/net/ethernet/i825xx/sun3_82586.c: warning: array subscript 1 is above array bounds of 'volatile struct transmit_cmd_struct *[1]' [-Warray-bounds]: => 989:108, 989:122
m68k-gcc11/sun3_defconfig
m68k-gcc8/sun3_defconfig
> + /kisskb/src/drivers/scsi/mpt3sas/mpt3sas_base.c: warning: array subscript 'Mpi2SasIOUnitPage1_t {aka struct _MPI2_CONFIG_PAGE_SASIOUNIT_1}[0]' is partly outside array bounds of 'unsigned char[20]' [-Warray-bounds]: => 5400:40, 5403:43, 5396:40
powerpc-gcc11/skiroot_defconfig
> + modpost: WARNING: modpost: EXPORT symbol "_mcount" [vmlinux] version generation failed, symbol will not be versioned.: => N/A
sparc64-gcc11/sparc64-defconfig
sparc64/sparc64-defconfig
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Build regressions/improvements in v5.18-rc1
@ 2022-04-04 8:16 ` Geert Uytterhoeven
0 siblings, 0 replies; 36+ messages in thread
From: Geert Uytterhoeven @ 2022-04-04 8:16 UTC (permalink / raw)
To: linux-kernel
Cc: linux-wireless, alsa-devel, linux-usb, linux-scsi, linux-parisc,
Dennis Dalessandro, linux-rdma, netdev, Mike Marciniszyn,
linux-um, dri-devel, linux-xfs, linux-m68k, linux-serial,
sparclinux, linux-s390, linux-media
On Mon, 4 Apr 2022, Geert Uytterhoeven wrote:
> Below is the list of build error/warning regressions/improvements in
> v5.18-rc1[1] compared to v5.17[2].
>
> Summarized:
> - build errors: +36/-15
> - build warnings: +5/-38
>
> Happy fixing! ;-)
>
> Thanks to the linux-next team for providing the build service.
>
> [1] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/3123109284176b1532874591f7c81f3837bbdc17/ (all 96 configs)
> [2] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/f443e374ae131c168a065ea1748feac6b2e76613/ (all 96 configs)
>
>
> *** ERRORS ***
>
> 36 error regressions:
> + /kisskb/src/arch/m68k/include/asm/bitops.h: error: array subscript 2 is above array bounds of 'long unsigned int[1]' [-Werror=array-bounds]: => 329:20
m68k-gcc8/m68k-allmodconfig (assumed gcc8 bug)
> + /kisskb/src/arch/parisc/kernel/vdso32/restart_syscall.S: Error: .cfi_endproc without corresponding .cfi_startproc: => 32
> + /kisskb/src/arch/parisc/kernel/vdso32/restart_syscall.S: Error: bad or irreducible absolute expression: => 16
> + /kisskb/src/arch/parisc/kernel/vdso32/restart_syscall.S: Error: junk at end of line, first unrecognized character is `:': => 16
> + /kisskb/src/arch/parisc/kernel/vdso32/restart_syscall.S: Error: no such instruction: `be 0x100(%sr2,%r0)': => 29
> + /kisskb/src/arch/parisc/kernel/vdso32/restart_syscall.S: Error: no such instruction: `ldi 0,%r20': => 30
> + /kisskb/src/arch/parisc/kernel/vdso32/restart_syscall.S: Error: no such instruction: `ldw 0(%sp),%r31': => 26
> + /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: no such instruction: `ble 0x100(%sr2,%r0)': => 51, 46
> + /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: no such instruction: `ldi 0,%r25': => 44
> + /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: no such instruction: `ldi 1,%r25': => 49
> + /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: no such instruction: `ldi 173,%r20': => 45, 50
> + /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: unknown pseudo-op: `.callinfo': => 40
> + /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: unknown pseudo-op: `.entry': => 41
> + /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: unknown pseudo-op: `.exit': => 54
> + /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: unknown pseudo-op: `.proc': => 39
> + /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: unknown pseudo-op: `.procend': => 55
> + /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: unknown pseudo-op: `.stringz': => 76
parisc64-gcc8/generic-64bit_defconfig
parisc-gcc8/generic-32bit_defconfig
parisc-gcc8/parisc-allmodconfig
parisc-gcc8/parisc-allnoconfig
> + /kisskb/src/arch/sparc/kernel/irq_32.c: error: array subscript [16, 79] is outside array bounds of 'struct tt_entry[1]' [-Werror=array-bounds]: => 262:14, 261:46, 259:14, 258:14, 263:14
sparc64-gcc11/sparc-allmodconfig
> + /kisskb/src/drivers/gpu/drm/r128/r128_cce.c: error: case label does not reduce to an integer constant: => 417:2, 418:2
arm64-gcc5.4/arm64-allmodconfig
mipsel/mips-allmodconfig
powerpc-gcc5/powerpc-allmodconfig
powerpc-gcc5/powerpc-allyesconfig
powerpc-gcc5/ppc32_allmodconfig
powerpc-gcc5/ppc64_book3e_allmodconfig
powerpc-gcc5/ppc64le_allmodconfig
> + /kisskb/src/drivers/infiniband/hw/qib/qib_wc_x86_64.c: error: 'X86_VENDOR_AMD' undeclared (first use in this function): => 149:37
> + /kisskb/src/drivers/infiniband/hw/qib/qib_wc_x86_64.c: error: 'struct cpuinfo_um' has no member named 'x86_vendor': => 149:22
> + /kisskb/src/drivers/infiniband/hw/qib/qib_wc_x86_64.c: error: control reaches end of non-void function [-Werror=return-type]: => 150:1
> + /kisskb/src/drivers/infiniband/sw/rdmavt/qp.c: error: 'struct cpuinfo_um' has no member named 'x86_cache_size': => 88:22
> + /kisskb/src/drivers/infiniband/sw/rdmavt/qp.c: error: control reaches end of non-void function [-Werror=return-type]: => 89:1
> + /kisskb/src/drivers/infiniband/sw/rdmavt/qp.c: error: implicit declaration of function '__copy_user_nocache' [-Werror=implicit-function-declaration]: => 100:2
um-x86_64/um-allmodconfig
um-x86_64/um-allyesconfig
> + /kisskb/src/drivers/media/platform/nxp/imx-pxp.h: error: initializer element is not constant: => 582:38
arm64-gcc5.4/arm64-allmodconfig
powerpc-gcc5/powerpc-allmodconfig
> + /kisskb/src/drivers/misc/habanalabs/common/memory.c: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]: => 153:49, 153:7
mipsel/mips-allmodconfig
mips-gcc8/mips-allmodconfig
sparc64/sparc-allmodconfig
xtensa-gcc11/xtensa-allmodconfig
> + /kisskb/src/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c: error: case label does not reduce to an integer constant: => 4917:4
> + /kisskb/src/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c: error: case label does not reduce to an integer constant: => 3798:2, 3809:2
arm64-gcc5.4/arm64-allmodconfig
powerpc-gcc5/powerpc-allmodconfig
powerpc-gcc5/ppc64_book3e_allmodconfig
> + /kisskb/src/drivers/scsi/aacraid/commsup.c: error: case label does not reduce to an integer constant: => 1983:2
arm64-gcc5.4/arm64-allmodconfig
powerpc-gcc5/powerpc-allmodconfig
powerpc-gcc5/ppc64_book3e_allmodconfig
powerpc-gcc5/ppc64le_allmodconfig
> + /kisskb/src/drivers/tty/serial/mpc52xx_uart.c: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]: => 1004:12, 1005:12, 1006:14, 970:12, 968:16, 971:14, 969:12, 1002:16, 1003:16, 967:16
powerpc-gcc5/ppc32_allmodconfig
> + /kisskb/src/drivers/usb/typec/tcpm/tcpm.c: error: case label does not reduce to an integer constant: => 4724:3
arm64-gcc5.4/arm64-allmodconfig
powerpc-gcc5/powerpc-allmodconfig
powerpc-gcc5/ppc64_book3e_allmodconfig
> + /kisskb/src/fs/xfs/xfs_buf.h: error: initializer element is not constant: => 46:23
> + /kisskb/src/sound/usb/midi.c: error: case label does not reduce to an integer constant: => 1389:2
arm64-gcc5.4/arm64-allmodconfig
mipsel/mips-allmodconfig
powerpc-gcc5/powerpc-allmodconfig
powerpc-gcc5/powerpc-allyesconfig
powerpc-gcc5/ppc32_allmodconfig
powerpc-gcc5/ppc64_book3e_allmodconfig
powerpc-gcc5/ppc64le_allmodconfig
> + /kisskb/src/include/linux/compiler_types.h: error: call to '__compiletime_assert_402' declared with attribute error: FIELD_PREP: mask is not constant: => 352:38
> + /kisskb/src/include/linux/compiler_types.h: error: call to '__compiletime_assert_404' declared with attribute error: FIELD_PREP: mask is not constant: => 352:38
powerpc-gcc5/powerpc-allmodconfig
> *** WARNINGS ***
>
> 5 warning regressions:
> + /kisskb/src/arch/m68k/include/asm/string.h: warning: '__builtin_memset' offset [0, 11] is out of the bounds [0, 0] [-Warray-bounds]: => 68:25
m68k-gcc11/sun3_defconfig
> + /kisskb/src/arch/s390/kernel/machine_kexec.c: warning: 'memcpy' offset [0, 511] is out of the bounds [0, 0] [-Warray-bounds]: => 57:9
s390x-gcc11/s390-defconfig
> + /kisskb/src/drivers/net/ethernet/i825xx/sun3_82586.c: warning: array subscript 1 is above array bounds of 'volatile struct transmit_cmd_struct *[1]' [-Warray-bounds]: => 989:108, 989:122
m68k-gcc11/sun3_defconfig
m68k-gcc8/sun3_defconfig
> + /kisskb/src/drivers/scsi/mpt3sas/mpt3sas_base.c: warning: array subscript 'Mpi2SasIOUnitPage1_t {aka struct _MPI2_CONFIG_PAGE_SASIOUNIT_1}[0]' is partly outside array bounds of 'unsigned char[20]' [-Warray-bounds]: => 5400:40, 5403:43, 5396:40
powerpc-gcc11/skiroot_defconfig
> + modpost: WARNING: modpost: EXPORT symbol "_mcount" [vmlinux] version generation failed, symbol will not be versioned.: => N/A
sparc64-gcc11/sparc64-defconfig
sparc64/sparc64-defconfig
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Build regressions/improvements in v5.18-rc1
@ 2022-04-04 8:16 ` Geert Uytterhoeven
0 siblings, 0 replies; 36+ messages in thread
From: Geert Uytterhoeven @ 2022-04-04 8:16 UTC (permalink / raw)
To: linux-kernel
Cc: linux-m68k, linux-parisc, sparclinux, dri-devel,
Dennis Dalessandro, Mike Marciniszyn, linux-rdma, linux-um,
linux-media, netdev, linux-wireless, linux-scsi, linux-serial,
linux-usb, linux-xfs, alsa-devel, linux-s390
On Mon, 4 Apr 2022, Geert Uytterhoeven wrote:
> Below is the list of build error/warning regressions/improvements in
> v5.18-rc1[1] compared to v5.17[2].
>
> Summarized:
> - build errors: +36/-15
> - build warnings: +5/-38
>
> Happy fixing! ;-)
>
> Thanks to the linux-next team for providing the build service.
>
> [1] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/3123109284176b1532874591f7c81f3837bbdc17/ (all 96 configs)
> [2] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/f443e374ae131c168a065ea1748feac6b2e76613/ (all 96 configs)
>
>
> *** ERRORS ***
>
> 36 error regressions:
> + /kisskb/src/arch/m68k/include/asm/bitops.h: error: array subscript 2 is above array bounds of 'long unsigned int[1]' [-Werror=array-bounds]: => 329:20
m68k-gcc8/m68k-allmodconfig (assumed gcc8 bug)
> + /kisskb/src/arch/parisc/kernel/vdso32/restart_syscall.S: Error: .cfi_endproc without corresponding .cfi_startproc: => 32
> + /kisskb/src/arch/parisc/kernel/vdso32/restart_syscall.S: Error: bad or irreducible absolute expression: => 16
> + /kisskb/src/arch/parisc/kernel/vdso32/restart_syscall.S: Error: junk at end of line, first unrecognized character is `:': => 16
> + /kisskb/src/arch/parisc/kernel/vdso32/restart_syscall.S: Error: no such instruction: `be 0x100(%sr2,%r0)': => 29
> + /kisskb/src/arch/parisc/kernel/vdso32/restart_syscall.S: Error: no such instruction: `ldi 0,%r20': => 30
> + /kisskb/src/arch/parisc/kernel/vdso32/restart_syscall.S: Error: no such instruction: `ldw 0(%sp),%r31': => 26
> + /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: no such instruction: `ble 0x100(%sr2,%r0)': => 51, 46
> + /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: no such instruction: `ldi 0,%r25': => 44
> + /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: no such instruction: `ldi 1,%r25': => 49
> + /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: no such instruction: `ldi 173,%r20': => 45, 50
> + /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: unknown pseudo-op: `.callinfo': => 40
> + /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: unknown pseudo-op: `.entry': => 41
> + /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: unknown pseudo-op: `.exit': => 54
> + /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: unknown pseudo-op: `.proc': => 39
> + /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: unknown pseudo-op: `.procend': => 55
> + /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: unknown pseudo-op: `.stringz': => 76
parisc64-gcc8/generic-64bit_defconfig
parisc-gcc8/generic-32bit_defconfig
parisc-gcc8/parisc-allmodconfig
parisc-gcc8/parisc-allnoconfig
> + /kisskb/src/arch/sparc/kernel/irq_32.c: error: array subscript [16, 79] is outside array bounds of 'struct tt_entry[1]' [-Werror=array-bounds]: => 262:14, 261:46, 259:14, 258:14, 263:14
sparc64-gcc11/sparc-allmodconfig
> + /kisskb/src/drivers/gpu/drm/r128/r128_cce.c: error: case label does not reduce to an integer constant: => 417:2, 418:2
arm64-gcc5.4/arm64-allmodconfig
mipsel/mips-allmodconfig
powerpc-gcc5/powerpc-allmodconfig
powerpc-gcc5/powerpc-allyesconfig
powerpc-gcc5/ppc32_allmodconfig
powerpc-gcc5/ppc64_book3e_allmodconfig
powerpc-gcc5/ppc64le_allmodconfig
> + /kisskb/src/drivers/infiniband/hw/qib/qib_wc_x86_64.c: error: 'X86_VENDOR_AMD' undeclared (first use in this function): => 149:37
> + /kisskb/src/drivers/infiniband/hw/qib/qib_wc_x86_64.c: error: 'struct cpuinfo_um' has no member named 'x86_vendor': => 149:22
> + /kisskb/src/drivers/infiniband/hw/qib/qib_wc_x86_64.c: error: control reaches end of non-void function [-Werror=return-type]: => 150:1
> + /kisskb/src/drivers/infiniband/sw/rdmavt/qp.c: error: 'struct cpuinfo_um' has no member named 'x86_cache_size': => 88:22
> + /kisskb/src/drivers/infiniband/sw/rdmavt/qp.c: error: control reaches end of non-void function [-Werror=return-type]: => 89:1
> + /kisskb/src/drivers/infiniband/sw/rdmavt/qp.c: error: implicit declaration of function '__copy_user_nocache' [-Werror=implicit-function-declaration]: => 100:2
um-x86_64/um-allmodconfig
um-x86_64/um-allyesconfig
> + /kisskb/src/drivers/media/platform/nxp/imx-pxp.h: error: initializer element is not constant: => 582:38
arm64-gcc5.4/arm64-allmodconfig
powerpc-gcc5/powerpc-allmodconfig
> + /kisskb/src/drivers/misc/habanalabs/common/memory.c: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]: => 153:49, 153:7
mipsel/mips-allmodconfig
mips-gcc8/mips-allmodconfig
sparc64/sparc-allmodconfig
xtensa-gcc11/xtensa-allmodconfig
> + /kisskb/src/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c: error: case label does not reduce to an integer constant: => 4917:4
> + /kisskb/src/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c: error: case label does not reduce to an integer constant: => 3798:2, 3809:2
arm64-gcc5.4/arm64-allmodconfig
powerpc-gcc5/powerpc-allmodconfig
powerpc-gcc5/ppc64_book3e_allmodconfig
> + /kisskb/src/drivers/scsi/aacraid/commsup.c: error: case label does not reduce to an integer constant: => 1983:2
arm64-gcc5.4/arm64-allmodconfig
powerpc-gcc5/powerpc-allmodconfig
powerpc-gcc5/ppc64_book3e_allmodconfig
powerpc-gcc5/ppc64le_allmodconfig
> + /kisskb/src/drivers/tty/serial/mpc52xx_uart.c: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]: => 1004:12, 1005:12, 1006:14, 970:12, 968:16, 971:14, 969:12, 1002:16, 1003:16, 967:16
powerpc-gcc5/ppc32_allmodconfig
> + /kisskb/src/drivers/usb/typec/tcpm/tcpm.c: error: case label does not reduce to an integer constant: => 4724:3
arm64-gcc5.4/arm64-allmodconfig
powerpc-gcc5/powerpc-allmodconfig
powerpc-gcc5/ppc64_book3e_allmodconfig
> + /kisskb/src/fs/xfs/xfs_buf.h: error: initializer element is not constant: => 46:23
> + /kisskb/src/sound/usb/midi.c: error: case label does not reduce to an integer constant: => 1389:2
arm64-gcc5.4/arm64-allmodconfig
mipsel/mips-allmodconfig
powerpc-gcc5/powerpc-allmodconfig
powerpc-gcc5/powerpc-allyesconfig
powerpc-gcc5/ppc32_allmodconfig
powerpc-gcc5/ppc64_book3e_allmodconfig
powerpc-gcc5/ppc64le_allmodconfig
> + /kisskb/src/include/linux/compiler_types.h: error: call to '__compiletime_assert_402' declared with attribute error: FIELD_PREP: mask is not constant: => 352:38
> + /kisskb/src/include/linux/compiler_types.h: error: call to '__compiletime_assert_404' declared with attribute error: FIELD_PREP: mask is not constant: => 352:38
powerpc-gcc5/powerpc-allmodconfig
> *** WARNINGS ***
>
> 5 warning regressions:
> + /kisskb/src/arch/m68k/include/asm/string.h: warning: '__builtin_memset' offset [0, 11] is out of the bounds [0, 0] [-Warray-bounds]: => 68:25
m68k-gcc11/sun3_defconfig
> + /kisskb/src/arch/s390/kernel/machine_kexec.c: warning: 'memcpy' offset [0, 511] is out of the bounds [0, 0] [-Warray-bounds]: => 57:9
s390x-gcc11/s390-defconfig
> + /kisskb/src/drivers/net/ethernet/i825xx/sun3_82586.c: warning: array subscript 1 is above array bounds of 'volatile struct transmit_cmd_struct *[1]' [-Warray-bounds]: => 989:108, 989:122
m68k-gcc11/sun3_defconfig
m68k-gcc8/sun3_defconfig
> + /kisskb/src/drivers/scsi/mpt3sas/mpt3sas_base.c: warning: array subscript 'Mpi2SasIOUnitPage1_t {aka struct _MPI2_CONFIG_PAGE_SASIOUNIT_1}[0]' is partly outside array bounds of 'unsigned char[20]' [-Warray-bounds]: => 5400:40, 5403:43, 5396:40
powerpc-gcc11/skiroot_defconfig
> + modpost: WARNING: modpost: EXPORT symbol "_mcount" [vmlinux] version generation failed, symbol will not be versioned.: => N/A
sparc64-gcc11/sparc64-defconfig
sparc64/sparc64-defconfig
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Build regressions/improvements in v5.18-rc1
2022-04-04 8:16 ` Geert Uytterhoeven
@ 2022-04-04 9:26 ` Dave Chinner
-1 siblings, 0 replies; 36+ messages in thread
From: Dave Chinner @ 2022-04-04 9:26 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linux-kernel, linux-m68k, linux-parisc, sparclinux, dri-devel,
Dennis Dalessandro, Mike Marciniszyn, linux-rdma, linux-um,
linux-media, netdev, linux-wireless, linux-scsi, linux-serial,
linux-usb, linux-xfs, alsa-devel, linux-s390
On Mon, Apr 04, 2022 at 10:16:08AM +0200, Geert Uytterhoeven wrote:
> On Mon, 4 Apr 2022, Geert Uytterhoeven wrote:
> > Below is the list of build error/warning regressions/improvements in
> > v5.18-rc1[1] compared to v5.17[2].
> >
> > Summarized:
> > - build errors: +36/-15
> > - build warnings: +5/-38
> >
> > Happy fixing! ;-)
Well....
> > + /kisskb/src/fs/xfs/xfs_buf.h: error: initializer element is not constant: => 46:23
Looking at:
http://kisskb.ellerman.id.au/kisskb/buildresult/14714961/
The build error is:
/kisskb/src/fs/xfs/./xfs_trace.h:432:2: note: in expansion of macro 'TP_printk'
TP_printk("dev %d:%d daddr 0x%llx bbcount 0x%x hold %d pincount %d "
^
/kisskb/src/fs/xfs/./xfs_trace.h:440:5: note: in expansion of macro '__print_flags'
__print_flags(__entry->flags, "|", XFS_BUF_FLAGS),
^
/kisskb/src/fs/xfs/xfs_buf.h:67:4: note: in expansion of macro 'XBF_UNMAPPED'
{ XBF_UNMAPPED, "UNMAPPED" }
^
/kisskb/src/fs/xfs/./xfs_trace.h:440:40: note: in expansion of macro 'XFS_BUF_FLAGS'
__print_flags(__entry->flags, "|", XFS_BUF_FLAGS),
^
/kisskb/src/fs/xfs/./xfs_trace.h: In function 'trace_raw_output_xfs_buf_flags_class':
/kisskb/src/fs/xfs/xfs_buf.h:46:23: error: initializer element is not constant
#define XBF_UNMAPPED (1 << 31)/* do not map the buffer */
This doesn't make a whole lotta sense to me. It's blown up in a
tracepoint macro in XFS that was not changed at all in 5.18-rc1, nor
was any of the surrounding XFS code or contexts. Perhaps something
outside XFS changed to cause this on these platforms?
Can you bisect this, please?
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Build regressions/improvements in v5.18-rc1
@ 2022-04-04 9:26 ` Dave Chinner
0 siblings, 0 replies; 36+ messages in thread
From: Dave Chinner @ 2022-04-04 9:26 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linux-wireless, alsa-devel, linux-usb, linux-scsi, linux-parisc,
Dennis Dalessandro, linux-rdma, netdev, Mike Marciniszyn,
linux-um, linux-kernel, dri-devel, linux-xfs, linux-m68k,
linux-serial, sparclinux, linux-s390, linux-media
On Mon, Apr 04, 2022 at 10:16:08AM +0200, Geert Uytterhoeven wrote:
> On Mon, 4 Apr 2022, Geert Uytterhoeven wrote:
> > Below is the list of build error/warning regressions/improvements in
> > v5.18-rc1[1] compared to v5.17[2].
> >
> > Summarized:
> > - build errors: +36/-15
> > - build warnings: +5/-38
> >
> > Happy fixing! ;-)
Well....
> > + /kisskb/src/fs/xfs/xfs_buf.h: error: initializer element is not constant: => 46:23
Looking at:
http://kisskb.ellerman.id.au/kisskb/buildresult/14714961/
The build error is:
/kisskb/src/fs/xfs/./xfs_trace.h:432:2: note: in expansion of macro 'TP_printk'
TP_printk("dev %d:%d daddr 0x%llx bbcount 0x%x hold %d pincount %d "
^
/kisskb/src/fs/xfs/./xfs_trace.h:440:5: note: in expansion of macro '__print_flags'
__print_flags(__entry->flags, "|", XFS_BUF_FLAGS),
^
/kisskb/src/fs/xfs/xfs_buf.h:67:4: note: in expansion of macro 'XBF_UNMAPPED'
{ XBF_UNMAPPED, "UNMAPPED" }
^
/kisskb/src/fs/xfs/./xfs_trace.h:440:40: note: in expansion of macro 'XFS_BUF_FLAGS'
__print_flags(__entry->flags, "|", XFS_BUF_FLAGS),
^
/kisskb/src/fs/xfs/./xfs_trace.h: In function 'trace_raw_output_xfs_buf_flags_class':
/kisskb/src/fs/xfs/xfs_buf.h:46:23: error: initializer element is not constant
#define XBF_UNMAPPED (1 << 31)/* do not map the buffer */
This doesn't make a whole lotta sense to me. It's blown up in a
tracepoint macro in XFS that was not changed at all in 5.18-rc1, nor
was any of the surrounding XFS code or contexts. Perhaps something
outside XFS changed to cause this on these platforms?
Can you bisect this, please?
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Build regressions/improvements in v5.18-rc1
2022-04-04 9:26 ` Dave Chinner
(?)
@ 2022-04-04 10:19 ` Geert Uytterhoeven
2022-04-04 11:45 ` Arnd Bergmann
-1 siblings, 1 reply; 36+ messages in thread
From: Geert Uytterhoeven @ 2022-04-04 10:19 UTC (permalink / raw)
To: Dave Chinner; +Cc: Linux Kernel Mailing List, linux-xfs, Arnd Bergmann
Hi Dave
CC Arnd
On Mon, Apr 4, 2022 at 11:27 AM Dave Chinner <david@fromorbit.com> wrote:
> On Mon, Apr 04, 2022 at 10:16:08AM +0200, Geert Uytterhoeven wrote:
> > On Mon, 4 Apr 2022, Geert Uytterhoeven wrote:
> > > Below is the list of build error/warning regressions/improvements in
> > > v5.18-rc1[1] compared to v5.17[2].
> > >
> > > Summarized:
> > > - build errors: +36/-15
> > > - build warnings: +5/-38
> > >
> > > Happy fixing! ;-)
>
> Well....
>
> > > + /kisskb/src/fs/xfs/xfs_buf.h: error: initializer element is not constant: => 46:23
>
> Looking at:
>
> http://kisskb.ellerman.id.au/kisskb/buildresult/14714961/
>
> The build error is:
>
> /kisskb/src/fs/xfs/./xfs_trace.h:432:2: note: in expansion of macro 'TP_printk'
> TP_printk("dev %d:%d daddr 0x%llx bbcount 0x%x hold %d pincount %d "
> ^
> /kisskb/src/fs/xfs/./xfs_trace.h:440:5: note: in expansion of macro '__print_flags'
> __print_flags(__entry->flags, "|", XFS_BUF_FLAGS),
> ^
> /kisskb/src/fs/xfs/xfs_buf.h:67:4: note: in expansion of macro 'XBF_UNMAPPED'
> { XBF_UNMAPPED, "UNMAPPED" }
> ^
> /kisskb/src/fs/xfs/./xfs_trace.h:440:40: note: in expansion of macro 'XFS_BUF_FLAGS'
> __print_flags(__entry->flags, "|", XFS_BUF_FLAGS),
> ^
> /kisskb/src/fs/xfs/./xfs_trace.h: In function 'trace_raw_output_xfs_buf_flags_class':
> /kisskb/src/fs/xfs/xfs_buf.h:46:23: error: initializer element is not constant
> #define XBF_UNMAPPED (1 << 31)/* do not map the buffer */
>
> This doesn't make a whole lotta sense to me. It's blown up in a
> tracepoint macro in XFS that was not changed at all in 5.18-rc1, nor
> was any of the surrounding XFS code or contexts. Perhaps something
> outside XFS changed to cause this on these platforms?
Upon closer look, all builds showing this issue are using gcc-5...
> Can you bisect this, please?
Fortunately I still have gcc-5 installed on an older machine,
and I could reproduce the issue on amd64 with
"make allmodconfig fs/xfs/xfs_trace.o".
Bisection points to commit e8c07082a810fbb9 ("Kbuild: move to
-std=gnu11").
[1] gcc version 5.5.0 20171010 (Ubuntu 5.5.0-12ubuntu1
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Build regressions/improvements in v5.18-rc1
2022-04-04 10:19 ` Geert Uytterhoeven
@ 2022-04-04 11:45 ` Arnd Bergmann
2022-04-04 12:31 ` Arnd Bergmann
2022-04-04 22:16 ` Dave Chinner
0 siblings, 2 replies; 36+ messages in thread
From: Arnd Bergmann @ 2022-04-04 11:45 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Dave Chinner, Linux Kernel Mailing List, linux-xfs, Arnd Bergmann
On Mon, Apr 4, 2022 at 12:19 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> >
> > /kisskb/src/fs/xfs/./xfs_trace.h:432:2: note: in expansion of macro 'TP_printk'
> > TP_printk("dev %d:%d daddr 0x%llx bbcount 0x%x hold %d pincount %d "
> > ^
> > /kisskb/src/fs/xfs/./xfs_trace.h:440:5: note: in expansion of macro '__print_flags'
> > __print_flags(__entry->flags, "|", XFS_BUF_FLAGS),
> > ^
> > /kisskb/src/fs/xfs/xfs_buf.h:67:4: note: in expansion of macro 'XBF_UNMAPPED'
> > { XBF_UNMAPPED, "UNMAPPED" }
> > ^
> > /kisskb/src/fs/xfs/./xfs_trace.h:440:40: note: in expansion of macro 'XFS_BUF_FLAGS'
> > __print_flags(__entry->flags, "|", XFS_BUF_FLAGS),
> > ^
> > /kisskb/src/fs/xfs/./xfs_trace.h: In function 'trace_raw_output_xfs_buf_flags_class':
> > /kisskb/src/fs/xfs/xfs_buf.h:46:23: error: initializer element is not constant
> > #define XBF_UNMAPPED (1 << 31)/* do not map the buffer */
> >
> > This doesn't make a whole lotta sense to me. It's blown up in a
> > tracepoint macro in XFS that was not changed at all in 5.18-rc1, nor
> > was any of the surrounding XFS code or contexts. Perhaps something
> > outside XFS changed to cause this on these platforms?
>
> Upon closer look, all builds showing this issue are using gcc-5...
>
> > Can you bisect this, please?
>
> Fortunately I still have gcc-5 installed on an older machine,
> and I could reproduce the issue on amd64 with
> "make allmodconfig fs/xfs/xfs_trace.o".
>
> Bisection points to commit e8c07082a810fbb9 ("Kbuild: move to
> -std=gnu11").
>
> [1] gcc version 5.5.0 20171010 (Ubuntu 5.5.0-12ubuntu1
Thanks for the report. I've produced it and can see that the problem
is assigning
the value of "(1 << 31)" to an 'unsigned long' struct member. Since this is
a signed integer overflow, the result is technically undefined behavior,
which gcc-5 does not accept as an integer constant.
The patch below fixes it for me, but I have not checked if there are any
other instances. This could also be done using the 'BIT()' macro if the
XFS maintainers prefer:
diff --git a/fs/xfs/xfs_buf.h b/fs/xfs/xfs_buf.h
index edcb6254fa6a..762348973e8c 100644
--- a/fs/xfs/xfs_buf.h
+++ b/fs/xfs/xfs_buf.h
@@ -22,28 +22,28 @@ struct xfs_buf;
#define XFS_BUF_DADDR_NULL ((xfs_daddr_t) (-1LL))
-#define XBF_READ (1 << 0) /* buffer intended for reading from device */
-#define XBF_WRITE (1 << 1) /* buffer intended for writing to device */
-#define XBF_READ_AHEAD (1 << 2) /* asynchronous read-ahead */
-#define XBF_NO_IOACCT (1 << 3) /* bypass I/O accounting (non-LRU bufs) */
-#define XBF_ASYNC (1 << 4) /* initiator will not wait for completion */
-#define XBF_DONE (1 << 5) /* all pages in the buffer uptodate */
-#define XBF_STALE (1 << 6) /* buffer has been staled, do not find it */
-#define XBF_WRITE_FAIL (1 << 7) /* async writes have failed on this buffer */
+#define XBF_READ (1ul << 0) /* buffer intended for reading
from device */
+#define XBF_WRITE (1ul << 1) /* buffer intended for writing to device */
+#define XBF_READ_AHEAD (1ul << 2) /* asynchronous read-ahead */
+#define XBF_NO_IOACCT (1ul << 3) /* bypass I/O accounting (non-LRU bufs) */
+#define XBF_ASYNC (1ul << 4) /* initiator will not wait for completion */
+#define XBF_DONE (1ul << 5) /* all pages in the buffer uptodate */
+#define XBF_STALE (1ul << 6) /* buffer has been staled, do not find it */
+#define XBF_WRITE_FAIL (1ul << 7) /* async writes have failed on
this buffer */
/* buffer type flags for write callbacks */
-#define _XBF_INODES (1 << 16)/* inode buffer */
-#define _XBF_DQUOTS (1 << 17)/* dquot buffer */
-#define _XBF_LOGRECOVERY (1 << 18)/* log recovery buffer */
+#define _XBF_INODES (1ul << 16)/* inode buffer */
+#define _XBF_DQUOTS (1ul << 17)/* dquot buffer */
+#define _XBF_LOGRECOVERY (1ul << 18)/* log recovery buffer */
/* flags used only internally */
-#define _XBF_PAGES (1 << 20)/* backed by refcounted pages */
-#define _XBF_KMEM (1 << 21)/* backed by heap memory */
-#define _XBF_DELWRI_Q (1 << 22)/* buffer on a delwri queue */
+#define _XBF_PAGES (1ul << 20)/* backed by refcounted pages */
+#define _XBF_KMEM (1ul << 21)/* backed by heap memory */
+#define _XBF_DELWRI_Q (1ul << 22)/* buffer on a delwri queue */
/* flags used only as arguments to access routines */
-#define XBF_TRYLOCK (1 << 30)/* lock requested, but do not wait */
-#define XBF_UNMAPPED (1 << 31)/* do not map the buffer */
+#define XBF_TRYLOCK (1ul << 30)/* lock requested, but do not wait */
+#define XBF_UNMAPPED (1ul << 31)/* do not map the buffer */
typedef unsigned int xfs_buf_flags_t;
^ permalink raw reply related [flat|nested] 36+ messages in thread
* Re: Build regressions/improvements in v5.18-rc1
2022-04-04 11:45 ` Arnd Bergmann
@ 2022-04-04 12:31 ` Arnd Bergmann
2022-04-04 22:16 ` Dave Chinner
1 sibling, 0 replies; 36+ messages in thread
From: Arnd Bergmann @ 2022-04-04 12:31 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Geert Uytterhoeven, Dave Chinner, Linux Kernel Mailing List, linux-xfs
On Mon, Apr 4, 2022 at 1:45 PM Arnd Bergmann <arnd@arndb.de> wrote:
> On Mon, Apr 4, 2022 at 12:19 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > Fortunately I still have gcc-5 installed on an older machine,
> > and I could reproduce the issue on amd64 with
> > "make allmodconfig fs/xfs/xfs_trace.o".
> >
> > Bisection points to commit e8c07082a810fbb9 ("Kbuild: move to
> > -std=gnu11").
> >
> > [1] gcc version 5.5.0 20171010 (Ubuntu 5.5.0-12ubuntu1
>
> Thanks for the report. I've produced it and can see that the problem
> is assigning
> the value of "(1 << 31)" to an 'unsigned long' struct member. Since this is
> a signed integer overflow, the result is technically undefined behavior,
> which gcc-5 does not accept as an integer constant.
>
> The patch below fixes it for me, but I have not checked if there are any
> other instances.
There are, this is now the patch to address arm64 allmodconfig:
diff --git a/drivers/gpu/drm/r128/r128_drv.h b/drivers/gpu/drm/r128/r128_drv.h
index 2e1bc01aa5c9..69b990639b70 100644
--- a/drivers/gpu/drm/r128/r128_drv.h
+++ b/drivers/gpu/drm/r128/r128_drv.h
@@ -291,18 +291,18 @@ extern long r128_compat_ioctl(struct file *filp,
unsigned int cmd,
*/
#define R128_PM4_BUFFER_OFFSET 0x0700
#define R128_PM4_BUFFER_CNTL 0x0704
-# define R128_PM4_MASK (15 << 28)
-# define R128_PM4_NONPM4 (0 << 28)
-# define R128_PM4_192PIO (1 << 28)
-# define R128_PM4_192BM (2 << 28)
-# define R128_PM4_128PIO_64INDBM (3 << 28)
-# define R128_PM4_128BM_64INDBM (4 << 28)
-# define R128_PM4_64PIO_128INDBM (5 << 28)
-# define R128_PM4_64BM_128INDBM (6 << 28)
-# define R128_PM4_64PIO_64VCBM_64INDBM (7 << 28)
-# define R128_PM4_64BM_64VCBM_64INDBM (8 << 28)
-# define R128_PM4_64PIO_64VCPIO_64INDPIO (15 << 28)
-# define R128_PM4_BUFFER_CNTL_NOUPDATE (1 << 27)
+# define R128_PM4_MASK (15u << 28)
+# define R128_PM4_NONPM4 (0u << 28)
+# define R128_PM4_192PIO (1u << 28)
+# define R128_PM4_192BM (2u << 28)
+# define R128_PM4_128PIO_64INDBM (3u << 28)
+# define R128_PM4_128BM_64INDBM (4u << 28)
+# define R128_PM4_64PIO_128INDBM (5u << 28)
+# define R128_PM4_64BM_128INDBM (6u << 28)
+# define R128_PM4_64PIO_64VCBM_64INDBM (7u << 28)
+# define R128_PM4_64BM_64VCBM_64INDBM (8u << 28)
+# define R128_PM4_64PIO_64VCPIO_64INDPIO (15u << 28)
+# define R128_PM4_BUFFER_CNTL_NOUPDATE (1u << 27)
#define R128_PM4_BUFFER_WM_CNTL 0x0708
# define R128_WMA_SHIFT 0
diff --git a/drivers/media/platform/nxp/imx-pxp.h
b/drivers/media/platform/nxp/imx-pxp.h
index 44f95c749d2e..83cdb3fd1312 100644
--- a/drivers/media/platform/nxp/imx-pxp.h
+++ b/drivers/media/platform/nxp/imx-pxp.h
@@ -579,27 +579,27 @@
#define HW_PXP_CSC1_COEF0 (0x000001a0)
-#define BM_PXP_CSC1_COEF0_YCBCR_MODE 0x80000000
+#define BM_PXP_CSC1_COEF0_YCBCR_MODE 0x80000000u
#define BF_PXP_CSC1_COEF0_YCBCR_MODE(v) \
- (((v) << 31) & BM_PXP_CSC1_COEF0_YCBCR_MODE)
-#define BM_PXP_CSC1_COEF0_BYPASS 0x40000000
+ (((unsigned)(v) << 31) & BM_PXP_CSC1_COEF0_YCBCR_MODE)
+#define BM_PXP_CSC1_COEF0_BYPASS 0x40000000u
#define BF_PXP_CSC1_COEF0_BYPASS(v) \
- (((v) << 30) & BM_PXP_CSC1_COEF0_BYPASS)
-#define BM_PXP_CSC1_COEF0_RSVD1 0x20000000
+ (((unsigned)(v) << 30) & BM_PXP_CSC1_COEF0_BYPASS)
+#define BM_PXP_CSC1_COEF0_RSVD1 0x20000000u
#define BF_PXP_CSC1_COEF0_RSVD1(v) \
- (((v) << 29) & BM_PXP_CSC1_COEF0_RSVD1)
+ (((unsigned)(v) << 29) & BM_PXP_CSC1_COEF0_RSVD1)
#define BP_PXP_CSC1_COEF0_C0 18
-#define BM_PXP_CSC1_COEF0_C0 0x1FFC0000
+#define BM_PXP_CSC1_COEF0_C0 0x1FFC0000u
#define BF_PXP_CSC1_COEF0_C0(v) \
- (((v) << 18) & BM_PXP_CSC1_COEF0_C0)
+ (((unsigned)(v) << 18) & BM_PXP_CSC1_COEF0_C0)
#define BP_PXP_CSC1_COEF0_UV_OFFSET 9
-#define BM_PXP_CSC1_COEF0_UV_OFFSET 0x0003FE00
+#define BM_PXP_CSC1_COEF0_UV_OFFSET 0x0003FE00u
#define BF_PXP_CSC1_COEF0_UV_OFFSET(v) \
- (((v) << 9) & BM_PXP_CSC1_COEF0_UV_OFFSET)
+ (((unsigned)(v) << 9) & BM_PXP_CSC1_COEF0_UV_OFFSET)
#define BP_PXP_CSC1_COEF0_Y_OFFSET 0
-#define BM_PXP_CSC1_COEF0_Y_OFFSET 0x000001FF
+#define BM_PXP_CSC1_COEF0_Y_OFFSET 0x000001FFu
#define BF_PXP_CSC1_COEF0_Y_OFFSET(v) \
- (((v) << 0) & BM_PXP_CSC1_COEF0_Y_OFFSET)
+ (((unsigned)(v) << 0) & BM_PXP_CSC1_COEF0_Y_OFFSET)
#define HW_PXP_CSC1_COEF1 (0x000001b0)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_reg.h
b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_reg.h
index 5caa75b41b73..7fa901fb5596 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_reg.h
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_reg.h
@@ -6196,71 +6196,71 @@
#define HW_LOCK_RESOURCE_RECOVERY_REG 11
#define HW_LOCK_RESOURCE_RESET 5
#define HW_LOCK_RESOURCE_SPIO 2
-#define AEU_INPUTS_ATTN_BITS_ATC_HW_INTERRUPT (0x1<<4)
-#define AEU_INPUTS_ATTN_BITS_ATC_PARITY_ERROR (0x1<<5)
-#define AEU_INPUTS_ATTN_BITS_BRB_HW_INTERRUPT (0x1<<19)
-#define AEU_INPUTS_ATTN_BITS_BRB_PARITY_ERROR (0x1<<18)
-#define AEU_INPUTS_ATTN_BITS_CCM_HW_INTERRUPT (0x1<<31)
-#define AEU_INPUTS_ATTN_BITS_CCM_PARITY_ERROR (0x1<<30)
-#define AEU_INPUTS_ATTN_BITS_CDU_HW_INTERRUPT (0x1<<9)
-#define AEU_INPUTS_ATTN_BITS_CDU_PARITY_ERROR (0x1<<8)
-#define AEU_INPUTS_ATTN_BITS_CFC_HW_INTERRUPT (0x1<<7)
-#define AEU_INPUTS_ATTN_BITS_CFC_PARITY_ERROR (0x1<<6)
-#define AEU_INPUTS_ATTN_BITS_CSDM_HW_INTERRUPT (0x1<<29)
-#define AEU_INPUTS_ATTN_BITS_CSDM_PARITY_ERROR (0x1<<28)
-#define AEU_INPUTS_ATTN_BITS_CSEMI_HW_INTERRUPT (0x1<<1)
-#define AEU_INPUTS_ATTN_BITS_CSEMI_PARITY_ERROR (0x1<<0)
-#define AEU_INPUTS_ATTN_BITS_DEBUG_PARITY_ERROR (0x1<<18)
-#define AEU_INPUTS_ATTN_BITS_DMAE_HW_INTERRUPT (0x1<<11)
-#define AEU_INPUTS_ATTN_BITS_DMAE_PARITY_ERROR (0x1<<10)
-#define AEU_INPUTS_ATTN_BITS_DOORBELLQ_HW_INTERRUPT (0x1<<13)
-#define AEU_INPUTS_ATTN_BITS_DOORBELLQ_PARITY_ERROR (0x1<<12)
-#define AEU_INPUTS_ATTN_BITS_GPIO0_FUNCTION_0 (0x1<<2)
-#define AEU_INPUTS_ATTN_BITS_IGU_PARITY_ERROR (0x1<<12)
-#define AEU_INPUTS_ATTN_BITS_MCP_LATCHED_ROM_PARITY (0x1<<28)
-#define AEU_INPUTS_ATTN_BITS_MCP_LATCHED_SCPAD_PARITY (0x1<<31)
-#define AEU_INPUTS_ATTN_BITS_MCP_LATCHED_UMP_RX_PARITY (0x1<<29)
-#define AEU_INPUTS_ATTN_BITS_MCP_LATCHED_UMP_TX_PARITY (0x1<<30)
-#define AEU_INPUTS_ATTN_BITS_MISC_HW_INTERRUPT (0x1<<15)
-#define AEU_INPUTS_ATTN_BITS_MISC_PARITY_ERROR (0x1<<14)
-#define AEU_INPUTS_ATTN_BITS_NIG_PARITY_ERROR (0x1<<14)
-#define AEU_INPUTS_ATTN_BITS_PARSER_PARITY_ERROR (0x1<<20)
-#define AEU_INPUTS_ATTN_BITS_PBCLIENT_HW_INTERRUPT (0x1<<31)
-#define AEU_INPUTS_ATTN_BITS_PBCLIENT_PARITY_ERROR (0x1<<30)
-#define AEU_INPUTS_ATTN_BITS_PBF_PARITY_ERROR (0x1<<0)
-#define AEU_INPUTS_ATTN_BITS_PGLUE_HW_INTERRUPT (0x1<<2)
-#define AEU_INPUTS_ATTN_BITS_PGLUE_PARITY_ERROR (0x1<<3)
-#define AEU_INPUTS_ATTN_BITS_PXPPCICLOCKCLIENT_HW_INTERRUPT (0x1<<5)
-#define AEU_INPUTS_ATTN_BITS_PXPPCICLOCKCLIENT_PARITY_ERROR (0x1<<4)
-#define AEU_INPUTS_ATTN_BITS_PXP_HW_INTERRUPT (0x1<<3)
-#define AEU_INPUTS_ATTN_BITS_PXP_PARITY_ERROR (0x1<<2)
-#define AEU_INPUTS_ATTN_BITS_QM_HW_INTERRUPT (0x1<<3)
-#define AEU_INPUTS_ATTN_BITS_QM_PARITY_ERROR (0x1<<2)
-#define AEU_INPUTS_ATTN_BITS_SEARCHER_PARITY_ERROR (0x1<<22)
-#define AEU_INPUTS_ATTN_BITS_SPIO5 (0x1<<15)
-#define AEU_INPUTS_ATTN_BITS_TCM_HW_INTERRUPT (0x1<<27)
-#define AEU_INPUTS_ATTN_BITS_TCM_PARITY_ERROR (0x1<<26)
-#define AEU_INPUTS_ATTN_BITS_TIMERS_HW_INTERRUPT (0x1<<5)
-#define AEU_INPUTS_ATTN_BITS_TIMERS_PARITY_ERROR (0x1<<4)
-#define AEU_INPUTS_ATTN_BITS_TSDM_HW_INTERRUPT (0x1<<25)
-#define AEU_INPUTS_ATTN_BITS_TSDM_PARITY_ERROR (0x1<<24)
-#define AEU_INPUTS_ATTN_BITS_TSEMI_HW_INTERRUPT (0x1<<29)
-#define AEU_INPUTS_ATTN_BITS_TSEMI_PARITY_ERROR (0x1<<28)
-#define AEU_INPUTS_ATTN_BITS_UCM_HW_INTERRUPT (0x1<<23)
-#define AEU_INPUTS_ATTN_BITS_UCM_PARITY_ERROR (0x1<<22)
-#define AEU_INPUTS_ATTN_BITS_UPB_HW_INTERRUPT (0x1<<27)
-#define AEU_INPUTS_ATTN_BITS_UPB_PARITY_ERROR (0x1<<26)
-#define AEU_INPUTS_ATTN_BITS_USDM_HW_INTERRUPT (0x1<<21)
-#define AEU_INPUTS_ATTN_BITS_USDM_PARITY_ERROR (0x1<<20)
-#define AEU_INPUTS_ATTN_BITS_USEMI_HW_INTERRUPT (0x1<<25)
-#define AEU_INPUTS_ATTN_BITS_USEMI_PARITY_ERROR (0x1<<24)
-#define AEU_INPUTS_ATTN_BITS_VAUX_PCI_CORE_PARITY_ERROR (0x1<<16)
-#define AEU_INPUTS_ATTN_BITS_XCM_HW_INTERRUPT (0x1<<9)
-#define AEU_INPUTS_ATTN_BITS_XCM_PARITY_ERROR (0x1<<8)
-#define AEU_INPUTS_ATTN_BITS_XSDM_HW_INTERRUPT (0x1<<7)
-#define AEU_INPUTS_ATTN_BITS_XSDM_PARITY_ERROR (0x1<<6)
-#define AEU_INPUTS_ATTN_BITS_XSEMI_HW_INTERRUPT (0x1<<11)
-#define AEU_INPUTS_ATTN_BITS_XSEMI_PARITY_ERROR (0x1<<10)
+#define AEU_INPUTS_ATTN_BITS_ATC_HW_INTERRUPT BIT(4)
+#define AEU_INPUTS_ATTN_BITS_ATC_PARITY_ERROR BIT(5)
+#define AEU_INPUTS_ATTN_BITS_BRB_HW_INTERRUPT BIT(19)
+#define AEU_INPUTS_ATTN_BITS_BRB_PARITY_ERROR BIT(18)
+#define AEU_INPUTS_ATTN_BITS_CCM_HW_INTERRUPT BIT(31)
+#define AEU_INPUTS_ATTN_BITS_CCM_PARITY_ERROR BIT(30)
+#define AEU_INPUTS_ATTN_BITS_CDU_HW_INTERRUPT BIT(9)
+#define AEU_INPUTS_ATTN_BITS_CDU_PARITY_ERROR BIT(8)
+#define AEU_INPUTS_ATTN_BITS_CFC_HW_INTERRUPT BIT(7)
+#define AEU_INPUTS_ATTN_BITS_CFC_PARITY_ERROR BIT(6)
+#define AEU_INPUTS_ATTN_BITS_CSDM_HW_INTERRUPT BIT(29)
+#define AEU_INPUTS_ATTN_BITS_CSDM_PARITY_ERROR BIT(28)
+#define AEU_INPUTS_ATTN_BITS_CSEMI_HW_INTERRUPT BIT(1)
+#define AEU_INPUTS_ATTN_BITS_CSEMI_PARITY_ERROR BIT(0)
+#define AEU_INPUTS_ATTN_BITS_DEBUG_PARITY_ERROR BIT(18)
+#define AEU_INPUTS_ATTN_BITS_DMAE_HW_INTERRUPT BIT(11)
+#define AEU_INPUTS_ATTN_BITS_DMAE_PARITY_ERROR BIT(10)
+#define AEU_INPUTS_ATTN_BITS_DOORBELLQ_HW_INTERRUPT BIT(13)
+#define AEU_INPUTS_ATTN_BITS_DOORBELLQ_PARITY_ERROR BIT(12)
+#define AEU_INPUTS_ATTN_BITS_GPIO0_FUNCTION_0 BIT(2)
+#define AEU_INPUTS_ATTN_BITS_IGU_PARITY_ERROR BIT(12)
+#define AEU_INPUTS_ATTN_BITS_MCP_LATCHED_ROM_PARITY BIT(28)
+#define AEU_INPUTS_ATTN_BITS_MCP_LATCHED_SCPAD_PARITY BIT(31)
+#define AEU_INPUTS_ATTN_BITS_MCP_LATCHED_UMP_RX_PARITY BIT(29)
+#define AEU_INPUTS_ATTN_BITS_MCP_LATCHED_UMP_TX_PARITY BIT(30)
+#define AEU_INPUTS_ATTN_BITS_MISC_HW_INTERRUPT BIT(15)
+#define AEU_INPUTS_ATTN_BITS_MISC_PARITY_ERROR BIT(14)
+#define AEU_INPUTS_ATTN_BITS_NIG_PARITY_ERROR BIT(14)
+#define AEU_INPUTS_ATTN_BITS_PARSER_PARITY_ERROR BIT(20)
+#define AEU_INPUTS_ATTN_BITS_PBCLIENT_HW_INTERRUPT BIT(31)
+#define AEU_INPUTS_ATTN_BITS_PBCLIENT_PARITY_ERROR BIT(30)
+#define AEU_INPUTS_ATTN_BITS_PBF_PARITY_ERROR BIT(0)
+#define AEU_INPUTS_ATTN_BITS_PGLUE_HW_INTERRUPT BIT(2)
+#define AEU_INPUTS_ATTN_BITS_PGLUE_PARITY_ERROR BIT(3)
+#define AEU_INPUTS_ATTN_BITS_PXPPCICLOCKCLIENT_HW_INTERRUPT BIT(5)
+#define AEU_INPUTS_ATTN_BITS_PXPPCICLOCKCLIENT_PARITY_ERROR BIT(4)
+#define AEU_INPUTS_ATTN_BITS_PXP_HW_INTERRUPT BIT(3)
+#define AEU_INPUTS_ATTN_BITS_PXP_PARITY_ERROR BIT(2)
+#define AEU_INPUTS_ATTN_BITS_QM_HW_INTERRUPT BIT(3)
+#define AEU_INPUTS_ATTN_BITS_QM_PARITY_ERROR BIT(2)
+#define AEU_INPUTS_ATTN_BITS_SEARCHER_PARITY_ERROR BIT(22)
+#define AEU_INPUTS_ATTN_BITS_SPIO5 BIT(15)
+#define AEU_INPUTS_ATTN_BITS_TCM_HW_INTERRUPT BIT(27)
+#define AEU_INPUTS_ATTN_BITS_TCM_PARITY_ERROR BIT(26)
+#define AEU_INPUTS_ATTN_BITS_TIMERS_HW_INTERRUPT BIT(5)
+#define AEU_INPUTS_ATTN_BITS_TIMERS_PARITY_ERROR BIT(4)
+#define AEU_INPUTS_ATTN_BITS_TSDM_HW_INTERRUPT BIT(25)
+#define AEU_INPUTS_ATTN_BITS_TSDM_PARITY_ERROR BIT(24)
+#define AEU_INPUTS_ATTN_BITS_TSEMI_HW_INTERRUPT BIT(29)
+#define AEU_INPUTS_ATTN_BITS_TSEMI_PARITY_ERROR BIT(28)
+#define AEU_INPUTS_ATTN_BITS_UCM_HW_INTERRUPT BIT(23)
+#define AEU_INPUTS_ATTN_BITS_UCM_PARITY_ERROR BIT(22)
+#define AEU_INPUTS_ATTN_BITS_UPB_HW_INTERRUPT BIT(27)
+#define AEU_INPUTS_ATTN_BITS_UPB_PARITY_ERROR BIT(26)
+#define AEU_INPUTS_ATTN_BITS_USDM_HW_INTERRUPT BIT(21)
+#define AEU_INPUTS_ATTN_BITS_USDM_PARITY_ERROR BIT(20)
+#define AEU_INPUTS_ATTN_BITS_USEMI_HW_INTERRUPT BIT(25)
+#define AEU_INPUTS_ATTN_BITS_USEMI_PARITY_ERROR BIT(24)
+#define AEU_INPUTS_ATTN_BITS_VAUX_PCI_CORE_PARITY_ERROR BIT(16)
+#define AEU_INPUTS_ATTN_BITS_XCM_HW_INTERRUPT BIT(9)
+#define AEU_INPUTS_ATTN_BITS_XCM_PARITY_ERROR BIT(8)
+#define AEU_INPUTS_ATTN_BITS_XSDM_HW_INTERRUPT BIT(7)
+#define AEU_INPUTS_ATTN_BITS_XSDM_PARITY_ERROR BIT(6)
+#define AEU_INPUTS_ATTN_BITS_XSEMI_HW_INTERRUPT BIT(11)
+#define AEU_INPUTS_ATTN_BITS_XSEMI_PARITY_ERROR BIT(10)
#define AEU_INPUTS_ATTN_BITS_GPIO3_FUNCTION_0 (0x1<<5)
#define AEU_INPUTS_ATTN_BITS_GPIO3_FUNCTION_1 (0x1<<9)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
index ba3c159111d3..a8ec60a0d8a1 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -557,7 +557,7 @@ enum brcmf_sdio_frmtype {
BRCMF_SDIO_FT_SUB,
};
-#define SDIOD_DRVSTR_KEY(chip, pmu) (((chip) << 16) | (pmu))
+#define SDIOD_DRVSTR_KEY(chip, pmu) (((u32)(chip) << 16) | (pmu))
/* SDIO Pad drive strength to select value mappings */
struct sdiod_drive_str {
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x2/pci.c
b/drivers/net/wireless/mediatek/mt76/mt76x2/pci.c
index 8a22ee581674..ab59a1533c02 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x2/pci.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x2/pci.c
@@ -77,13 +77,13 @@ mt76x2e_probe(struct pci_dev *pdev, const struct
pci_device_id *id)
/* Fix up ASPM configuration */
/* RG_SSUSB_G1_CDR_BIR_LTR = 0x9 */
- mt76_rmw_field(dev, 0x15a10, 0x1f << 16, 0x9);
+ mt76_rmw_field(dev, 0x15a10, 0x1fu << 16, 0x9);
/* RG_SSUSB_G1_CDR_BIC_LTR = 0xf */
- mt76_rmw_field(dev, 0x15a0c, 0xf << 28, 0xf);
+ mt76_rmw_field(dev, 0x15a0c, 0xfu << 28, 0xf);
/* RG_SSUSB_CDR_BR_PE1D = 0x3 */
- mt76_rmw_field(dev, 0x15c58, 0x3 << 6, 0x3);
+ mt76_rmw_field(dev, 0x15c58, 0x3u << 6, 0x3);
mt76_pci_disable_aspm(pdev);
diff --git a/drivers/perf/fsl_imx8_ddr_perf.c b/drivers/perf/fsl_imx8_ddr_perf.c
index 94ebc1ecace7..7da764322c28 100644
--- a/drivers/perf/fsl_imx8_ddr_perf.c
+++ b/drivers/perf/fsl_imx8_ddr_perf.c
@@ -24,12 +24,12 @@
#define CNTL_OVER 0x1
#define CNTL_CLEAR 0x2
#define CNTL_EN 0x4
-#define CNTL_EN_MASK 0xFFFFFFFB
-#define CNTL_CLEAR_MASK 0xFFFFFFFD
-#define CNTL_OVER_MASK 0xFFFFFFFE
+#define CNTL_EN_MASK 0xFFFFFFFBu
+#define CNTL_CLEAR_MASK 0xFFFFFFFDu
+#define CNTL_OVER_MASK 0xFFFFFFFEu
#define CNTL_CSV_SHIFT 24
-#define CNTL_CSV_MASK (0xFF << CNTL_CSV_SHIFT)
+#define CNTL_CSV_MASK (0xFFu << CNTL_CSV_SHIFT)
#define EVENT_CYCLES_ID 0
#define EVENT_CYCLES_COUNTER 0
@@ -416,7 +416,7 @@ static void ddr_perf_counter_enable(struct ddr_pmu
*pmu, int config,
int counter, bool enable)
{
u8 reg = counter * 4 + COUNTER_CNTL;
- int val;
+ u32 val;
if (enable) {
/*
diff --git a/drivers/scsi/aacraid/aacraid.h b/drivers/scsi/aacraid/aacraid.h
index f849e7c9d428..9df966c6558a 100644
--- a/drivers/scsi/aacraid/aacraid.h
+++ b/drivers/scsi/aacraid/aacraid.h
@@ -116,12 +116,12 @@ enum {
#define get_target_number(x) (x%AAC_MAX_TARGETS)
/* Thor AIF events */
-#define SA_AIF_HOTPLUG (1<<1)
-#define SA_AIF_HARDWARE (1<<2)
-#define SA_AIF_PDEV_CHANGE (1<<4)
-#define SA_AIF_LDEV_CHANGE (1<<5)
-#define SA_AIF_BPSTAT_CHANGE (1<<30)
-#define SA_AIF_BPCFG_CHANGE (1<<31)
+#define SA_AIF_HOTPLUG BIT(1)
+#define SA_AIF_HARDWARE BIT(2)
+#define SA_AIF_PDEV_CHANGE BIT(4)
+#define SA_AIF_LDEV_CHANGE BIT(5)
+#define SA_AIF_BPSTAT_CHANGE BIT(30)
+#define SA_AIF_BPCFG_CHANGE BIT(31)
#define HBA_MAX_SG_EMBEDDED 28
#define HBA_MAX_SG_SEPARATE 90
diff --git a/drivers/scsi/ufs/ufshci.h b/drivers/scsi/ufs/ufshci.h
index a7ff0e5b5494..afb28efd77c2 100644
--- a/drivers/scsi/ufs/ufshci.h
+++ b/drivers/scsi/ufs/ufshci.h
@@ -240,8 +240,8 @@ enum {
#define UIC_ARG_MPHY_TX_GEN_SEL_INDEX(lane) (lane)
#define UIC_ARG_MPHY_RX_GEN_SEL_INDEX(lane) (PA_MAXDATALANES + (lane))
-#define UIC_ARG_MIB_SEL(attr, sel) ((((attr) & 0xFFFF) << 16) |\
- ((sel) & 0xFFFF))
+#define UIC_ARG_MIB_SEL(attr, sel) ((((attr) & 0xFFFFu) << 16) |\
+ ((sel) & 0xFFFFu))
#define UIC_ARG_MIB(attr) UIC_ARG_MIB_SEL(attr, 0)
#define UIC_ARG_ATTR_TYPE(t) (((t) & 0xFF) << 16)
#define UIC_GET_ATTR_ID(v) (((v) >> 16) & 0xFFFF)
diff --git a/fs/xfs/xfs_buf.h b/fs/xfs/xfs_buf.h
index edcb6254fa6a..762348973e8c 100644
--- a/fs/xfs/xfs_buf.h
+++ b/fs/xfs/xfs_buf.h
@@ -22,28 +22,28 @@ struct xfs_buf;
#define XFS_BUF_DADDR_NULL ((xfs_daddr_t) (-1LL))
-#define XBF_READ (1 << 0) /* buffer intended for reading from device */
-#define XBF_WRITE (1 << 1) /* buffer intended for writing to device */
-#define XBF_READ_AHEAD (1 << 2) /* asynchronous read-ahead */
-#define XBF_NO_IOACCT (1 << 3) /* bypass I/O accounting (non-LRU bufs) */
-#define XBF_ASYNC (1 << 4) /* initiator will not wait for completion */
-#define XBF_DONE (1 << 5) /* all pages in the buffer uptodate */
-#define XBF_STALE (1 << 6) /* buffer has been staled, do not find it */
-#define XBF_WRITE_FAIL (1 << 7) /* async writes have failed on this buffer */
+#define XBF_READ (1ul << 0) /* buffer intended for reading from device */
+#define XBF_WRITE (1ul << 1) /* buffer intended for writing to device */
+#define XBF_READ_AHEAD (1ul << 2) /* asynchronous read-ahead */
+#define XBF_NO_IOACCT (1ul << 3) /* bypass I/O accounting (non-LRU bufs) */
+#define XBF_ASYNC (1ul << 4) /* initiator will not wait for completion */
+#define XBF_DONE (1ul << 5) /* all pages in the buffer uptodate */
+#define XBF_STALE (1ul << 6) /* buffer has been staled, do not find it */
+#define XBF_WRITE_FAIL (1ul << 7) /* async writes have failed on this buffer */
/* buffer type flags for write callbacks */
-#define _XBF_INODES (1 << 16)/* inode buffer */
-#define _XBF_DQUOTS (1 << 17)/* dquot buffer */
-#define _XBF_LOGRECOVERY (1 << 18)/* log recovery buffer */
+#define _XBF_INODES (1ul << 16)/* inode buffer */
+#define _XBF_DQUOTS (1ul << 17)/* dquot buffer */
+#define _XBF_LOGRECOVERY (1ul << 18)/* log recovery buffer */
/* flags used only internally */
-#define _XBF_PAGES (1 << 20)/* backed by refcounted pages */
-#define _XBF_KMEM (1 << 21)/* backed by heap memory */
-#define _XBF_DELWRI_Q (1 << 22)/* buffer on a delwri queue */
+#define _XBF_PAGES (1ul << 20)/* backed by refcounted pages */
+#define _XBF_KMEM (1ul << 21)/* backed by heap memory */
+#define _XBF_DELWRI_Q (1ul << 22)/* buffer on a delwri queue */
/* flags used only as arguments to access routines */
-#define XBF_TRYLOCK (1 << 30)/* lock requested, but do not wait */
-#define XBF_UNMAPPED (1 << 31)/* do not map the buffer */
+#define XBF_TRYLOCK (1ul << 30)/* lock requested, but do not wait */
+#define XBF_UNMAPPED (1ul << 31)/* do not map the buffer */
typedef unsigned int xfs_buf_flags_t;
diff --git a/include/linux/mlx5/port.h b/include/linux/mlx5/port.h
index 28a928b0684b..f175d5bb601e 100644
--- a/include/linux/mlx5/port.h
+++ b/include/linux/mlx5/port.h
@@ -141,7 +141,7 @@ enum mlx5_ptys_width {
MLX5_PTYS_WIDTH_12X = 1 << 4,
};
-#define MLX5E_PROT_MASK(link_mode) (1 << link_mode)
+#define MLX5E_PROT_MASK(link_mode) BIT(link_mode)
#define MLX5_GET_ETH_PROTO(reg, out, ext, field) \
(ext ? MLX5_GET(reg, out, ext_##field) : \
MLX5_GET(reg, out, field))
diff --git a/include/linux/usb/pd_bdo.h b/include/linux/usb/pd_bdo.h
index 033fe3e17141..f0ad5ce8c8a0 100644
--- a/include/linux/usb/pd_bdo.h
+++ b/include/linux/usb/pd_bdo.h
@@ -7,16 +7,16 @@
#define __LINUX_USB_PD_BDO_H
/* BDO : BIST Data Object */
-#define BDO_MODE_RECV (0 << 28)
-#define BDO_MODE_TRANSMIT (1 << 28)
-#define BDO_MODE_COUNTERS (2 << 28)
-#define BDO_MODE_CARRIER0 (3 << 28)
-#define BDO_MODE_CARRIER1 (4 << 28)
-#define BDO_MODE_CARRIER2 (5 << 28)
-#define BDO_MODE_CARRIER3 (6 << 28)
-#define BDO_MODE_EYE (7 << 28)
-#define BDO_MODE_TESTDATA (8 << 28)
+#define BDO_MODE_RECV (0u << 28)
+#define BDO_MODE_TRANSMIT (1u << 28)
+#define BDO_MODE_COUNTERS (2u << 28)
+#define BDO_MODE_CARRIER0 (3u << 28)
+#define BDO_MODE_CARRIER1 (4u << 28)
+#define BDO_MODE_CARRIER2 (5u << 28)
+#define BDO_MODE_CARRIER3 (6u << 28)
+#define BDO_MODE_EYE (7u << 28)
+#define BDO_MODE_TESTDATA (8u << 28)
-#define BDO_MODE_MASK(mode) ((mode) & 0xf0000000)
+#define BDO_MODE_MASK(mode) ((mode) & 0xf0000000u)
#endif
diff --git a/sound/usb/usbaudio.h b/sound/usb/usbaudio.h
index 167834133b9b..b8359a0aa008 100644
--- a/sound/usb/usbaudio.h
+++ b/sound/usb/usbaudio.h
@@ -8,7 +8,7 @@
*/
/* handling of USB vendor/product ID pairs as 32-bit numbers */
-#define USB_ID(vendor, product) (((vendor) << 16) | (product))
+#define USB_ID(vendor, product) (((unsigned int)(vendor) << 16) | (product))
#define USB_ID_VENDOR(id) ((id) >> 16)
#define USB_ID_PRODUCT(id) ((u16)(id))
^ permalink raw reply related [flat|nested] 36+ messages in thread
* Re: Linux 5.18-rc1
2022-04-04 4:23 ` Guenter Roeck
2022-04-04 7:30 ` Ron Economos
@ 2022-04-04 15:32 ` Linus Torvalds
2022-04-04 16:21 ` Greg Kroah-Hartman
2022-04-04 16:45 ` Guenter Roeck
1 sibling, 2 replies; 36+ messages in thread
From: Linus Torvalds @ 2022-04-04 15:32 UTC (permalink / raw)
To: Guenter Roeck
Cc: Larry Finger, Oded Gabbay, Jiri Slaby, Linux Kernel Mailing List,
Greg Kroah-Hartman
On Sun, Apr 3, 2022 at 9:23 PM Guenter Roeck <linux@roeck-us.net> wrote:
>
> Oops. Sorry, I thought it was big endian. No idea why. I'll update
> subject and description and resend.
I see your updated patch, but for some reason 'b4' is unhappy about it, with
$ b4 am 20220404134338.3276991-1-linux@roeck-us.net
causing
✗ [PATCH v3] staging: r8188eu: Fix PPPoE tag insertion on little
endian systems
---
✗ BADSIG: DKIM/roeck-us.net
your DKIM looks fine on the messages I see, but now that I look at it
on the mailing list, I notice that your DKIM really is very wrong, and
has a lot of headers that a DKIM signature should *not* have.
Your DKIM signature includes header names that are very much for list
management, so by definition DKIM will fail for any email you send
through a mailing list. Headers like
"Resent-From:Resent-Sender:Resent-To:Resent-Cc
:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe" etc.
The DKIM setup should protect the meaningful headers that matter to
the sender, not things that the mail system will validly add when it
passes through.
So the DKIM header list should be things like
":To:From:Cc:Message-Id:Date:Subject:"
Not things like "Sender" or mailing list things.
Anyway, I was going to just commit it directly, but with the DKIM
verification failing, I was a bit less eager to. And then I noticed
that you used "be16_to_cpu()" - which is technically correct - which
doesn't match the other code in that file.
That driver uses the traditional "htons()" to convert to network byte
order. And yes, our naming with "be16_to_cpu()" etc is much more
legible and does do the reverse, but it looks very odd to mix the two
naming conventions. Either use one or the other, but not a mix.
Linus
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Linux 5.18-rc1
2022-04-04 15:32 ` Linus Torvalds
@ 2022-04-04 16:21 ` Greg Kroah-Hartman
2022-04-04 16:45 ` Guenter Roeck
1 sibling, 0 replies; 36+ messages in thread
From: Greg Kroah-Hartman @ 2022-04-04 16:21 UTC (permalink / raw)
To: Linus Torvalds
Cc: Guenter Roeck, Larry Finger, Oded Gabbay, Jiri Slaby,
Linux Kernel Mailing List
On Mon, Apr 04, 2022 at 08:32:16AM -0700, Linus Torvalds wrote:
> On Sun, Apr 3, 2022 at 9:23 PM Guenter Roeck <linux@roeck-us.net> wrote:
> >
> > Oops. Sorry, I thought it was big endian. No idea why. I'll update
> > subject and description and resend.
>
> I see your updated patch, but for some reason 'b4' is unhappy about it, with
>
> $ b4 am 20220404134338.3276991-1-linux@roeck-us.net
>
> causing
>
> ✗ [PATCH v3] staging: r8188eu: Fix PPPoE tag insertion on little
> endian systems
> ---
> ✗ BADSIG: DKIM/roeck-us.net
>
> your DKIM looks fine on the messages I see, but now that I look at it
> on the mailing list, I notice that your DKIM really is very wrong, and
> has a lot of headers that a DKIM signature should *not* have.
>
> Your DKIM signature includes header names that are very much for list
> management, so by definition DKIM will fail for any email you send
> through a mailing list. Headers like
> "Resent-From:Resent-Sender:Resent-To:Resent-Cc
> :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe" etc.
>
> The DKIM setup should protect the meaningful headers that matter to
> the sender, not things that the mail system will validly add when it
> passes through.
>
> So the DKIM header list should be things like
> ":To:From:Cc:Message-Id:Date:Subject:"
>
> Not things like "Sender" or mailing list things.
>
> Anyway, I was going to just commit it directly, but with the DKIM
> verification failing, I was a bit less eager to. And then I noticed
> that you used "be16_to_cpu()" - which is technically correct - which
> doesn't match the other code in that file.
I've taken this in my tree now and will get it to you for -rc2 if you
don't want to take it. And yes, I see the dkim issue as well, I haven't
started complaining about to people yet as lots of people have problem
email setups. Should we start pushing back?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Linux 5.18-rc1
2022-04-04 15:32 ` Linus Torvalds
2022-04-04 16:21 ` Greg Kroah-Hartman
@ 2022-04-04 16:45 ` Guenter Roeck
2022-04-04 17:09 ` Linus Torvalds
2022-04-05 21:14 ` Konstantin Ryabitsev
1 sibling, 2 replies; 36+ messages in thread
From: Guenter Roeck @ 2022-04-04 16:45 UTC (permalink / raw)
To: Linus Torvalds
Cc: Larry Finger, Oded Gabbay, Jiri Slaby, Linux Kernel Mailing List,
Greg Kroah-Hartman
On 4/4/22 08:32, Linus Torvalds wrote:
> On Sun, Apr 3, 2022 at 9:23 PM Guenter Roeck <linux@roeck-us.net> wrote:
>>
>> Oops. Sorry, I thought it was big endian. No idea why. I'll update
>> subject and description and resend.
>
> I see your updated patch, but for some reason 'b4' is unhappy about it, with
>
> $ b4 am 20220404134338.3276991-1-linux@roeck-us.net
>
> causing
>
> ✗ [PATCH v3] staging: r8188eu: Fix PPPoE tag insertion on little
> endian systems
> ---
> ✗ BADSIG: DKIM/roeck-us.net
>
> your DKIM looks fine on the messages I see, but now that I look at it
> on the mailing list, I notice that your DKIM really is very wrong, and
> has a lot of headers that a DKIM signature should *not* have.
>
> Your DKIM signature includes header names that are very much for list
> management, so by definition DKIM will fail for any email you send
> through a mailing list. Headers like
> "Resent-From:Resent-Sender:Resent-To:Resent-Cc
> :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe" etc.
>
> The DKIM setup should protect the meaningful headers that matter to
> the sender, not things that the mail system will validly add when it
> passes through.
>
> So the DKIM header list should be things like
> ":To:From:Cc:Message-Id:Date:Subject:"
>
> Not things like "Sender" or mailing list things.
I tried to tell my provider, but to no avail. Until now I used gmail,
but gmail will disable that ability by end of this month, leaving me
in the dark. Lose-lose situation for me. Right now I don't have a
useful alternative that doesn't require me to change my e-mail
address completely (or setting up my own e-mail server which
is a pita).
>
> Anyway, I was going to just commit it directly, but with the DKIM
> verification failing, I was a bit less eager to. And then I noticed
> that you used "be16_to_cpu()" - which is technically correct - which
> doesn't match the other code in that file.
>
Another lose-lose situation. Larry tells me I should use
be16_to_cpu(), you tell me I should not.
Either case, https://lore.kernel.org/r/YkPK/QmLAp3BkygY@sckzor-linux.localdomain
is a more complete solution, so you might want to pick that one.
Thanks,
Guenter
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Linux 5.18-rc1
2022-04-04 16:45 ` Guenter Roeck
@ 2022-04-04 17:09 ` Linus Torvalds
2022-04-05 21:14 ` Konstantin Ryabitsev
1 sibling, 0 replies; 36+ messages in thread
From: Linus Torvalds @ 2022-04-04 17:09 UTC (permalink / raw)
To: Guenter Roeck
Cc: Larry Finger, Oded Gabbay, Jiri Slaby, Linux Kernel Mailing List,
Greg Kroah-Hartman
On Mon, Apr 4, 2022 at 9:45 AM Guenter Roeck <linux@roeck-us.net> wrote:
>
> I tried to tell my provider, but to no avail.
Sad. Email providers that are clueless about email? Incompetent.
Linus
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Build regressions/improvements in v5.18-rc1
2022-04-04 8:16 ` Geert Uytterhoeven
@ 2022-04-04 18:39 ` Kalle Valo
-1 siblings, 0 replies; 36+ messages in thread
From: Kalle Valo @ 2022-04-04 18:39 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linux-wireless, alsa-devel, linux-usb, linux-scsi, linux-parisc,
Dennis Dalessandro, linux-rdma, netdev, Mike Marciniszyn,
linux-um, linux-kernel, dri-devel, linux-xfs, linux-m68k,
linux-serial, sparclinux, linux-s390, linux-media
Geert Uytterhoeven <geert@linux-m68k.org> writes:
>> /kisskb/src/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c:
>> error: case label does not reduce to an integer constant: => 3798:2,
>> 3809:2
>
> arm64-gcc5.4/arm64-allmodconfig
> powerpc-gcc5/powerpc-allmodconfig
> powerpc-gcc5/ppc64_book3e_allmodconfig
After v5.17 there were two commits to brcmfmac/sdio.c:
$ git log --oneline v5.17.. drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
ed26edf7bfd9 brcmfmac: Add BCM43454/6 support
6d766d8cb505 brcmfmac: pcie: Declare missing firmware files in pcie.c
I can't see how either of them could cause this warning. Could something
else cause this or am I missing something?
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Build regressions/improvements in v5.18-rc1
@ 2022-04-04 18:39 ` Kalle Valo
0 siblings, 0 replies; 36+ messages in thread
From: Kalle Valo @ 2022-04-04 18:39 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linux-kernel, linux-m68k, linux-parisc, sparclinux, dri-devel,
Dennis Dalessandro, Mike Marciniszyn, linux-rdma, linux-um,
linux-media, netdev, linux-wireless, linux-scsi, linux-serial,
linux-usb, linux-xfs, alsa-devel, linux-s390
Geert Uytterhoeven <geert@linux-m68k.org> writes:
>> /kisskb/src/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c:
>> error: case label does not reduce to an integer constant: => 3798:2,
>> 3809:2
>
> arm64-gcc5.4/arm64-allmodconfig
> powerpc-gcc5/powerpc-allmodconfig
> powerpc-gcc5/ppc64_book3e_allmodconfig
After v5.17 there were two commits to brcmfmac/sdio.c:
$ git log --oneline v5.17.. drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
ed26edf7bfd9 brcmfmac: Add BCM43454/6 support
6d766d8cb505 brcmfmac: pcie: Declare missing firmware files in pcie.c
I can't see how either of them could cause this warning. Could something
else cause this or am I missing something?
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Build regressions/improvements in v5.18-rc1
2022-04-04 11:45 ` Arnd Bergmann
2022-04-04 12:31 ` Arnd Bergmann
@ 2022-04-04 22:16 ` Dave Chinner
2022-04-05 6:47 ` Geert Uytterhoeven
1 sibling, 1 reply; 36+ messages in thread
From: Dave Chinner @ 2022-04-04 22:16 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Geert Uytterhoeven, Linux Kernel Mailing List, linux-xfs
On Mon, Apr 04, 2022 at 01:45:05PM +0200, Arnd Bergmann wrote:
> On Mon, Apr 4, 2022 at 12:19 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> > >
> > > /kisskb/src/fs/xfs/./xfs_trace.h:432:2: note: in expansion of macro 'TP_printk'
> > > TP_printk("dev %d:%d daddr 0x%llx bbcount 0x%x hold %d pincount %d "
> > > ^
> > > /kisskb/src/fs/xfs/./xfs_trace.h:440:5: note: in expansion of macro '__print_flags'
> > > __print_flags(__entry->flags, "|", XFS_BUF_FLAGS),
> > > ^
> > > /kisskb/src/fs/xfs/xfs_buf.h:67:4: note: in expansion of macro 'XBF_UNMAPPED'
> > > { XBF_UNMAPPED, "UNMAPPED" }
> > > ^
> > > /kisskb/src/fs/xfs/./xfs_trace.h:440:40: note: in expansion of macro 'XFS_BUF_FLAGS'
> > > __print_flags(__entry->flags, "|", XFS_BUF_FLAGS),
> > > ^
> > > /kisskb/src/fs/xfs/./xfs_trace.h: In function 'trace_raw_output_xfs_buf_flags_class':
> > > /kisskb/src/fs/xfs/xfs_buf.h:46:23: error: initializer element is not constant
> > > #define XBF_UNMAPPED (1 << 31)/* do not map the buffer */
> > >
> > > This doesn't make a whole lotta sense to me. It's blown up in a
> > > tracepoint macro in XFS that was not changed at all in 5.18-rc1, nor
> > > was any of the surrounding XFS code or contexts. Perhaps something
> > > outside XFS changed to cause this on these platforms?
> >
> > Upon closer look, all builds showing this issue are using gcc-5...
> >
> > > Can you bisect this, please?
> >
> > Fortunately I still have gcc-5 installed on an older machine,
> > and I could reproduce the issue on amd64 with
> > "make allmodconfig fs/xfs/xfs_trace.o".
> >
> > Bisection points to commit e8c07082a810fbb9 ("Kbuild: move to
> > -std=gnu11").
> >
> > [1] gcc version 5.5.0 20171010 (Ubuntu 5.5.0-12ubuntu1
>
> Thanks for the report. I've produced it and can see that the problem
> is assigning
> the value of "(1 << 31)" to an 'unsigned long' struct member. Since this is
> a signed integer overflow, the result is technically undefined behavior,
> which gcc-5 does not accept as an integer constant.
>
> The patch below fixes it for me, but I have not checked if there are any
> other instances. This could also be done using the 'BIT()' macro if the
> XFS maintainers prefer:
So XFS only uses these flags in unsigned int fields that are
typed via:
typedef unsigned int xfs_buf_flags_t;
So on the surface, declaring the flag values as ULONG and then writing
them into a UINT field is not a nice thing to be doing.
I really don't want to change the xfs_buf_flags_t type to an
unsigned long, because that changes the packing of the first
cacheline of the struct xfs_buf and the contents of that cacheline
are performance critical for the lookup fastpath....
Looking at __print_flags, the internal array type declaration is:
struct trace_print_flags {
unsigned long mask;
const char *name;
};
and that's the source of the problem. I notice __print_flags_u64()
exists, but __print_flags_u32() does not. Should it?
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Build regressions/improvements in v5.18-rc1
2022-04-04 8:16 ` Geert Uytterhoeven
` (3 preceding siblings ...)
(?)
@ 2022-04-05 6:45 ` Helge Deller
2022-04-05 6:49 ` Geert Uytterhoeven
-1 siblings, 1 reply; 36+ messages in thread
From: Helge Deller @ 2022-04-05 6:45 UTC (permalink / raw)
To: Geert Uytterhoeven, linux-kernel
Cc: linux-parisc, Dennis Dalessandro, Mike Marciniszyn
On 4/4/22 10:16, Geert Uytterhoeven wrote:
> On Mon, 4 Apr 2022, Geert Uytterhoeven wrote:
>> Below is the list of build error/warning regressions/improvements in
>> v5.18-rc1[1] compared to v5.17[2].
>>
>> [1] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/3123109284176b1532874591f7c81f3837bbdc17/ (all 96 configs)
>> [2] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/f443e374ae131c168a065ea1748feac6b2e76613/ (all 96 configs)
>>
>> *** ERRORS ***
> parisc64-gcc8/generic-64bit_defconfig
> parisc-gcc8/generic-32bit_defconfig
> parisc-gcc8/parisc-allmodconfig
> parisc-gcc8/parisc-allnoconfig
Someone needs to adjust how the parisc kernel is built on kisskb...
The parisc platform got vDSO support, so now the 32- and 64-bit
hppa compiler needs to be installed when building (for 64-bit).
In addition, it changed how to build a kernel:
make ARCH=parisc # to build a 32-bit kernel
or
make ARCH=parisc64 # to build a 64-bit kernel
(before ARCH=parisc was sufficient to build either for 32- or 64-bit).
And, in case "CROSS_COMPILE=" is given, you need to give "CROSS32_COMPILE=" as well.
It's preferred to leave out both CROSS[32]_COMPILE= parameters and let
the environment detect the compilers automatically. They just need to be in $PATH.
Who can change that on kisskb ?
Helge
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Build regressions/improvements in v5.18-rc1
2022-04-04 18:39 ` Kalle Valo
@ 2022-04-05 6:46 ` Geert Uytterhoeven
-1 siblings, 0 replies; 36+ messages in thread
From: Geert Uytterhoeven @ 2022-04-05 6:46 UTC (permalink / raw)
To: Kalle Valo
Cc: Linux Kernel Mailing List, linux-m68k, Parisc List, sparclinux,
DRI Development, Dennis Dalessandro, Mike Marciniszyn,
linux-rdma, linux-um, Linux Media Mailing List, netdev,
linux-wireless, scsi, open list:SERIAL DRIVERS, USB list,
linux-xfs, ALSA Development Mailing List, linux-s390
Hi Kalle,
On Mon, Apr 4, 2022 at 8:39 PM Kalle Valo <kvalo@kernel.org> wrote:
> Geert Uytterhoeven <geert@linux-m68k.org> writes:
> >> /kisskb/src/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c:
> >> error: case label does not reduce to an integer constant: => 3798:2,
> >> 3809:2
> >
> > arm64-gcc5.4/arm64-allmodconfig
> > powerpc-gcc5/powerpc-allmodconfig
> > powerpc-gcc5/ppc64_book3e_allmodconfig
>
> After v5.17 there were two commits to brcmfmac/sdio.c:
>
> $ git log --oneline v5.17.. drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> ed26edf7bfd9 brcmfmac: Add BCM43454/6 support
> 6d766d8cb505 brcmfmac: pcie: Declare missing firmware files in pcie.c
>
> I can't see how either of them could cause this warning. Could something
> else cause this or am I missing something?
Doh, I should not have reduced the CC list in the xfs subthread...
The builds above are all gcc-5 builds, so they are affected by the same
issue as XFS: unsigned constants that don't fit in int are lacking a
"U" suffix.
I assume Arnd's patch for
drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
fixes this?
https://lore.kernel.org/all/CAK8P3a0wRiS03imdXk2WbGONkSSczEGdE-ue5ubF6UyyDE9dQg@mail.gmail.com
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Build regressions/improvements in v5.18-rc1
@ 2022-04-05 6:46 ` Geert Uytterhoeven
0 siblings, 0 replies; 36+ messages in thread
From: Geert Uytterhoeven @ 2022-04-05 6:46 UTC (permalink / raw)
To: Kalle Valo
Cc: linux-wireless, ALSA Development Mailing List, USB list, scsi,
Parisc List, Dennis Dalessandro, linux-rdma, netdev,
Mike Marciniszyn, linux-um, Linux Kernel Mailing List,
DRI Development, linux-xfs, linux-m68k, open list:SERIAL DRIVERS,
sparclinux, linux-s390, Linux Media Mailing List
Hi Kalle,
On Mon, Apr 4, 2022 at 8:39 PM Kalle Valo <kvalo@kernel.org> wrote:
> Geert Uytterhoeven <geert@linux-m68k.org> writes:
> >> /kisskb/src/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c:
> >> error: case label does not reduce to an integer constant: => 3798:2,
> >> 3809:2
> >
> > arm64-gcc5.4/arm64-allmodconfig
> > powerpc-gcc5/powerpc-allmodconfig
> > powerpc-gcc5/ppc64_book3e_allmodconfig
>
> After v5.17 there were two commits to brcmfmac/sdio.c:
>
> $ git log --oneline v5.17.. drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> ed26edf7bfd9 brcmfmac: Add BCM43454/6 support
> 6d766d8cb505 brcmfmac: pcie: Declare missing firmware files in pcie.c
>
> I can't see how either of them could cause this warning. Could something
> else cause this or am I missing something?
Doh, I should not have reduced the CC list in the xfs subthread...
The builds above are all gcc-5 builds, so they are affected by the same
issue as XFS: unsigned constants that don't fit in int are lacking a
"U" suffix.
I assume Arnd's patch for
drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
fixes this?
https://lore.kernel.org/all/CAK8P3a0wRiS03imdXk2WbGONkSSczEGdE-ue5ubF6UyyDE9dQg@mail.gmail.com
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Build regressions/improvements in v5.18-rc1
2022-04-04 22:16 ` Dave Chinner
@ 2022-04-05 6:47 ` Geert Uytterhoeven
2022-04-05 7:08 ` Arnd Bergmann
0 siblings, 1 reply; 36+ messages in thread
From: Geert Uytterhoeven @ 2022-04-05 6:47 UTC (permalink / raw)
To: Dave Chinner; +Cc: Arnd Bergmann, Linux Kernel Mailing List, linux-xfs
Hi Dave,
On Tue, Apr 5, 2022 at 12:16 AM Dave Chinner <david@fromorbit.com> wrote:
> On Mon, Apr 04, 2022 at 01:45:05PM +0200, Arnd Bergmann wrote:
> > On Mon, Apr 4, 2022 at 12:19 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > > /kisskb/src/fs/xfs/./xfs_trace.h:432:2: note: in expansion of macro 'TP_printk'
> > > > TP_printk("dev %d:%d daddr 0x%llx bbcount 0x%x hold %d pincount %d "
> > > > ^
> > > > /kisskb/src/fs/xfs/./xfs_trace.h:440:5: note: in expansion of macro '__print_flags'
> > > > __print_flags(__entry->flags, "|", XFS_BUF_FLAGS),
> > > > ^
> > > > /kisskb/src/fs/xfs/xfs_buf.h:67:4: note: in expansion of macro 'XBF_UNMAPPED'
> > > > { XBF_UNMAPPED, "UNMAPPED" }
> > > > ^
> > > > /kisskb/src/fs/xfs/./xfs_trace.h:440:40: note: in expansion of macro 'XFS_BUF_FLAGS'
> > > > __print_flags(__entry->flags, "|", XFS_BUF_FLAGS),
> > > > ^
> > > > /kisskb/src/fs/xfs/./xfs_trace.h: In function 'trace_raw_output_xfs_buf_flags_class':
> > > > /kisskb/src/fs/xfs/xfs_buf.h:46:23: error: initializer element is not constant
> > > > #define XBF_UNMAPPED (1 << 31)/* do not map the buffer */
> > > >
> > > > This doesn't make a whole lotta sense to me. It's blown up in a
> > > > tracepoint macro in XFS that was not changed at all in 5.18-rc1, nor
> > > > was any of the surrounding XFS code or contexts. Perhaps something
> > > > outside XFS changed to cause this on these platforms?
> > >
> > > Upon closer look, all builds showing this issue are using gcc-5...
> > >
> > > > Can you bisect this, please?
> > >
> > > Fortunately I still have gcc-5 installed on an older machine,
> > > and I could reproduce the issue on amd64 with
> > > "make allmodconfig fs/xfs/xfs_trace.o".
> > >
> > > Bisection points to commit e8c07082a810fbb9 ("Kbuild: move to
> > > -std=gnu11").
> > >
> > > [1] gcc version 5.5.0 20171010 (Ubuntu 5.5.0-12ubuntu1
> >
> > Thanks for the report. I've produced it and can see that the problem
> > is assigning
> > the value of "(1 << 31)" to an 'unsigned long' struct member. Since this is
> > a signed integer overflow, the result is technically undefined behavior,
> > which gcc-5 does not accept as an integer constant.
> >
> > The patch below fixes it for me, but I have not checked if there are any
> > other instances. This could also be done using the 'BIT()' macro if the
> > XFS maintainers prefer:
>
> So XFS only uses these flags in unsigned int fields that are
> typed via:
>
> typedef unsigned int xfs_buf_flags_t;
>
> So on the surface, declaring the flag values as ULONG and then writing
> them into a UINT field is not a nice thing to be doing.
>
> I really don't want to change the xfs_buf_flags_t type to an
> unsigned long, because that changes the packing of the first
> cacheline of the struct xfs_buf and the contents of that cacheline
> are performance critical for the lookup fastpath....
Hence just use "1u << n" instead of "1ul << n"?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Build regressions/improvements in v5.18-rc1
2022-04-05 6:45 ` Helge Deller
@ 2022-04-05 6:49 ` Geert Uytterhoeven
2022-04-28 7:25 ` Michael Ellerman
0 siblings, 1 reply; 36+ messages in thread
From: Geert Uytterhoeven @ 2022-04-05 6:49 UTC (permalink / raw)
To: Helge Deller
Cc: Linux Kernel Mailing List, Parisc List, Dennis Dalessandro,
Mike Marciniszyn, Michael Ellerman
Hi Helge,
CC Michael
On Tue, Apr 5, 2022 at 8:45 AM Helge Deller <deller@gmx.de> wrote:
> On 4/4/22 10:16, Geert Uytterhoeven wrote:
> > On Mon, 4 Apr 2022, Geert Uytterhoeven wrote:
> >> Below is the list of build error/warning regressions/improvements in
> >> v5.18-rc1[1] compared to v5.17[2].
> >>
> >> [1] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/3123109284176b1532874591f7c81f3837bbdc17/ (all 96 configs)
> >> [2] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/f443e374ae131c168a065ea1748feac6b2e76613/ (all 96 configs)
> >>
> >> *** ERRORS ***
> > parisc64-gcc8/generic-64bit_defconfig
> > parisc-gcc8/generic-32bit_defconfig
> > parisc-gcc8/parisc-allmodconfig
> > parisc-gcc8/parisc-allnoconfig
>
> Someone needs to adjust how the parisc kernel is built on kisskb...
>
> The parisc platform got vDSO support, so now the 32- and 64-bit
> hppa compiler needs to be installed when building (for 64-bit).
>
> In addition, it changed how to build a kernel:
> make ARCH=parisc # to build a 32-bit kernel
> or
> make ARCH=parisc64 # to build a 64-bit kernel
> (before ARCH=parisc was sufficient to build either for 32- or 64-bit).
>
> And, in case "CROSS_COMPILE=" is given, you need to give "CROSS32_COMPILE=" as well.
> It's preferred to leave out both CROSS[32]_COMPILE= parameters and let
> the environment detect the compilers automatically. They just need to be in $PATH.
>
> Who can change that on kisskb ?
Michael (CCed).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Build regressions/improvements in v5.18-rc1
2022-04-05 6:46 ` Geert Uytterhoeven
(?)
@ 2022-04-05 6:52 ` Kalle Valo
-1 siblings, 0 replies; 36+ messages in thread
From: Kalle Valo @ 2022-04-05 6:52 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linux Kernel Mailing List, linux-m68k, Parisc List, sparclinux,
DRI Development, Dennis Dalessandro, Mike Marciniszyn,
linux-rdma, linux-um, Linux Media Mailing List, netdev,
linux-wireless, scsi, open list:SERIAL DRIVERS, USB list,
linux-xfs, ALSA Development Mailing List, linux-s390
Geert Uytterhoeven <geert@linux-m68k.org> writes:
> On Mon, Apr 4, 2022 at 8:39 PM Kalle Valo <kvalo@kernel.org> wrote:
>> Geert Uytterhoeven <geert@linux-m68k.org> writes:
>> >> /kisskb/src/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c:
>> >> error: case label does not reduce to an integer constant: => 3798:2,
>> >> 3809:2
>> >
>> > arm64-gcc5.4/arm64-allmodconfig
>> > powerpc-gcc5/powerpc-allmodconfig
>> > powerpc-gcc5/ppc64_book3e_allmodconfig
>>
>> After v5.17 there were two commits to brcmfmac/sdio.c:
>>
>> $ git log --oneline v5.17.. drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
>> ed26edf7bfd9 brcmfmac: Add BCM43454/6 support
>> 6d766d8cb505 brcmfmac: pcie: Declare missing firmware files in pcie.c
>>
>> I can't see how either of them could cause this warning. Could something
>> else cause this or am I missing something?
>
> Doh, I should not have reduced the CC list in the xfs subthread...
>
> The builds above are all gcc-5 builds, so they are affected by the same
> issue as XFS: unsigned constants that don't fit in int are lacking a
> "U" suffix.
>
> I assume Arnd's patch for
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> fixes this?
> https://lore.kernel.org/all/CAK8P3a0wRiS03imdXk2WbGONkSSczEGdE-ue5ubF6UyyDE9dQg@mail.gmail.com
Great, thanks. I assume Arnd will submit it officially at some point.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Build regressions/improvements in v5.18-rc1
@ 2022-04-05 6:52 ` Kalle Valo
0 siblings, 0 replies; 36+ messages in thread
From: Kalle Valo @ 2022-04-05 6:52 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linux-wireless, ALSA Development Mailing List, USB list, scsi,
Parisc List, Dennis Dalessandro, linux-rdma, netdev,
Mike Marciniszyn, linux-um, Linux Kernel Mailing List,
DRI Development, linux-xfs, linux-m68k, open list:SERIAL DRIVERS,
sparclinux, linux-s390, Linux Media Mailing List
Geert Uytterhoeven <geert@linux-m68k.org> writes:
> On Mon, Apr 4, 2022 at 8:39 PM Kalle Valo <kvalo@kernel.org> wrote:
>> Geert Uytterhoeven <geert@linux-m68k.org> writes:
>> >> /kisskb/src/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c:
>> >> error: case label does not reduce to an integer constant: => 3798:2,
>> >> 3809:2
>> >
>> > arm64-gcc5.4/arm64-allmodconfig
>> > powerpc-gcc5/powerpc-allmodconfig
>> > powerpc-gcc5/ppc64_book3e_allmodconfig
>>
>> After v5.17 there were two commits to brcmfmac/sdio.c:
>>
>> $ git log --oneline v5.17.. drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
>> ed26edf7bfd9 brcmfmac: Add BCM43454/6 support
>> 6d766d8cb505 brcmfmac: pcie: Declare missing firmware files in pcie.c
>>
>> I can't see how either of them could cause this warning. Could something
>> else cause this or am I missing something?
>
> Doh, I should not have reduced the CC list in the xfs subthread...
>
> The builds above are all gcc-5 builds, so they are affected by the same
> issue as XFS: unsigned constants that don't fit in int are lacking a
> "U" suffix.
>
> I assume Arnd's patch for
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> fixes this?
> https://lore.kernel.org/all/CAK8P3a0wRiS03imdXk2WbGONkSSczEGdE-ue5ubF6UyyDE9dQg@mail.gmail.com
Great, thanks. I assume Arnd will submit it officially at some point.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Build regressions/improvements in v5.18-rc1
@ 2022-04-05 6:52 ` Kalle Valo
0 siblings, 0 replies; 36+ messages in thread
From: Kalle Valo @ 2022-04-05 6:52 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linux Kernel Mailing List, linux-m68k, Parisc List, sparclinux,
DRI Development, Dennis Dalessandro, Mike Marciniszyn,
linux-rdma, linux-um, Linux Media Mailing List, netdev,
linux-wireless, scsi, open list:SERIAL DRIVERS, USB list,
linux-xfs, ALSA Development Mailing List, linux-s390
Geert Uytterhoeven <geert@linux-m68k.org> writes:
> On Mon, Apr 4, 2022 at 8:39 PM Kalle Valo <kvalo@kernel.org> wrote:
>> Geert Uytterhoeven <geert@linux-m68k.org> writes:
>> >> /kisskb/src/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c:
>> >> error: case label does not reduce to an integer constant: => 3798:2,
>> >> 3809:2
>> >
>> > arm64-gcc5.4/arm64-allmodconfig
>> > powerpc-gcc5/powerpc-allmodconfig
>> > powerpc-gcc5/ppc64_book3e_allmodconfig
>>
>> After v5.17 there were two commits to brcmfmac/sdio.c:
>>
>> $ git log --oneline v5.17.. drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
>> ed26edf7bfd9 brcmfmac: Add BCM43454/6 support
>> 6d766d8cb505 brcmfmac: pcie: Declare missing firmware files in pcie.c
>>
>> I can't see how either of them could cause this warning. Could something
>> else cause this or am I missing something?
>
> Doh, I should not have reduced the CC list in the xfs subthread...
>
> The builds above are all gcc-5 builds, so they are affected by the same
> issue as XFS: unsigned constants that don't fit in int are lacking a
> "U" suffix.
>
> I assume Arnd's patch for
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> fixes this?
> https://lore.kernel.org/all/CAK8P3a0wRiS03imdXk2WbGONkSSczEGdE-ue5ubF6UyyDE9dQg@mail.gmail.com
Great, thanks. I assume Arnd will submit it officially at some point.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Build regressions/improvements in v5.18-rc1
2022-04-05 6:47 ` Geert Uytterhoeven
@ 2022-04-05 7:08 ` Arnd Bergmann
2022-04-05 21:05 ` Dave Chinner
0 siblings, 1 reply; 36+ messages in thread
From: Arnd Bergmann @ 2022-04-05 7:08 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Dave Chinner, Arnd Bergmann, Linux Kernel Mailing List, linux-xfs
?On Tue, Apr 5, 2022 at 8:47 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Tue, Apr 5, 2022 at 12:16 AM Dave Chinner <david@fromorbit.com> wrote:
> > So XFS only uses these flags in unsigned int fields that are
> > typed via:
> >
> > typedef unsigned int xfs_buf_flags_t;
> >
> > So on the surface, declaring the flag values as ULONG and then writing
> > them into a UINT field is not a nice thing to be doing.
> >
> > I really don't want to change the xfs_buf_flags_t type to an
> > unsigned long, because that changes the packing of the first
> > cacheline of the struct xfs_buf and the contents of that cacheline
> > are performance critical for the lookup fastpath....
>
> Hence just use "1u << n" instead of "1ul << n"?
Right, that avoids the error as well. I picked '1ul' to match the type of
the variable it's assigned to, but as Dave said the intended type is
'u32', so '1u' is better here.
> > Looking at __print_flags, the internal array type declaration is:
> >
> > struct trace_print_flags {
> > unsigned long mask;
> > const char *name;
> > };
> >
> > and that's the source of the problem. I notice __print_flags_u64()
> > exists, but __print_flags_u32() does not. Should it?
It's not the source of the error, as there is no signed integer
overflow when assigning an unsigned int to an unsigned long.
It may be helpful to add a __print_flags_u32(), but it's unrelated
to the problem at hand.
Arnd
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Linux 5.18-rc1
2022-04-04 2:22 ` Guenter Roeck
2022-04-04 3:29 ` Linus Torvalds
@ 2022-04-05 12:19 ` Sudip Mukherjee
2022-04-05 13:18 ` Guenter Roeck
1 sibling, 1 reply; 36+ messages in thread
From: Sudip Mukherjee @ 2022-04-05 12:19 UTC (permalink / raw)
To: Linus Torvalds
Cc: Linus Torvalds, Linux Kernel Mailing List, Guenter Roeck,
Jonathan Cameron
On Sun, Apr 03, 2022 at 07:22:39PM -0700, Guenter Roeck wrote:
> On Sun, Apr 03, 2022 at 03:14:19PM -0700, Linus Torvalds wrote:
> > So here we are, two weeks later, and the merge window is closed.
> >
<snip>
> >
> > Go test, please,
>
> Build results:
> total: 151 pass: 142 fail: 9
> Failed builds:
> alpha:allmodconfig
> arm:allmodconfig
Apart from the ones Guenter reported, arm imote2_defconfig fails due to:
28f74201e37c ("ARM: pxa: remove Intel Imote2 and Stargate 2 boards")
--
Regards
Sudip
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Linux 5.18-rc1
2022-04-05 12:19 ` Sudip Mukherjee
@ 2022-04-05 13:18 ` Guenter Roeck
0 siblings, 0 replies; 36+ messages in thread
From: Guenter Roeck @ 2022-04-05 13:18 UTC (permalink / raw)
To: Sudip Mukherjee, Linus Torvalds
Cc: Linux Kernel Mailing List, Jonathan Cameron
On 4/5/22 05:19, Sudip Mukherjee wrote:
> On Sun, Apr 03, 2022 at 07:22:39PM -0700, Guenter Roeck wrote:
>> On Sun, Apr 03, 2022 at 03:14:19PM -0700, Linus Torvalds wrote:
>>> So here we are, two weeks later, and the merge window is closed.
>>>
>
> <snip>
>
>>>
>>> Go test, please,
>>
>> Build results:
>> total: 151 pass: 142 fail: 9
>> Failed builds:
>> alpha:allmodconfig
>> arm:allmodconfig
>
> Apart from the ones Guenter reported, arm imote2_defconfig fails due to:
> 28f74201e37c ("ARM: pxa: remove Intel Imote2 and Stargate 2 boards")
>
Not entirely surprising, since its support was removed with that patch.
The error is "arm-linux-gnueabi-ld: no machine record defined", which is
consistent with that removal. So the fix would be to remove that
configuration file.
Guenter
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Build regressions/improvements in v5.18-rc1
2022-04-05 7:08 ` Arnd Bergmann
@ 2022-04-05 21:05 ` Dave Chinner
0 siblings, 0 replies; 36+ messages in thread
From: Dave Chinner @ 2022-04-05 21:05 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Geert Uytterhoeven, Linux Kernel Mailing List, linux-xfs
On Tue, Apr 05, 2022 at 09:08:13AM +0200, Arnd Bergmann wrote:
> ?On Tue, Apr 5, 2022 at 8:47 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Tue, Apr 5, 2022 at 12:16 AM Dave Chinner <david@fromorbit.com> wrote:
> > > So XFS only uses these flags in unsigned int fields that are
> > > typed via:
> > >
> > > typedef unsigned int xfs_buf_flags_t;
> > >
> > > So on the surface, declaring the flag values as ULONG and then writing
> > > them into a UINT field is not a nice thing to be doing.
> > >
> > > I really don't want to change the xfs_buf_flags_t type to an
> > > unsigned long, because that changes the packing of the first
> > > cacheline of the struct xfs_buf and the contents of that cacheline
> > > are performance critical for the lookup fastpath....
> >
> > Hence just use "1u << n" instead of "1ul << n"?
>
> Right, that avoids the error as well. I picked '1ul' to match the type of
> the variable it's assigned to, but as Dave said the intended type is
> 'u32', so '1u' is better here.
Ok, I'll queue up a patch to make this modification. I'll also need
to check all the other trace flags fields we print as well, as they
likely have the same issue but there's no warnings from them because
they don't use the high bit in the 32 bit field yet...
> > > Looking at __print_flags, the internal array type declaration is:
> > >
> > > struct trace_print_flags {
> > > unsigned long mask;
> > > const char *name;
> > > };
> > >
> > > and that's the source of the problem. I notice __print_flags_u64()
> > > exists, but __print_flags_u32() does not. Should it?
>
> It's not the source of the error, as there is no signed integer
> overflow when assigning an unsigned int to an unsigned long.
Thanks for the clarification!
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Linux 5.18-rc1
2022-04-04 16:45 ` Guenter Roeck
2022-04-04 17:09 ` Linus Torvalds
@ 2022-04-05 21:14 ` Konstantin Ryabitsev
1 sibling, 0 replies; 36+ messages in thread
From: Konstantin Ryabitsev @ 2022-04-05 21:14 UTC (permalink / raw)
To: Guenter Roeck
Cc: Linus Torvalds, Larry Finger, Oded Gabbay, Jiri Slaby,
Linux Kernel Mailing List, Greg Kroah-Hartman
On Mon, Apr 04, 2022 at 09:45:46AM -0700, Guenter Roeck wrote:
> I tried to tell my provider, but to no avail. Until now I used gmail,
> but gmail will disable that ability by end of this month, leaving me
> in the dark. Lose-lose situation for me. Right now I don't have a
> useful alternative that doesn't require me to change my e-mail
> address completely (or setting up my own e-mail server which
> is a pita).
There are hosting providers that are known to work well. Many people happily
use fastmail (e.g. Greg KH), and it is known to do All The Right Things when
it comes to DKIM/DMARC.
-K
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Build regressions/improvements in v5.18-rc1
2022-04-05 6:49 ` Geert Uytterhoeven
@ 2022-04-28 7:25 ` Michael Ellerman
0 siblings, 0 replies; 36+ messages in thread
From: Michael Ellerman @ 2022-04-28 7:25 UTC (permalink / raw)
To: Geert Uytterhoeven, Helge Deller
Cc: Linux Kernel Mailing List, Parisc List, Dennis Dalessandro,
Mike Marciniszyn
Geert Uytterhoeven <geert@linux-m68k.org> writes:
> Hi Helge,
>
> CC Michael
>
> On Tue, Apr 5, 2022 at 8:45 AM Helge Deller <deller@gmx.de> wrote:
>> On 4/4/22 10:16, Geert Uytterhoeven wrote:
>> > On Mon, 4 Apr 2022, Geert Uytterhoeven wrote:
>> >> Below is the list of build error/warning regressions/improvements in
>> >> v5.18-rc1[1] compared to v5.17[2].
>> >>
>> >> [1] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/3123109284176b1532874591f7c81f3837bbdc17/ (all 96 configs)
>> >> [2] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/f443e374ae131c168a065ea1748feac6b2e76613/ (all 96 configs)
>> >>
>> >> *** ERRORS ***
>> > parisc64-gcc8/generic-64bit_defconfig
>> > parisc-gcc8/generic-32bit_defconfig
>> > parisc-gcc8/parisc-allmodconfig
>> > parisc-gcc8/parisc-allnoconfig
>>
>> Someone needs to adjust how the parisc kernel is built on kisskb...
>>
>> The parisc platform got vDSO support, so now the 32- and 64-bit
>> hppa compiler needs to be installed when building (for 64-bit).
>>
>> In addition, it changed how to build a kernel:
>> make ARCH=parisc # to build a 32-bit kernel
>> or
>> make ARCH=parisc64 # to build a 64-bit kernel
>> (before ARCH=parisc was sufficient to build either for 32- or 64-bit).
>>
>> And, in case "CROSS_COMPILE=" is given, you need to give "CROSS32_COMPILE=" as well.
>> It's preferred to leave out both CROSS[32]_COMPILE= parameters and let
>> the environment detect the compilers automatically. They just need to be in $PATH.
>>
>> Who can change that on kisskb ?
>
> Michael (CCed).
Hi all,
Sorry for the delay, I don't have much time to work on kisskb these days :}
I've updated things to work. It required a bit of fiddling because the
cross compilers I use from kernel.org don't have hppa and hppa64 in the
same prefix. But I just rsync'ed them into a shared directory and that
seems to be working.
The two parisc configs we have are here, everything recent is green:
http://kisskb.ellerman.id.au/kisskb/config/507/
http://kisskb.ellerman.id.au/kisskb/config/508/
I also added gcc11 for parisc.
cheers
^ permalink raw reply [flat|nested] 36+ messages in thread
end of thread, other threads:[~2022-04-28 7:25 UTC | newest]
Thread overview: 36+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-04-03 22:14 Linux 5.18-rc1 Linus Torvalds
2022-04-04 2:22 ` Guenter Roeck
2022-04-04 3:29 ` Linus Torvalds
2022-04-04 4:23 ` Guenter Roeck
2022-04-04 7:30 ` Ron Economos
2022-04-04 15:32 ` Linus Torvalds
2022-04-04 16:21 ` Greg Kroah-Hartman
2022-04-04 16:45 ` Guenter Roeck
2022-04-04 17:09 ` Linus Torvalds
2022-04-05 21:14 ` Konstantin Ryabitsev
2022-04-04 6:01 ` Jiri Slaby
2022-04-05 12:19 ` Sudip Mukherjee
2022-04-05 13:18 ` Guenter Roeck
2022-04-04 7:47 ` Build regressions/improvements in v5.18-rc1 Geert Uytterhoeven
2022-04-04 8:16 ` Geert Uytterhoeven
2022-04-04 8:16 ` Geert Uytterhoeven
2022-04-04 8:16 ` Geert Uytterhoeven
2022-04-04 9:26 ` Dave Chinner
2022-04-04 9:26 ` Dave Chinner
2022-04-04 10:19 ` Geert Uytterhoeven
2022-04-04 11:45 ` Arnd Bergmann
2022-04-04 12:31 ` Arnd Bergmann
2022-04-04 22:16 ` Dave Chinner
2022-04-05 6:47 ` Geert Uytterhoeven
2022-04-05 7:08 ` Arnd Bergmann
2022-04-05 21:05 ` Dave Chinner
2022-04-04 18:39 ` Kalle Valo
2022-04-04 18:39 ` Kalle Valo
2022-04-05 6:46 ` Geert Uytterhoeven
2022-04-05 6:46 ` Geert Uytterhoeven
2022-04-05 6:52 ` Kalle Valo
2022-04-05 6:52 ` Kalle Valo
2022-04-05 6:52 ` Kalle Valo
2022-04-05 6:45 ` Helge Deller
2022-04-05 6:49 ` Geert Uytterhoeven
2022-04-28 7:25 ` Michael Ellerman
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.