[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <12dfd74a-2c01-441d-9085-c1a0ec45f908@roeck-us.net>
Date: Mon, 9 Dec 2024 07:41:33 -0800
From: Guenter Roeck <linux@...ck-us.net>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: linux-kernel@...r.kernel.org, Masahiro Yamada <masahiroy@...nel.org>,
Fabio Estevam <festevam@...x.de>,
Linus Walleij <linus.walleij@...aro.org>,
Peter Zijlstra <peterz@...radead.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Arnd Bergmann <arnd@...db.de>,
Niklas Schnelle <schnelle@...ux.ibm.com>,
Dave Penkler <dpenkler@...il.com>,
Stafford Horne <shorne@...il.com>, Waiman Long <longman@...hat.com>
Subject: Re: Linux 6.13-rc2
On Sun, Dec 08, 2024 at 02:15:17PM -0800, Linus Torvalds wrote:
> The diffstat looks a bit unusual with 80%+ drivers, and a lot of it
> one-liners, but that's actually just because of a couple of automated
> scripts that got run after -rc1 for some cleanups. Nothing
> particularly interesting, but it makes for a lot of noise in the diff.
>
> That said, there are real fixes in there too, but nothing that looks
> hugely remarkable. The shortlog below gives a flavor of it all. That's
> m ostly drivers too, but there's networking and bpf and some arch
> updates too.
>
> Please do keep testing, and then we can all take it a bit easier over
> the holidays,
>
Build results:
total: 161 pass: 155 fail: 6
Failed builds:
csky:allmodconfig
i386:allyesconfig
i386:allmodconfig
openrisc:allmodconfig
s390:allmodconfig
xtensa:allmodconfig
Qemu test results:
total: 544 pass: 528 fail: 16
Failed tests:
arm:imx25-pdk:imx_v4_v5_defconfig:nonand:mem128:net=default:imx25-pdk:initrd
arm:imx25-pdk:imx_v4_v5_defconfig:nonand:sd:mem128:net=default:imx25-pdk:ext2
arm:imx25-pdk:imx_v4_v5_defconfig:nonand:usb0:mem128:net=default:imx25-pdk:ext2
arm:imx25-pdk:imx_v4_v5_defconfig:nonand:usb1:mem128:net=default:imx25-pdk:ext2
arm:mcimx6ul-evk:imx_v6_v7_defconfig:nodrm:mem256:net=nic:net=nic:imx6ul-14x14-evk:initrd
arm:mcimx6ul-evk:imx_v6_v7_defconfig:nodrm:sd:mem256:net=nic:net=nic:imx6ul-14x14-evk:ext2
arm:mcimx6ul-evk:imx_v6_v7_defconfig:nodrm:usb0:mem256:net=nic:net=nic:imx6ul-14x14-evk:ext2
arm:mcimx6ul-evk:imx_v6_v7_defconfig:nodrm:usb1:mem256:net=nic:net=nic:imx6ul-14x14-evk:ext2
arm:mcimx7d-sabre:imx_v6_v7_defconfig:nodrm:smp2:mem256:net=nic:imx7d-sdb:initrd
arm:mcimx7d-sabre:imx_v6_v7_defconfig:nodrm:smp2:usb1:mem256:net=nic:imx7d-sdb:ext2
arm:mcimx7d-sabre:imx_v6_v7_defconfig:nodrm:smp2:sd:mem256:net=nic:imx7d-sdb:ext2
arm:sabrelite:imx_v6_v7_defconfig:nodrm:mem256:net=default:imx6dl-sabrelite:initrd
arm:sabrelite:imx_v6_v7_defconfig:nodrm:mmc,b300:mem256:net=default:imx6dl-sabrelite:ext2
arm:sabrelite:imx_v6_v7_defconfig:nodrm:usb0:mem256:net=default:imx6dl-sabrelite:ext2
arm:sabrelite:imx_v6_v7_defconfig:nodrm:usb1:mem256:net=default:imx6dl-sabrelite:ext2
openrisc:or1200:or1ksim_defconfig
Unit test results:
pass: 464016 fail: 0
A couple of problems have been fixed since last week. Fixes for the
remaining issues seen in my tests have all been submitted. Most of those
patches are queued in linux-next. Here is a summary from my fixes branch
at git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git.
4ea915f32887 openrisc: place exception table at the head of vmlinux
5d481cfdbbca ARM: imx: Re-introduce the PINCTRL selection
62fb306f9082 locking/lockdep: Enforce PROVE_RAW_LOCK_NESTING only if ARCH_SUPPORTS_RT
e49fe26b045d tty: serial: Work around warning backtrace in serial8250_set_defaults
f11efcf05715 staging: gpib: Fix i386 build issue
1468f1923008 staging: gpib: Make GPIB_NI_PCI_ISA depend on HAS_IOPORT
All my build and boot tests pass with those patches applied.
I attached a long version of the commit log for reference and for details.
I added owners to Cc.
Guenter
---
commit 4ea915f3288756d829ba8abbd6cee10cf84a5a11
Author: Masahiro Yamada <masahiroy@...nel.org>
AuthorDate: Mon Dec 2 15:28:22 2024 +0900
Commit: Guenter Roeck <linux@...ck-us.net>
CommitDate: Sun Dec 8 15:41:42 2024 -0800
openrisc: place exception table at the head of vmlinux
Since commit 0043ecea2399 ("vmlinux.lds.h: Adjust symbol ordering in
text output section"), the exception table in arch/openrisc/kernel/head.S
is no longer positioned at the very beginning of the kernel image, which
causes a boot failure.
Currently, the exception table resides in the regular .text section.
Previously, it was placed at the head by relying on the linker receiving
arch/openrisc/kernel/head.o as the first object. However, this behavior
has changed because sections like .text.{asan,unknown,unlikely,hot} now
precede the regular .text section.
The .head.text section is intended for entry points requiring special
placement. However, in OpenRISC, this section has been misused: instead
of the entry points, it contains boot code meant to be discarded after
booting. This feature is typically handled by the .init.text section.
This commit addresses the issue by replacing the current __HEAD marker
with __INIT and re-annotating the entry points with __HEAD. Additionally,
it adds __REF to entry.S to suppress the following modpost warning:
WARNING: modpost: vmlinux: section mismatch in reference: _tng_kernel_start+0x70 (section: .text) -> _start (section: .init.text)
Fixes: 0043ecea2399 ("vmlinux.lds.h: Adjust symbol ordering in text output section")
Reported-by: Guenter Roeck <linux@...ck-us.net>
Closes: https://lore.kernel.org/all/5e032233-5b65-4ad5-ac50-d2eb6c00171c@roeck-us.net/#t
Signed-off-by: Masahiro Yamada <masahiroy@...nel.org>
Link: https://lore.kernel.org/r/20241202062909.2194341-1-masahiroy@kernel.org
Signed-off-by: Guenter Roeck <linux@...ck-us.net>
commit 5d481cfdbbca351f7fa347bd59f1471db7123305
Author: Fabio Estevam <festevam@...x.de>
AuthorDate: Wed Nov 27 16:06:05 2024 -0300
Commit: Guenter Roeck <linux@...ck-us.net>
CommitDate: Sun Dec 8 15:41:42 2024 -0800
ARM: imx: Re-introduce the PINCTRL selection
Since commit 17d210018914 ("ARM: imx: Allow user to disable pinctrl"),
the CONFIG_PINCTRL option is no longer implicitly selected, causing
several i.MX SoC pinctrl drivers no longer getting selected by default.
This causes boot regressions on the ARMv4, ARMv5, ARMv6 and ARMv7
i.MX SoCs.
Fix it by selecting CONFIG_PINCTRL as before.
This defeats the purpose of 7d210018914 ("ARM: imx: Allow user to disable
pinctrl"), but it is the less invasive fix for the boot regressions.
The attempt to build Layerscape without pinctrl can still be explored
later as suggested by Arnd:
"Overall, my best advice here is still to not change the way
i.MX pinctrl works at all, but just fix Layerscape to not depend
on i.MX. The reason for the 'select' here is clearly that the
i.MX machines would fail to boot without pinctrl, and changing
that because of Layerscape seems backwards."
Fixes: 17d210018914 ("ARM: imx: Allow user to disable pinctrl")
Reported-by: Guenter Roeck <linux@...ck-us.net>
Closes: https://lore.kernel.org/linux-arm-kernel/49ff070a-ce67-42d7-84ec-8b54fd7e9742@roeck-us.net/
Signed-off-by: Fabio Estevam <festevam@...x.de>
Acked-by: Arnd Bergmann <arnd@...db.de>
Reviewed-by: Linus Walleij <linus.walleij@...aro.org>
Tested-by: Guenter Roeck <linux@...ck-us.net>
Link: https://lore.kernel.org/20241127190605.1367157-1-festevam@gmail.com
Signed-off-by: Linus Walleij <linus.walleij@...aro.org>
Signed-off-by: Guenter Roeck <linux@...ck-us.net>
commit 62fb306f9082badff8e7ddc65140c156f380cb96
Author: Waiman Long <longman@...hat.com>
AuthorDate: Wed Nov 27 21:00:09 2024 -0500
Commit: Guenter Roeck <linux@...ck-us.net>
CommitDate: Sun Dec 8 15:41:42 2024 -0800
locking/lockdep: Enforce PROVE_RAW_LOCK_NESTING only if ARCH_SUPPORTS_RT
Relax the rule to set PROVE_RAW_LOCK_NESTING by default only for arches
that supports PREEMPT_RT. For arches that do not support PREEMPT_RT,
they will not be forced to address unimportant raw lock nesting issues
when they want to enable PROVE_LOCKING. They do have the option
to enable it to look for these raw locking nesting problems if they
choose to.
Suggested-by: Guenter Roeck <linux@...ck-us.net>
Signed-off-by: Waiman Long <longman@...hat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@...radead.org>
Tested-by: Guenter Roeck <linux@...ck-us.net>
Link: https://lore.kernel.org/r/20241128020009.83347-1-longman@redhat.com
Signed-off-by: Guenter Roeck <linux@...ck-us.net>
commit e49fe26b045d7819e45e0ed7156d9c546b0e5276
Author: Guenter Roeck <linux@...ck-us.net>
AuthorDate: Thu Dec 5 06:30:33 2024 -0800
Commit: Guenter Roeck <linux@...ck-us.net>
CommitDate: Sun Dec 8 15:41:42 2024 -0800
tty: serial: Work around warning backtrace in serial8250_set_defaults
Commit 7c7e6c8924e7 ("tty: serial: handle HAS_IOPORT dependencies")
triggers warning backtraces on a number of platforms which don't support
IO ports.
WARNING: CPU: 0 PID: 0 at drivers/tty/serial/8250/8250_port.c:470 serial8250_set_defaults+0x148/0x1d8
Unsupported UART type 0
The problem is seen because serial8250_set_defaults() is called for
all members of the serial8250_ports[] array even if that array is
not initialized.
Work around the problem by only displaying the warning if the port
type is not 0 (UPIO_PORT) or if iobase is set for the port.
Fixes: 7c7e6c8924e7 ("tty: serial: handle HAS_IOPORT dependencies")
Acked-by: Arnd Bergmann <arnd@...db.de>
Cc: Niklas Schnelle <schnelle@...ux.ibm.com>
Signed-off-by: Guenter Roeck <linux@...ck-us.net>
Tested-by: Stafford Horne <shorne@...il.com>
Link: https://lore.kernel.org/r/20241205143033.2695333-1-linux@roeck-us.net
Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Signed-off-by: Guenter Roeck <linux@...ck-us.net>
commit f11efcf05715a9f4df0411452cdebb832006798a
Author: Dave Penkler <dpenkler@...il.com>
AuthorDate: Wed Dec 4 17:21:28 2024 +0100
Commit: Guenter Roeck <linux@...ck-us.net>
CommitDate: Sun Dec 8 15:41:42 2024 -0800
staging: gpib: Fix i386 build issue
These drivers cast resource_type_t to void * causing the build to fail.
With CONFIG_X86_PAE enabled the resource_size_t type is a 64bit unsigned
int which cannot be cast to a 32 bit pointer.
Disable these drivers if X68_PAE is enabled
Reported-by: Guenter Roeck <linux@...ck-us.net>
Closes: https://lore.kernel.org/all/f10e976e-7a04-4454-b38d-39cd18f142da@roeck-us.net/
Fixes: e9dc69956d4d ("staging: gpib: Add Computer Boards GPIB driver")
Fixes: e1339245eba3 ("staging: gpib: Add Computer Equipment Corporation GPIB driver")
Fixes: bb1bd92fa0f2 ("staging: gpib: Add ines GPIB driver")
Fixes: 0cd5b05551e0 ("staging: gpib: Add TNT4882 chip based GPIB driver")
Signed-off-by: Dave Penkler <dpenkler@...il.com>
Link: https://lore.kernel.org/r/20241204162128.25617-1-dpenkler@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Signed-off-by: Guenter Roeck <linux@...ck-us.net>
commit 1468f19230080ec3c5b6f8565e679c6482d650fb
Author: Nathan Chancellor <nathan@...nel.org>
AuthorDate: Sat Nov 23 13:03:25 2024 -0700
Commit: Guenter Roeck <linux@...ck-us.net>
CommitDate: Sun Dec 8 15:41:42 2024 -0800
staging: gpib: Make GPIB_NI_PCI_ISA depend on HAS_IOPORT
After commit 78ecb0375685 ("staging: gpib: make port I/O code
conditional"), building tnt4882.ko on platforms without HAS_IOPORT (such
as hexagon and s390) fails with:
ERROR: modpost: "inb_wrapper" [drivers/staging/gpib/tnt4882/tnt4882.ko] undefined!
ERROR: modpost: "inw_wrapper" [drivers/staging/gpib/tnt4882/tnt4882.ko] undefined!
ERROR: modpost: "nec7210_locking_ioport_write_byte" [drivers/staging/gpib/tnt4882/tnt4882.ko] undefined!
ERROR: modpost: "nec7210_locking_ioport_read_byte" [drivers/staging/gpib/tnt4882/tnt4882.ko] undefined!
ERROR: modpost: "outb_wrapper" [drivers/staging/gpib/tnt4882/tnt4882.ko] undefined!
ERROR: modpost: "outw_wrapper" [drivers/staging/gpib/tnt4882/tnt4882.ko] undefined!
Only allow tnt4882.ko to be built when CONFIG_HAS_IOPORT is set to avoid
this build failure, as this driver unconditionally needs it.
Fixes: 78ecb0375685 ("staging: gpib: make port I/O code conditional")
Signed-off-by: Nathan Chancellor <nathan@...nel.org>
Tested-by: Geert Uytterhoeven <geert@...ux-m68k.org>
Link: https://lore.kernel.org/r/20241123-gpib-tnt4882-depends-on-has_ioport-v1-1-033c58b64751@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Signed-off-by: Guenter Roeck <linux@...ck-us.net>
Powered by blists - more mailing lists