So two weeks are over, and the merge window is closed.
This was - as expected - a fairly big merge window, but things seem to
have proceeded fairly smoothly. Famous last words.
There's a lot in there, although the diffstat looks pretty skewed -
once again due to some amdgpu header files. Those things are huge, and
autogenerated from hardware descriptions, and the end result is that
they often end up overshadowing all the other changes if you only look
at the diffs. In fact, over a third of the diff for 5.13-rc1 is just
from those kinds of header files.
So ignore that part if you want to look at what changed. That will
still show driver changes at 60% of the diff, which is all normal.
It's all over the place, although gpu and networking stands out (yes,
the gpu updates are noticeable even when ignoring the amd header
files).
Outside of drivers, it's a bit of everything: arch updates (arm, x86
and powerpc dominate), documentation (devicetree bindings dominate -
I'm not sure it should count as documentation, but there's also a fair
amount of translation work), tooling, and obviously all the expected
core kernel stuff: filesystems, process handling, VM and core
networking.
The shortlog would be even bigger than usual, with 1800+ developers
and 14k+ non-merge commits (over 15k commits counting merges). So
appended is my usual rc1 "merge shortlog". And as always, this credits
the people I merge from - if you want to see details about authorship
and exact commits, you will need to go to the git tree itself.
The merge log is obviously woefully inadequate, with the diffstat
summary kind of showing why:
12015 files changed, 631309 insertions(+), 246239 deletions(-)
it really is a fair amount of stuff, all over the place.
Go test,
Linus
---
Al Viro (6):
vfs inode type handling updates
coredump updates
exryptfs updates
misc vfs updates
receive_fd update
another simple_recursive_removal() update
Alex Williamson (2):
VFIO updates
more VFIO updates
Alexandre Belloni (2):
RTC updates
i3cupdates
Andreas Gruenbacher (1):
gfs2 updates
Andrew Morton (3):
misc updates
more updates
yet more updates
Arnaldo Carvalho de Melo (1):
perf tool updates
Arnd Bergmann (6):
ARM SoC updates
ARM defconfig updates
ARM SoC driver updates
ARM devicetree updates
ARM Nuvoton WPCM450 platform support
ARM Apple M1 platform support
Bartosz Golaszewski (1):
gpio updates
Benson Leung (1):
chrome platform updates
Bjorn Andersson (3):
hwspinlock udpates
rpmsg updates
remoteproc updates
Bjorn Helgaas (1):
pci updates
Borislav Petkov (14):
x86 microcode update
x86 RAS update
x86 alternatives/paravirt updates
x86 tool update
x86 AMD secure virtualization (SEV-ES) updates
x86 vmware guest update
x86 SGX updates
x86 boot updates
misc x86 cleanups
x86 build updates
x86 platform updates
x86 updates
x86 fixes
x86 perf fix
Brian Cain (1):
Hexagon updates
Catalin Marinas (2):
arm64 updates
more arm64 updates
Christian Brauner (2):
fs helper kernel-doc updates
fs mapping helper updates
Christoph Hellwig (1):
dma-mapping updates
Chuck Lever (2):
nfsd updates
more nfsd updates
Corey Minyard (1):
IPMI updates
Daniel Lezcano (1):
thermal updates
Daniel Thompson (1):
kgdb updates
Darrick Wong (4):
iomap update
xfs updates
more xfs updates
more iomap updates
Dave Airlie (3):
drm updates
more drm updates
drm fixes
David Howells (3):
x509 dbx/mokx UEFI support
network filesystem helper library updates
AFS updates
David Sterba (1):
btrfs updates
David Teigland (1):
dlm updates
Dmitry Torokhov (1):
input updates
Dominik Brodowski (1):
pcmcia updates
Dominique Martinet (1):
9p updates
Gao Xiang (1):
erofs updates
Geert Uytterhoeven (1):
m68k updates
Greg KH (6):
char/misc driver updates
driver core updates
staging/IIO driver updates
tty and serial driver updates
USB and Thunderbolt updates
char/misc driver fixes
Greg Ungerer (1):
m68knommu updates
Guenter Roeck (1):
hwmon updates
Guo Ren (1):
arch/csky updates
Heiko Carstens (2):
s390 updates
more s390 updates
Helge Deller (1):
parisc architecture updates
Herbert Xu (1):
crypto updates
Ilya Dryomov (1):
ceph updates
Ingo Molnar (6):
RCU updates
locking updates
objtool updates
perf event updates
scheduler updates
x86 tlb updates
Jaegeuk Kim (1):
f2fs updates
Jakub Kicinski (2):
networking updates
networking fixes
James Bottomley (3):
tpm fixes
SCSI updates
more SCSI updates
James Morris (2):
security layer fixes
Landlock LSM
Jan Kara (2):
quota, ext2, reiserfs updates
fsnotify updates
Jarkko Sakkinen (1):
tpm updates
Jason Gunthorpe (1):
rdma updates
Jassi Brar (1):
mailbox updates
Jean Delvare (1):
dmi update
Jeff Layton (1):
file locking updates
Jens Axboe (7):
block updates
block driver updates
libata updates
io_uring updates
io_uring fixes
block fixes
block fix
Jessica Yu (1):
module updates
Jiri Kosina (1):
HID updates
Joerg Roedel (1):
iommu updates
Jonathan Corbet (2):
documentation updates
documentation fixes
Juergen Gross (1):
xen updates
Kees Cook (4):
seccomp updates
pstore update
overflow update
CFI on arm64 support
Konrad Rzeszutek Wilk (1):
swiotlb updates
Lee Jones (2):
MFD updates
backlight updates
Len Brown (1):
turbostat updates
Linus Walleij (1):
pin control updates
Mark Brown (3):
regmap updates
regulator updates
spi updates
Masahiro Yamada (3):
Kbuild updates
Kconfig updates
more Kbuild updates
Mauro Carvalho Chehab (1):
media updates
Max Filippov (1):
Xtensa updates
Micah Morton (1):
SafeSetID update
Michael Ellerman (2):
powerpc updates
powerpc updates and fixes
Michael Tsirkin (1):
virtio updates
Michal Simek (1):
Microblaze updates
Mike Marshall (1):
orangefs updates
Mike Snitzer (1):
device mapper updates
Miklos Szeredi (2):
overlayfs update
fuse updates
Miklos Szeredi via Al Viro (1):
fileattr conversion updates
Mimi Zohar (1):
IMA updates
Miquel Raynal (1):
mtd updates
Namjae Jeon (1):
exfat updates
Palmer Dabbelt (2):
RISC-V updates
RISC-V fixes
Paolo Bonzini (1):
kvm updates
Paul Moore (2):
selinux updates
audit updates
Pavel Machek (1):
LED updates
Petr Mladek (2):
printk updates
livepatching update
Rafael Wysocki (4):
ACPI updates
power management updates
device properties framework update
ACPI fixes
Richard Weinberger (2):
JFFS2, UBI and UBIFS updates
UML updates
Rob Herring (2):
devicetree updates
devicetree fixes
Russell King (1):
ARM updates
Sebastian Reichel (2):
HSI update
power supply and reset updates
Shuah Khan (2):
Kselftest updates
KUnit updates
Stephen Boyd (1):
clk updates
Steve French (3):
cifs updates
cifs updates
cifs fixes
Steven Rostedt (3):
tracing updates
ktest updates
tracing fix
Takashi Iwai (2):
sound updates
sound fixes
Ted Ts'o (1):
ext4 updates
Tejun Heo (1):
cgroup changes
Tetsuo Handa (1):
lockdep capacity limit updates
Thierry Reding (1):
pwm updates
Thomas Bogendoerfer (1):
MIPS updates
Thomas Gleixner (9):
core entry updates
irq updates
timer updates
x86 apic update
entry code update
x86 bus lock detection updates
x86 vdso update
locking fixes
scheduler fixes
Trond Myklebust (1):
NFS client updates
Tyler Hicks (1):
ecryptfs updates
Ulf Hansson (1):
MMC and MEMSTICK updates
Vinod Koul (1):
dmaengine updates
Wei Liu (1):
Hyper-V updates
Wolfram Sang (1):
i2c updates
On Sun, May 09, 2021 at 02:43:40PM -0700, Linus Torvalds wrote:
[ ... ]
>
> Go test,
Build results:
total: 151 pass: 151 fail: 0
Qemu test results:
total: 462 pass: 460 fail: 2
Failed tests:
arm:raspi2:multi_v7_defconfig:net,usb:bcm2836-rpi-2-b:initrd
arm:raspi2:multi_v7_defconfig:sd:net,usb:bcm2836-rpi-2-b:rootfs
The raspi2 problem (a crash in of_clk_add_hw_provider) is well known.
It was introduced with commit 6579c8d97ad7 ("clk: Mark fwnodes when
their clock provider is added"). Unfortunately it appears that there
is still no agreement on how to fix it.
There is also a repeated warning
WARNING: CPU: 0 PID: 1 at kernel/irq/irqdomain.c:550 irq_domain_associate+0x194/0x1f0
in some pxa boot tests. It looks like that problem has been fixed in -next.
Guenter
On Mon, 10 May 2021 at 03:14, Linus Torvalds
<[email protected]> wrote:
>
> So two weeks are over, and the merge window is closed.
< trim >
> The merge log is obviously woefully inadequate, with the diffstat
> summary kind of showing why:
>
> 12015 files changed, 631309 insertions(+), 246239 deletions(-)
>
> it really is a fair amount of stuff, all over the place.
>
> Go test,
Results from Linaro’s test farm.
Regressions detected.
Summary
------------------------------------------------------------------------
kernel: 5.13.0-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git branch: master
git commit: 6efb943b8616ec53a5e444193dccf1af9ad627b5
git describe: v5.13-rc1
Test details: https://qa-reports.linaro.org/lkft/linux-mainline-master/build/v5.13-rc1
Regressions (compared to build v5.12)
------------------------------------
Regression on TI BeagleBoard-X15 arm32 bit platform as the device was not able
to detect SATA drive.
Which is fixed by Tony Lindgren but this is yet to get into the mainline tree.
"
Naresh Kamboju <[email protected]> reported that Beaglebone-X15
does not detect sata drives any longer after dra7 was flipped to boot with
device tree data only. Turns out we are now missing the sata related quirk
flags in ti-sysc that we used to have earlier.
Fixes: 98feab31ac49 ("ARM: OMAP2+: Drop legacy platform data for dra7 sata")
Fixes: 21206c8f2cb5 ("ARM: OMAP2+: Drop legacy platform data for omap5 sata")
Link: https://lore.kernel.org/regressions/CA+G9fYtTN6ug3eBAW3wMcDeESUo+ebj7L5HBe5_fj4uqDExFQg@mail.gmail.com/
"
ref:
https://lore.kernel.org/linux-arm-kernel/[email protected]/
## Test result summary
total: 63780, pass: 53717, fail: 1047, skip: 8782, xfail: 234,
## Build Summary
* arc: 10 total, 10 passed, 0 failed
* arm: 194 total, 194 passed, 0 failed
* arm64: 28 total, 28 passed, 0 failed
* dragonboard-410c: 1 total, 1 passed, 0 failed
* hi6220-hikey: 1 total, 1 passed, 0 failed
* i386: 27 total, 27 passed, 0 failed
* juno-r2: 1 total, 1 passed, 0 failed
* mips: 45 total, 45 passed, 0 failed
* parisc: 9 total, 9 passed, 0 failed
* powerpc: 27 total, 27 passed, 0 failed
* riscv: 21 total, 21 passed, 0 failed
* s390: 18 total, 18 passed, 0 failed
* sh: 18 total, 18 passed, 0 failed
* sparc: 9 total, 9 passed, 0 failed
* x86_64: 28 total, 28 passed, 0 failed
## Test suites summary
* fwts
* install-android-platform-tools-r2600
* kselftest-android
* kselftest-bpf
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-drivers
* kselftest-efivarfs
* kselftest-filesystems
* kselftest-firmware
* kselftest-fpu
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kexec
* kselftest-kvm
* kselftest-lib
* kselftest-livepatch
* kselftest-lkdtm
* kselftest-membarrier
* kselftest-memfd
* kselftest-memory-hotplug
* kselftest-mincore
* kselftest-mount
* kselftest-mqueue
* kselftest-net
* kselftest-netfilter
* kselftest-nsfs
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* kselftest-tc-testing
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-vm
* kselftest-x86
* kselftest-zram
* kunit
* kvm-unit-tests
* libhugetlbfs
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-controllers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-open-posix-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-tracing-tests
* network-basic-tests
* packetdrill
* perf
* rcutorture
* ssuite
* v4l2-compliance
--
Linaro LKFT
https://lkft.linaro.org
On Mon, May 10, 2021 at 10:54 AM Naresh Kamboju
<[email protected]> wrote:
>
> Regressions (compared to build v5.12)
> ------------------------------------
>
> Regression on TI BeagleBoard-X15 arm32 bit platform as the device was not able
> to detect SATA drive.
>
> Which is fixed by Tony Lindgren but this is yet to get into the mainline tree.
>
> "
> Naresh Kamboju <[email protected]> reported that Beaglebone-X15
> does not detect sata drives any longer after dra7 was flipped to boot with
> device tree data only. Turns out we are now missing the sata related quirk
> flags in ti-sysc that we used to have earlier.
>
> Fixes: 98feab31ac49 ("ARM: OMAP2+: Drop legacy platform data for dra7 sata")
> Fixes: 21206c8f2cb5 ("ARM: OMAP2+: Drop legacy platform data for omap5 sata")
> Link: https://lore.kernel.org/regressions/CA+G9fYtTN6ug3eBAW3wMcDeESUo+ebj7L5HBe5_fj4uqDExFQg@mail.gmail.com/
> "
> ref:
> https://lore.kernel.org/linux-arm-kernel/[email protected]/
Ok, thanks, looks good.
I'm assuming I'll be getting that fix through the usual ARM SoC trees,
so it will hopefully be all good by rc2.
Thanks,
Linus
On Sun, May 9, 2021 at 7:54 PM Guenter Roeck <[email protected]> wrote:
>
> Qemu test results:
> total: 462 pass: 460 fail: 2
> Failed tests:
> arm:raspi2:multi_v7_defconfig:net,usb:bcm2836-rpi-2-b:initrd
> arm:raspi2:multi_v7_defconfig:sd:net,usb:bcm2836-rpi-2-b:rootfs
>
> The raspi2 problem (a crash in of_clk_add_hw_provider) is well known.
> It was introduced with commit 6579c8d97ad7 ("clk: Mark fwnodes when
> their clock provider is added"). Unfortunately it appears that there
> is still no agreement on how to fix it.
Hmm. I see
https://lore.kernel.org/linux-acpi/[email protected]/
and don't see any objections to that version.
Does that fix it for you too?
I'm assuming I'll get that through the usual channels.
> There is also a repeated warning
>
> WARNING: CPU: 0 PID: 1 at kernel/irq/irqdomain.c:550 irq_domain_associate+0x194/0x1f0
>
> in some pxa boot tests. It looks like that problem has been fixed in -next.
Ok, I won't worry about it then.
Thanks,
Linus
On Mon, May 10, 2021 at 12:01:00PM -0700, Linus Torvalds wrote:
> On Sun, May 9, 2021 at 7:54 PM Guenter Roeck <[email protected]> wrote:
> >
> > Qemu test results:
> > total: 462 pass: 460 fail: 2
> > Failed tests:
> > arm:raspi2:multi_v7_defconfig:net,usb:bcm2836-rpi-2-b:initrd
> > arm:raspi2:multi_v7_defconfig:sd:net,usb:bcm2836-rpi-2-b:rootfs
> >
> > The raspi2 problem (a crash in of_clk_add_hw_provider) is well known.
> > It was introduced with commit 6579c8d97ad7 ("clk: Mark fwnodes when
> > their clock provider is added"). Unfortunately it appears that there
> > is still no agreement on how to fix it.
>
> Hmm. I see
>
> https://lore.kernel.org/linux-acpi/[email protected]/
>
> and don't see any objections to that version.
>
> Does that fix it for you too?
>
Yes, it does. It was submitted ~2 weeks ago, so I have no idea what its
status might be (it is not in the most recent -next). I just sent a
Tested-by:, figuring that it can't hurt.
Guenter
Just adding Greg & co explicitly to the participants to make sure
they're aware of this..
Greg? This came through your driver core tree.
Linus
On Mon, May 10, 2021 at 12:39 PM Guenter Roeck <[email protected]> wrote:
>
> On Mon, May 10, 2021 at 12:01:00PM -0700, Linus Torvalds wrote:
> > On Sun, May 9, 2021 at 7:54 PM Guenter Roeck <[email protected]> wrote:
> > >
> > > Qemu test results:
> > > total: 462 pass: 460 fail: 2
> > > Failed tests:
> > > arm:raspi2:multi_v7_defconfig:net,usb:bcm2836-rpi-2-b:initrd
> > > arm:raspi2:multi_v7_defconfig:sd:net,usb:bcm2836-rpi-2-b:rootfs
> > >
> > > The raspi2 problem (a crash in of_clk_add_hw_provider) is well known.
> > > It was introduced with commit 6579c8d97ad7 ("clk: Mark fwnodes when
> > > their clock provider is added"). Unfortunately it appears that there
> > > is still no agreement on how to fix it.
> >
> > Hmm. I see
> >
> > https://lore.kernel.org/linux-acpi/[email protected]/
> >
> > and don't see any objections to that version.
> >
> > Does that fix it for you too?
> >
>
> Yes, it does. It was submitted ~2 weeks ago, so I have no idea what its
> status might be (it is not in the most recent -next). I just sent a
> Tested-by:, figuring that it can't hurt.
>
> Guenter
On Mon, May 10, 2021 at 03:20:41PM -0700, Linus Torvalds wrote:
> Just adding Greg & co explicitly to the participants to make sure
> they're aware of this..
>
> Greg? This came through your driver core tree.
I thought Stephen had taken that commit by now, sorry about that. I've
grabbed it for my tree and will let it run in linux-next for a day or so
before sending it to you.
thanks,
greg k-h