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
On Sun, Apr 3, 2022 at 9:23 PM Guenter Roeck <[email protected]> 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 [email protected]
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
> On 4/3/22 20:29, Linus Torvalds wrote:
> > On Sun, Apr 3, 2022 at 7:22 PM Guenter Roeck <[email protected]> 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/[email protected]/
> >
> > 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
On Mon, Apr 04, 2022 at 08:32:16AM -0700, Linus Torvalds wrote:
> On Sun, Apr 3, 2022 at 9:23 PM Guenter Roeck <[email protected]> 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 [email protected]
>
> 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
On 4/3/22 20:29, Linus Torvalds wrote:
> On Sun, Apr 3, 2022 at 7:22 PM Guenter Roeck <[email protected]> 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/[email protected]/
>
> 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/[email protected]/
>
> 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
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/[email protected]/
--------------
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/[email protected]/
--------------
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/[email protected]/
On Sun, Apr 3, 2022 at 7:22 PM Guenter Roeck <[email protected]> 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/[email protected]/
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/[email protected]/
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/[email protected]/
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
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 -- [email protected]
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
Hi Helge,
CC Michael
On Tue, Apr 5, 2022 at 8:45 AM Helge Deller <[email protected]> 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 -- [email protected]
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
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
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
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
Geert Uytterhoeven <[email protected]> writes:
> Hi Helge,
>
> CC Michael
>
> On Tue, Apr 5, 2022 at 8:45 AM Helge Deller <[email protected]> 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