commit 68d54cee

 upstream.

The ptrace(PTRACE_PEEKMTETAGS) implementation checks whether the user
page has valid tags (mapped with PROT_MTE) by testing the PG_mte_tagged
page flag. If this bit is cleared, ptrace(PTRACE_PEEKMTETAGS) returns
-EIO.

A newly created (PROT_MTE) mapping points to the zero page which had its
tags zeroed during cpu_enable_mte(). If there were no prior writes to
this mapping, ptrace(PTRACE_PEEKMTETAGS) fails with -EIO since the zero
page does not have the PG_mte_tagged flag set.

Set PG_mte_tagged on the zero page when its tags are cleared during
boot. In addition, to avoid ptrace(PTRACE_PEEKMTETAGS) succeeding on
!PROT_MTE mappings pointing to the zero page, change the
__access_remote_tags() check to (vm_flags & VM_MTE) instead of
PG_mte_tagged.

Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Fixes: 34bfeea4

 ("arm64: mte: Clear the tags when a page is mapped in user-space with PROT_MTE")
Cc: <stable@vger.kernel.org> # 5.10.x
Cc: Will Deacon <will@kernel.org>
Reported-by: Luis Machado <luis.machado@linaro.org>
Tested-by: Luis Machado <luis.machado@linaro.org>
Reviewed-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
Link: https://lore.kernel.org/r/20210210180316.23654-1-catalin.marinas@arm.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

[ Upstream commit 74532de4

 ]

NanoPi R2S is headless, so rightly does not enable any of the display
interface hardware, which currently provokes an obnoxious error in the
boot log from the fake DRM device failing to find anything to bind to.
It probably isn't *too* hard to obviate the fake device shenanigans
entirely with a bit of driver reshuffling, but for now let's just
disable it here to shut up the spurious error.

Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Link: https://lore.kernel.org/r/c4553dfad1ad6792c4f22454c135ff55de77e2d6.1611186099.git.robin.murphy@arm.com


Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>

[ Upstream commit 94a5400f

 ]

A test with the command below gives this error:
/arch/arm64/boot/dts/rockchip/rk3399-evb.dt.yaml: video-codec@ff660000:
'interrupt-names' does not match any of the regexes: 'pinctrl-[0-9]+'

The rkvdec driver gets it irq with help of the platform_get_irq()
function, so remove the interrupt-names property from the rk3399
vdec node.

make ARCH=arm64 dtbs_check
DT_SCHEMA_FILES=Documentation/devicetree/bindings/
media/rockchip,vdec.yaml

Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Link: https://lore.kernel.org/r/20210117181653.24886-1-jbx6244@gmail.com


Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>

[ Upstream commit 93f2a115

 ]

The GCC_LPASS_Q6_AXI_CLK and GCC_LPASS_SWAY_CLK clocks may not be
touched on a typical UEFI based SDM845 device, but when the kernel is
built with CONFIG_SDM_LPASSCC_845 this happens, unless they are marked
as protected-clocks in the DT.

This was done for the MTP and the Pocophone, but not for DB845c and the
Lenovo Yoga C630 - causing these to fail to boot if the LPASS clock
controller is enabled (which it typically isn't).

Tested-by: Vinod Koul <vkoul@kernel.org> #on db845c
Reviewed-by: Vinod Koul <vkoul@kernel.org>
Link: https://lore.kernel.org/r/20201222001103.3112306-1-bjorn.andersson@linaro.org


Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>

[ Upstream commit 43f20b1c

 ]

It recently became apparent that the lack of a 'device_type = "pci"'
in the PCIe root complex node for rk3399 is a violation of the PCI
binding, as documented in IEEE Std 1275-1994. Changes to the kernel's
parsing of the DT made such violation fatal, as drivers cannot
probe the controller anymore.

Add the missing property makes the PCIe node compliant. While we
are at it, drop the pointless linux,pci-domain property, which only
makes sense when there are multiple host bridges.

Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20200815125112.462652-3-maz@kernel.org


Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>

See: https://github.com/raspberrypi/linux/issues/4144

(from https://github.com/RPi-Distro/repo/issues/229

)

Signed-off-by: Phil Elwell <phil@raspberrypi.com>

VGA666 uses "vga-connector" from DRM_DISPLAY_CONNECTOR, and
"dumb-vga-dac" from DRM_SIMPLE_BRIDGE to connect up, so add them
to the defconfigs.

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>

[ Upstream commit aa880c6f

 ]

Dcfg was overlapping with clockgen address space which resulted
in failure in memory allocation for dcfg. According regs description
dcfg size should not be bigger than 4KB.

Signed-off-by: Zyta Szpak <zr@semihalf.com>
Fixes: 8126d881

 ("arm64: dts: add QorIQ LS1046A SoC support")
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>

[ Upstream commit daf12bee

 ]

For the proper reboot Odroid-C4 board requires to switch TFLASH_VDD_EN
pin to the high impedance mode, otherwise the board is stuck in the
middle of loading early stages of the bootloader from SD card.

This can be achieved by using the OPEN_DRAIN flag instead of the
ACTIVE_HIGH, what will leave the pin in input mode to achieve high state
(pin has the pull-up) and solve the issue.

Suggested-by: Neil Armstrong <narmstrong@baylibre.com>
Fixes: 326e5751

 ("arm64: dts: meson-sm1: add support for Hardkernel ODROID-C4")
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Link: https://lore.kernel.org/r/20210122055218.27241-1-m.szyprowski@samsung.com


Signed-off-by: Sasha Levin <sashal@kernel.org>

[ Upstream commit 642fb279 ]

On Pinebook Pro laptops with an NVMe SSD installed, prevent random
crashes in the NVMe driver by not attempting to use a PCIe link speed
higher than that supported by the RK3399 SoC.

See commit 712fa177 ("arm64: dts: rockchip: add max-link-speed for
rk3399").

Fixes: 5a65505a

 ("arm64: dts: rockchip: Add initial support for Pinebook Pro")
Signed-off-by: Simon South <simon@simonsouth.net>
Link: https://lore.kernel.org/r/20200930185627.5918-1-simon@simonsouth.net


Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>

[ Upstream commit 656c6483 ]

The vop-mmu shares the irq with its matched vop but not the vpu.

Fixes: 7053e06b

 ("arm64: dts: rockchip: add core dtsi file for PX30 SoCs")
Signed-off-by: Sandy Huang <hjc@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Ezequiel Garcia <ezequiel@collabora.com>
Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Tested-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Link: https://lore.kernel.org/r/20210108110627.3231226-1-heiko@sntech.de


Signed-off-by: Sasha Levin <sashal@kernel.org>

[ Upstream commit 7386a559 ]

In accordance with the DWC USB3 bindings the property is supposed to have
uint32 type. It's erroneous from the DT schema and driver points of view
to declare it as boolean. As Neil suggested set it to 0x20 so not break
the platform and to make the dtbs checker happy.

Link: https://lore.kernel.org/linux-usb/20201010224121.12672-16-Sergey.Semin@baikalelectronics.ru/


Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Fixes: 9baf7d6b

 ("arm64: dts: meson: g12a: Add G12A USB nodes")
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Link: https://lore.kernel.org/r/20201210091756.18057-3-Sergey.Semin@baikalelectronics.ru


Signed-off-by: Sasha Levin <sashal@kernel.org>

[ Upstream commit a9164910 ]

Indicated by AML code in ACPI table, the touchpad in-use could be found
on two possible slave addresses on &i2c3, i.e. hid@15 and hid@2c.  And
which one is in-use can be determined by reading another address on the
I2C bus.  Unfortunately, for DT boot, there is currently no support in
firmware to make this check and patch DT accordingly.  This results in
a non-functional touchpad on those C630 devices with hid@2c.

As i2c-hid driver will stop probing the device if there is nothing on
the slave address, we can actually keep both devices enabled in DT, and
i2c-hid driver will only probe the existing one.  The only problem is
that we cannot set up pinctrl in both device nodes, as two devices with
the same pinctrl will cause pin conflict that makes the second device
fail to probe.  Let's move the pinctrl state up to parent node to solve
this problem.  As the pinctrl state of parent node is already defined in
sdm845.dtsi, it ends up with overwriting pinctrl-0 with i2c3_hid_active
state added in there.

Fixes: 11d0e4f2

 ("arm64: dts: qcom: c630: Polish i2c-hid devices")
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Link: https://lore.kernel.org/r/20210102045940.26874-1-shawn.guo@linaro.org


Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 91cb2c8b upstream.

Commit 519ea6f1 ("arm64: Fix kernel address detection of
__is_lm_address()") fixed the incorrect validation of addresses below
PAGE_OFFSET. However, it no longer allowed tagged addresses to be passed
to virt_addr_valid().

Fix this by explicitly resetting the pointer tag prior to invoking
__is_lm_address(). This is consistent with the __lm_to_phys() macro.

Fixes: 519ea6f1

 ("arm64: Fix kernel address detection of __is_lm_address()")
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Cc: <stable@vger.kernel.org> # 5.4.x
Cc: Will Deacon <will@kernel.org>
Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Link: https://lore.kernel.org/r/20210201190634.22942-2-catalin.marinas@arm.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 519ea6f1 upstream.

Currently, the __is_lm_address() check just masks out the top 12 bits
of the address, but if they are 0, it still yields a true result.
This has as a side effect that virt_addr_valid() returns true even for
invalid virtual addresses (e.g. 0x0).

Fix the detection checking that it's actually a kernel address starting
at PAGE_OFFSET.

Fixes: 68dd8ef3

 ("arm64: memory: Fix virt_addr_valid() using __is_lm_address()")
Cc: <stable@vger.kernel.org> # 5.4.x
Cc: Will Deacon <will@kernel.org>
Suggested-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
Link: https://lore.kernel.org/r/20210126134056.45747-1-vincenzo.frascino@arm.com


Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 03544505

 upstream.

According to a downstream commit I found in the Khadas vendor kernel,
the GPU on G12b is wired up for ACE-lite, so (now that Panfrost knows
how to handle this properly) we should describe it as such. Otherwise
the mismatch leads to all manner of fun with mismatched attributes and
inadvertently snooping stale data from caches, which would account for
at least some of the brokenness observed on this platform.

Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Tested-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://patchwork.freedesktop.org/patch/msgid/765446e529e50b304af63432da7836c4d31eb8d4.1600780574.git.robin.murphy@arm.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The BCM2711 has a number of instances of interrupt controllers handled
by the driver behind the BRCMSTB_L2_IRQ Kconfig option (irq-brcmstb-l2).

Let's select that driver as part of the ARCH_BCM2835 Kconfig option.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>

Signed-off-by: Phil Elwell <phil@raspberrypi.com>

[ Upstream commit b764eb65

 ]

On i.MX8MP, The GPIO3's secondary gpio-ranges's 'gpio controller offset'
cell value should be 26, so correct it.

Signed-off-by: Jacky Bai <ping.bai@nxp.com>
Fixes: 6d9b8d20

 ("arm64: dts: freescale: Add i.MX8MP dtsi support")
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>

[ Upstream commit 1653e3d4 ]

The offset of the reset request register is 0, the absolute address is
0x1e60000. Boards without PSCI support will fail to perform a reset:

[   26.734700] reboot: Restarting system
[   27.743259] Unable to restart system
[   27.746845] Reboot failed -- System halted

Fixes: 8897f325

 ("arm64: dts: Add support for NXP LS1028A SoC")
Signed-off-by: Michael Walle <michael@walle.cc>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>

commit da8ee66f upstream.

Add a non-empty dma-ranges so that DMA address translation happens.

Fixes: 2013a4b6

 ("arm64: dts: broadcom: clear the warnings caused by empty dma-ranges")
Signed-off-by: Bharat Gooty <bharat.gooty@broadcom.com>
Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Ray Jui <ray.jui@broadcom.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9529aaa0 upstream.

When running on v8.0 HW, make sure we don't try to advertise
events in the 0x4000-0x403f range.

Cc: stable@vger.kernel.org
Fixes: 88865bec

 ("KVM: arm64: Mask out filtered events in PCMEID{0,1}_EL1")
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20210121105636.1478491-1-maz@kernel.org


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

See: https://www.raspberrypi.org/forums/viewtopic.php?f=44&t=301072

See: https://github.com/raspberrypi/linux/issues/3648



Signed-off-by: Phil Elwell <phil@raspberrypi.com>

Signed-off-by: Phil Elwell <phil@raspberrypi.com>

It'll be used by the RPi4 family of boards to access its bootloader
configuration.

Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>

See: https://github.com/raspberrypi/linux/pull/4086



Signed-off-by: Phil Elwell <phil@raspberrypi.com>

Signed-off-by: popcornmix <popcornmix@gmail.com>

The arm64 version of bcm2711_defconfig is intended for Pi 4, but the
Raspberry Pi OS kernel8.img built from it is also used for Pi 3. It is
therefore necessary to include some legacy drivers such as the BCM2835
thermal driver, otherwise there is no support for reading the CPU
temperature on a Pi 3 in 64-bit mode.

See: https://github.com/raspberrypi/linux/issues/4077



Signed-off-by: Phil Elwell <phil@raspberrypi.com>

Include the driver module for the PCF85063 and PCF85063A RTC devices.

Signed-off-by: Phil Elwell <phil@raspberrypi.com>

Signed-off-by: Sudeep <sudeepkumar@cem-solutions.net>

CONFIG_BRIDGE_NETFILTER=m used to be the default when CONFIG_NETFILTER
was enabled, but that was removed in 5.9. The way that defconfigs work
caused this wanted setting to be lost in rpi-5.9.y and rpi-5.10.y -
restore it now.

See: https://github.com/Hexxeh/rpi-firmware/issues/248



Signed-off-by: Phil Elwell <phil@raspberrypi.com>

The CAN_ISOTP setting was in the wrong position, and it's better for
bisecting and reverting if this doesn't get rolled into the next
config-changing commit.

Signed-off-by: Phil Elwell <phil@raspberrypi.com>

* Add mcp251xfd driver module to the RPi kernel builds.
* Add isotp can protocol module to the RPi kernel builds.

Signed-off-by: Patrick Menschel <menschel.p@posteo.de>

Signed-off-by: Phil Elwell <phil@raspberrypi.com>

Enable support for MAX31856 temperature sensors.

See: https://github.com/raspberrypi/linux/issues/3915



Signed-off-by: Phil Elwell <phil@raspberrypi.com>

Signed-off-by: David Knell <david.knell@gmail.com>

RASPBERRYPI_FIRMWARE was missing from the arm64 bcm2711_defconfig.
bcmrpi3_defconfig was also missing a few options. Add the misssing
settings and regenerate all the Pi defconfigs.

Signed-off-by: Phil Elwell <phil@raspberrypi.com>

Signed-off-by: Phil Elwell <phil@raspberrypi.com>

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>