Hi Linus, It took a while for some patches to make it into mainline through maintainer trees, but the 28-patch series is now reduced to 10, with one tiny patch added at the end. I hope this can still make it into v4.9. Aside from patches that are no longer required, I did these changes compared to version 1: - Dropped "iio: maxim_thermocouple: detect invalid storage size in read()", which is currently in linux-next as commit 32cb7d27e65d. This is the only remaining warning I see for a couple of corner cases (kbuild bot reports it on blackfin, kernelci bot and arm-soc bot both report it on arm64) - Dropped "brcmfmac: avoid maybe-uninitialized warning in brcmf_cfg80211_start_ap", which is currently in net/master merge pending. - Dropped two x86 patches, "x86: math-emu: possible uninitialized variable use" and "x86: mark target address as output in 'insb' asm" as they do not seem to trigger for a default build, and I got no feedback on them. Both of these are ancient issues and seem harmless, I will send them again to the x86 maintainers once the rest is merged. - Dropped "rbd: false-postive gcc-4.9 -Wmaybe-uninitialized" based on feedback from Ilya Dryomov, who already has a different fix queued up for v4.10. The kbuild bot reports this as a warning for xtensa. - Replaced "crypto: aesni: avoid -Wmaybe-uninitialized warning" with a simpler patch, this one always triggers but my first solution would not be safe for linux-4.9 any more at this point. I'll follow up with the larger patch as a cleanup for 4.10. - Replaced "dib0700: fix nec repeat handling" with a better one, contributed by Sean Young. Please merge these directly if you are happy with the result. As the minimum, I'd hope to see the first patch get in soon, but the individual bugfixes are hopefully now all appropriate as well. If you see any regressions with the final patch, just leave that one out and let me know what problems remain. Arnd Arnd Bergmann (10): Kbuild: enable -Wmaybe-uninitialized warning for "make W=1" NFSv4.1: work around -Wmaybe-uninitialized warning x86: apm: avoid uninitialized data nios2: fix timer initcall return value s390: pci: don't print uninitialized data for debugging [media] rc: print correct variable for z8f0811 crypto: aesni: shut up -Wmaybe-uninitialized warning infiniband: shut up a maybe-uninitialized warning pcmcia: fix return value of soc_pcmcia_regulator_set Kbuild: enable -Wmaybe-uninitialized warnings by default Sean Young (1): [media] dib0700: fix nec repeat handling Makefile | 10 +++--- arch/arc/Makefile | 4 ++- arch/nios2/kernel/time.c | 1 + arch/s390/pci/pci_dma.c | 2 +- arch/x86/crypto/aesni-intel_glue.c | 4 +-- arch/x86/kernel/apm_32.c | 5 ++- drivers/infiniband/core/cma.c | 54 +++++++++++++++++--------------- drivers/media/i2c/ir-kbd-i2c.c | 2 +- drivers/media/usb/dvb-usb/dib0700_core.c | 5 +-- drivers/pcmcia/soc_common.c | 2 +- fs/nfs/nfs4session.c | 10 +++--- scripts/Makefile.extrawarn | 1 + scripts/Makefile.ubsan | 4 +++ 13 files changed, 61 insertions(+), 43 deletions(-) -- 2.9.0 Cc: Anna Schumaker <anna.schumaker@xxxxxxxxxx> Cc: "David S. Miller" <davem@xxxxxxxxxxxxx> Cc: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Cc: Ilya Dryomov <idryomov@xxxxxxxxx> Cc: Javier Martinez Canillas <javier@xxxxxxxxxxxxxxx> Cc: Jiri Kosina <jikos@xxxxxxxxxx> Cc: Jonathan Cameron <jic23@xxxxxxxxxx> Cc: Ley Foon Tan <lftan@xxxxxxxxxx> Cc: Luis R. Rodriguez <mcgrof@xxxxxxxxxx> Cc: Martin Schwidefsky <schwidefsky@xxxxxxxxxx> Cc: Mauro Carvalho Chehab <mchehab@xxxxxxxxxx> Cc: Michal Marek <mmarek@xxxxxxxx> Cc: Russell King <linux@xxxxxxxxxxxxxxx> Cc: Sean Young <sean@xxxxxxxx> Cc: Sebastian Ott <sebott@xxxxxxxxxxxxxxxxxx> Cc: Trond Myklebust <trond.myklebust@xxxxxxxxxxxxxxx> Cc: x86@xxxxxxxxxx Cc: linux-kbuild@xxxxxxxxxxxxxxx Cc: linux-kernel@xxxxxxxxxxxxxxx Cc: linux-snps-arc@xxxxxxxxxxxxxxxxxxx Cc: nios2-dev@xxxxxxxxxxxxxxxxxxxxxx Cc: linux-s390@xxxxxxxxxxxxxxx Cc: linux-crypto@xxxxxxxxxxxxxxx Cc: linux-media@xxxxxxxxxxxxxxx Cc: linux-nfs@xxxxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
