Merge branch 'next' into for-linus

Prepare input updates for 5.11 merge window.

Merge tag 'v5.9' into next

Sync up with mainline to bring in the latest DTS files.

Merge branch 'master' into for-next

Sync with Linus' branch in order to be able to apply fixups
of more recent patches.

Merge branch 'for-next' into for-linus

Merge tag 'irqchip-fixes-5.8-1' of git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/urgent

Pull irqchip fixes from Marc Zyngier:

- Fix atomicity of affinity update in the G

Merge tag 'irqchip-fixes-5.8-1' of git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/urgent

Pull irqchip fixes from Marc Zyngier:

- Fix atomicity of affinity update in the GIC driver
- Don't sleep in atomic when waiting for a GICv4.1 RD to respond
- Fix a couple of typos in user-visible messages

show more ...

Merge tag 'v5.8-rc3' into arm/qcom

Linux 5.8-rc3

Backmerge remote-tracking branch 'drm/drm-next' into drm-misc-next

Some conflicts with ttm_bo->offset removal, but drm-misc-next needs updating to v5.8.

Signed-off-by: Maarten Lankhorst <maarten.la

Backmerge remote-tracking branch 'drm/drm-next' into drm-misc-next

Some conflicts with ttm_bo->offset removal, but drm-misc-next needs updating to v5.8.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>

show more ...

Merge drm/drm-next into drm-intel-next-queued

Catch up with upstream, in particular to get c1e8d7c6a7a6 ("mmap locking
API: convert mmap_sem comments").

Signed-off-by: Jani Nikula <jani.nikula@inte

Merge drm/drm-next into drm-intel-next-queued

Catch up with upstream, in particular to get c1e8d7c6a7a6 ("mmap locking
API: convert mmap_sem comments").

Signed-off-by: Jani Nikula <jani.nikula@intel.com>

show more ...

Merge tag 'v5.8-rc1' into regulator-5.8

Linux 5.8-rc1

Merge tag 'v5.8-rc1' into fixes

Linux 5.8-rc1

Merge v5.8-rc1 into drm-misc-fixes

Beginning a new release cycles for what will become v5.8. Updating
drm-misc-fixes accordingly.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>

Merge branch 'dt/schema-cleanups' into dt/linus

Merge branch 'x86/entry' into ras/core

to fixup conflicts in arch/x86/kernel/cpu/mce/core.c so MCE specific follow
up patches can be applied without creating a horrible merge conflict
afterwards.

Merge tag 'sh-for-5.8' of git://git.libc.org/linux-sh

Pull arch/sh updates from Rich Felker:
"Fix for arch/sh build regression with newer binutils, removal of SH5,
fixes for module exports, and m

Merge tag 'sh-for-5.8' of git://git.libc.org/linux-sh

Pull arch/sh updates from Rich Felker:
"Fix for arch/sh build regression with newer binutils, removal of SH5,
fixes for module exports, and misc cleanup"

* tag 'sh-for-5.8' of git://git.libc.org/linux-sh:
sh: remove sh5 support
sh: add missing EXPORT_SYMBOL() for __delay
sh: Convert ins[bwl]/outs[bwl] macros to inline functions
sh: Convert iounmap() macros to inline functions
sh: Add missing DECLARE_EXPORT() for __ashiftrt_r4_xx
sh: configs: Cleanup old Kconfig IO scheduler options
arch/sh: vmlinux.scr
sh: Replace CONFIG_MTD_M25P80 with CONFIG_MTD_SPI_NOR in sh7757lcr_defconfig
sh: sh4a: Bring back tmu3_device early device

show more ...

sh: remove sh5 support

sh5 never became a product and has probably never really worked.

Remove it by recursively deleting all associated Kconfig options
and all corresponding files.

Reviewed-by: G

sh: remove sh5 support

sh5 never became a product and has probably never really worked.

Remove it by recursively deleting all associated Kconfig options
and all corresponding files.

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Rich Felker <dalias@libc.org>

show more ...

Merge tag 'v4.20' into for-linus

Sync with mainline to get linux/overflow.h among other things.

Merge tag 'v4.20' into next

Merge with mainline to bring in the new APIs.

Merge branch 'for-4.19/cougar' into for-linus

New device support for hid-cougar

Merge branch 'iomap-write' into linux-gfs2/for-next

Pull in the gfs2 iomap-write changes: Tweak the existing code to
properly support iomap write and eliminate an unnecessary special case
in gfs2_bl

Merge branch 'iomap-write' into linux-gfs2/for-next

Pull in the gfs2 iomap-write changes: Tweak the existing code to
properly support iomap write and eliminate an unnecessary special case
in gfs2_block_map. Implement iomap write support for buffered and
direct I/O. Simplify some of the existing code and eliminate code that
is no longer used:

gfs2: Remove gfs2_write_{begin,end}
gfs2: iomap direct I/O support
gfs2: gfs2_extent_length cleanup
gfs2: iomap buffered write support
gfs2: Further iomap cleanups

This is based on the following changes on the xfs 'iomap-4.19-merge'
branch:

iomap: add private pointer to struct iomap
iomap: add a page_done callback
iomap: generic inline data handling
iomap: complete partial direct I/O writes synchronously
iomap: mark newly allocated buffer heads as new
fs: factor out a __generic_write_end helper

Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>

show more ...

Merge drm/drm-next into drm-intel-next-queued

We need a backmerge to get DP_DPCD_REV_14 before we push other
i915 changes to dinq that could break compilation.

Signed-off-by: Rodrigo Vivi <rodrigo.

Merge drm/drm-next into drm-intel-next-queued

We need a backmerge to get DP_DPCD_REV_14 before we push other
i915 changes to dinq that could break compilation.

Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

show more ...

Merge remote-tracking branch 'gpio/ib-aspeed' into upstream-ready

Merge the GPIO tree "ib-aspeed" topic branch which contains pre-requisites
for subsequent changes. This branch is also in gpio "next

Merge remote-tracking branch 'gpio/ib-aspeed' into upstream-ready

Merge the GPIO tree "ib-aspeed" topic branch which contains pre-requisites
for subsequent changes. This branch is also in gpio "next".

show more ...

Merge tag 'v4.18-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux into fbdev-for-next

Linux 4.18-rc2

Merge tag 'v4.18-rc2' into next-general

Merge to Linux 4.18-rc2 for security subsystem developers.

Merge branch 'linus' into x86/urgent

Required to queue a dependent fix.

Kbuild: rename CC_STACKPROTECTOR[_STRONG] config variables

The changes to automatically test for working stack protector compiler
support in the Kconfig files removed the special STACKPROTECTOR_AUTO

Kbuild: rename CC_STACKPROTECTOR[_STRONG] config variables

The changes to automatically test for working stack protector compiler
support in the Kconfig files removed the special STACKPROTECTOR_AUTO
option that picked the strongest stack protector that the compiler
supported.

That was all a nice cleanup - it makes no sense to have the AUTO case
now that the Kconfig phase can just determine the compiler support
directly.

HOWEVER.

It also meant that doing "make oldconfig" would now _disable_ the strong
stackprotector if you had AUTO enabled, because in a legacy config file,
the sane stack protector configuration would look like

CONFIG_HAVE_CC_STACKPROTECTOR=y
# CONFIG_CC_STACKPROTECTOR_NONE is not set
# CONFIG_CC_STACKPROTECTOR_REGULAR is not set
# CONFIG_CC_STACKPROTECTOR_STRONG is not set
CONFIG_CC_STACKPROTECTOR_AUTO=y

and when you ran this through "make oldconfig" with the Kbuild changes,
it would ask you about the regular CONFIG_CC_STACKPROTECTOR (that had
been renamed from CONFIG_CC_STACKPROTECTOR_REGULAR to just
CONFIG_CC_STACKPROTECTOR), but it would think that the STRONG version
used to be disabled (because it was really enabled by AUTO), and would
disable it in the new config, resulting in:

CONFIG_HAVE_CC_STACKPROTECTOR=y
CONFIG_CC_HAS_STACKPROTECTOR_NONE=y
CONFIG_CC_STACKPROTECTOR=y
# CONFIG_CC_STACKPROTECTOR_STRONG is not set
CONFIG_CC_HAS_SANE_STACKPROTECTOR=y

That's dangerously subtle - people could suddenly find themselves with
the weaker stack protector setup without even realizing.

The solution here is to just rename not just the old RECULAR stack
protector option, but also the strong one. This does that by just
removing the CC_ prefix entirely for the user choices, because it really
is not about the compiler support (the compiler support now instead
automatially impacts _visibility_ of the options to users).

This results in "make oldconfig" actually asking the user for their
choice, so that we don't have any silent subtle security model changes.
The end result would generally look like this:

CONFIG_HAVE_CC_STACKPROTECTOR=y
CONFIG_CC_HAS_STACKPROTECTOR_NONE=y
CONFIG_STACKPROTECTOR=y
CONFIG_STACKPROTECTOR_STRONG=y
CONFIG_CC_HAS_SANE_STACKPROTECTOR=y

where the "CC_" versions really are about internal compiler
infrastructure, not the user selections.

Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

show more ...