Pull ARM SoC fixes from Arnd Bergmann:
 "Here is a third set of fixes for the soc tree, well within the
  expected set of changes.

  Maintainer list changes:
   - Krzysztof Kozlowski and Jisheng Zhang both have new email addresses
   - Broadcom iProc has a new git tree

  Regressions:
   - Robert Foss sends a revert for a Mediatek DPI bridge patch that
     caused an inadvertent break in the DT binding
   - mstar timers need to be included in Kconfig

  Devicetree fixes for:
   - Aspeed ast2600 spi pinmux
   - Tegra eDP panels on Nyan FHD
   - Tegra display IOMMU
   - Qualcomm sm8350 UFS clocks
   - minor DT changes for Marvell Armada, Qualcomm sdx65, Qualcomm
     sm8450, and Broadcom BCM2711"

* tag 'soc-fixes-5.17-3' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc:
  arm64: dts: marvell: armada-37xx: Remap IO space to bus address 0x0
  MAINTAINERS: Update Jisheng's email address
  Revert "arm64: dts: mt8183: jacuzzi: Fix bus properties in anx's DSI endpoint"
  dt-bindings: drm/bridge: anx7625: Revert DPI support
  ARM: dts: aspeed: Fix AST2600 quad spi group
  MAINTAINERS: update Krzysztof Kozlowski's email
  MAINTAINERS: Update git tree for Broadcom iProc SoCs
  ARM: tegra: Move Nyan FHD panels to AUX bus
  arm64: dts: armada-3720-turris-mox: Add missing ethernet0 alias
  ARM: mstar: Select HAVE_ARM_ARCH_TIMER
  soc: mediatek: mt8192-mmsys: Fix dither to dsi0 path's input sel
  arm64: dts: mt8183: jacuzzi: Fix bus properties in anx's DSI endpoint
  ARM: boot: dts: bcm2711: Fix HVS register range
  arm64: dts: qcom: c630: disable crypto due to serror
  arm64: dts: qcom: sm8450: fix apps_smmu interrupts
  arm64: dts: qcom: sm8450: enable GCC_USB3_0_CLKREF_EN for usb
  arm64: dts: qcom: sm8350: Correct UFS symbol clocks
  arm64: tegra: Disable ISO SMMU for Tegra194
  Revert "dt-bindings: arm: qcom: Document SDX65 platform and boards"

Instead of using GUP, make fault_in_safe_writeable() actually force a
'handle_mm_fault()' using the same fixup_user_fault() machinery that
futexes already use.

Using the GUP machinery meant that fault_in_safe_writeable() did not do
everything that a real fault would do, ranging from not auto-expanding
the stack segment, to not updating accessed or dirty flags in the page
tables (GUP sets those flags on the pages themselves).

The latter causes problems on architectures (like s390) that do accessed
bit handling in software, which meant that fault_in_safe_writeable()
didn't actually do all the fault handling it needed to, and trying to
access the user address afterwards would still cause faults.
Reported-and-tested-by: NAndreas Gruenbacher <agruenba@redhat.com>
Fixes: cdd591fc ("iov_iter: Introduce fault_in_iov_iter_writeable")
Link: https://lore.kernel.org/all/CAHc6FU5nP+nziNGG0JAF1FUx-GV7kKFvM7aZuU_XD2_1v4vnvg@mail.gmail.com/Acked-by: NDavid Hildenbrand <david@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Merge tag 'mvebu-fixes-5.17-2' of git://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu into arm/fixes

mvebu fixes for 5.17 (part 2)

Allow using old PCIe card on Armada 37xx

* tag 'mvebu-fixes-5.17-2' of git://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu:
  arm64: dts: marvell: armada-37xx: Remap IO space to bus address 0x0

Link: https://lore.kernel.org/r/87bkydj4fn.fsf@BL-laptopSigned-off-by: NArnd Bergmann <arnd@arndb.de>

Legacy and old PCI I/O based cards do not support 32-bit I/O addressing.

Since commit 64f160e1 ("PCI: aardvark: Configure PCIe resources from
'ranges' DT property") kernel can set different PCIe address on CPU and
different on the bus for the one A37xx address mapping without any firmware
support in case the bus address does not conflict with other A37xx mapping.

So remap I/O space to the bus address 0x0 to enable support for old legacy
I/O port based cards which have hardcoded I/O ports in low address space.

Note that DDR on A37xx is mapped to bus address 0x0. And mapping of I/O
space can be set to address 0x0 too because MEM space and I/O space are
separate and so do not conflict.

Remapping IO space on Turris Mox to different address is not possible to
due bootloader bug.
Signed-off-by: NPali Rohár <pali@kernel.org>
Reported-by: NArnd Bergmann <arnd@arndb.de>
Fixes: 76f6386b ("arm64: dts: marvell: Add Aardvark PCIe support for Armada 3700")
Cc: stable@vger.kernel.org # 64f160e1 ("PCI: aardvark: Configure PCIe resources from 'ranges' DT property")
Cc: stable@vger.kernel.org # 514ef1e6 ("arm64: dts: marvell: armada-37xx: Extend PCIe MEM space")
Reviewed-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NGregory CLEMENT <gregory.clement@bootlin.com>

Pull spi fix from Mark Brown:
 "One fix for type conversion issues when working out maximum
  scatter/gather segment sizes.

  It caused problems for some systems where the limits overflow
  due to the type conversion"

* tag 'spi-fix-v5.17-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi:
  spi: Fix invalid sgs value

The kernel test robot discovered that building without
HARDEN_BRANCH_PREDICTOR issues a warning due to a missing
argument to pr_info().

Add the missing argument.
Reported-by: Nkernel test robot <lkp@intel.com>
Fixes: 9dd78194 ("ARM: report Spectre v2 status through sysfs")
Signed-off-by: NRussell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Pull gpio fixes from Bartosz Golaszewski:

 - fix a probe failure for Tegra241 GPIO controller in gpio-tegra186

 - revert changes that caused a regression in the sysfs user-space
   interface

 - correct the debounce time conversion in GPIO ACPI

 - statify a struct in gpio-sim and fix a typo

 - update registers in correct order (hardware quirk) in gpio-ts4900

* tag 'gpio-fixes-for-v5.17' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux:
  gpio: sim: fix a typo
  gpio: ts4900: Do not set DAT and OE together
  gpio: sim: Declare gpio_sim_hog_config_item_ops static
  gpiolib: acpi: Convert ACPI value of debounce to microseconds
  gpio: Revert regression in sysfs-gpio (gpiolib.c)
  gpio: tegra186: Add IRQ per bank for Tegra241

Just noticed this when applying Andy's patch. s/childred/children/

Fixes: cb8c474e ("gpio: sim: new testing module")
Signed-off-by: NBartosz Golaszewski <brgl@bgdev.pl>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

This works around an issue with the hardware where both OE and
DAT are exposed in the same register. If both are updated
simultaneously, the harware makes no guarantees that OE or DAT
will actually change in any given order and may result in a
glitch of a few ns on a GPIO pin when changing direction and value
in a single write.

Setting direction to input now only affects OE bit. Setting
direction to output updates DAT first, then OE.

Fixes: 9c668632 ("gpio: add Technologic I2C-FPGA gpio support")
Signed-off-by: NMark Featherston <mark@embeddedTS.com>
Signed-off-by: NKris Bahnsen <kris@embeddedTS.com>
Signed-off-by: NBartosz Golaszewski <brgl@bgdev.pl>

Pull clk fixes from Stephen Boyd:
 "One more small batch of clk driver fixes:

   - A fix for the Qualcomm GDSC power domain delays that avoids black
     screens at boot on some more recent SoCs that use a different delay
     than the hard-coded delays in the driver.

   - A build fix LAN966X clk driver that let it be built on
     architectures that didn't have IOMEM"

* tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux:
  clk: lan966x: Fix linking error
  clk: qcom: dispcc: Update the transition delay for MDSS GDSC
  clk: qcom: gdsc: Add support to update GDSC transition delay

Pull xen fixes from Juergen Gross:
 "Several Linux PV device frontends are using the grant table interfaces
  for removing access rights of the backends in ways being subject to
  race conditions, resulting in potential data leaks, data corruption by
  malicious backends, and denial of service triggered by malicious
  backends:

   - blkfront, netfront, scsifront and the gntalloc driver are testing
     whether a grant reference is still in use. If this is not the case,
     they assume that a following removal of the granted access will
     always succeed, which is not true in case the backend has mapped
     the granted page between those two operations.

     As a result the backend can keep access to the memory page of the
     guest no matter how the page will be used after the frontend I/O
     has finished. The xenbus driver has a similar problem, as it
     doesn't check the success of removing the granted access of a
     shared ring buffer.

   - blkfront, netfront, scsifront, usbfront, dmabuf, xenbus, 9p,
     kbdfront, and pvcalls are using a functionality to delay freeing a
     grant reference until it is no longer in use, but the freeing of
     the related data page is not synchronized with dropping the granted
     access.

     As a result the backend can keep access to the memory page even
     after it has been freed and then re-used for a different purpose.

   - netfront will fail a BUG_ON() assertion if it fails to revoke
     access in the rx path.

     This will result in a Denial of Service (DoS) situation of the
     guest which can be triggered by the backend"

* tag 'xsa396-5.17-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
  xen/netfront: react properly to failing gnttab_end_foreign_access_ref()
  xen/gnttab: fix gnttab_end_foreign_access() without page specified
  xen/pvcalls: use alloc/free_pages_exact()
  xen/9p: use alloc/free_pages_exact()
  xen/usb: don't use gnttab_end_foreign_access() in xenhcd_gnttab_done()
  xen: remove gnttab_query_foreign_access()
  xen/gntalloc: don't use gnttab_query_foreign_access()
  xen/scsifront: don't use gnttab_query_foreign_access() for mapped status
  xen/netfront: don't use gnttab_query_foreign_access() for mapped status
  xen/blkfront: don't use gnttab_query_foreign_access() for mapped status
  xen/grant-table: add gnttab_try_end_foreign_access()
  xen/xenbus: don't let xenbus_grant_ring() remove grants in error case

Pull arm64 build fix from Catalin Marinas:
 "Fix kernel build with clang LTO after the inclusion of the Spectre BHB
  arm64 mitigations"

* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
  arm64: Do not include __READ_ONCE() block in assembly files

ld.lld does not support the NOCROSSREFS directive at the moment, which
breaks the build after commit b9baf5c8 ("ARM: Spectre-BHB
workaround"):

  ld.lld: error: ./arch/arm/kernel/vmlinux.lds:34: AT expected, but got NOCROSSREFS

Support for this directive will eventually be implemented, at which
point a version check can be added. To avoid breaking the build in the
meantime, just define NOCROSSREFS to nothing when using ld.lld, with a
link to the issue for tracking.

Cc: stable@vger.kernel.org
Fixes: b9baf5c8 ("ARM: Spectre-BHB workaround")
Link: https://github.com/ClangBuiltLinux/linux/issues/1609Signed-off-by: NNathan Chancellor <nathan@kernel.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

When building arm64 defconfig + CONFIG_LTO_CLANG_{FULL,THIN}=y after
commit 558c303c ("arm64: Mitigate spectre style branch history side
channels"), the following error occurs:

  <instantiation>:4:2: error: invalid fixup for movz/movk instruction
   mov w0, #ARM_SMCCC_ARCH_WORKAROUND_3
   ^

Marc figured out that moving "#include <linux/init.h>" in
include/linux/arm-smccc.h into a !__ASSEMBLY__ block resolves it. The
full include chain with CONFIG_LTO=y from include/linux/arm-smccc.h:

include/linux/init.h
include/linux/compiler.h
arch/arm64/include/asm/rwonce.h
arch/arm64/include/asm/alternative-macros.h
arch/arm64/include/asm/assembler.h

The asm/alternative-macros.h include in asm/rwonce.h only happens when
CONFIG_LTO is set, which ultimately casues asm/assembler.h to be
included before the definition of ARM_SMCCC_ARCH_WORKAROUND_3. As a
result, the preprocessor does not expand ARM_SMCCC_ARCH_WORKAROUND_3 in
__mitigate_spectre_bhb_fw, which results in the error above.

Avoid this problem by just avoiding the CONFIG_LTO=y __READ_ONCE() block
in asm/rwonce.h with assembly files, as nothing in that block is useful
to assembly files, which allows ARM_SMCCC_ARCH_WORKAROUND_3 to be
properly expanded with CONFIG_LTO=y builds.

Fixes: e35123d8 ("arm64: lto: Strengthen READ_ONCE() to acquire when CONFIG_LTO=y")
Cc: <stable@vger.kernel.org> # 5.11.x
Link: https://lore.kernel.org/r/20220309155716.3988480-1-maz@kernel.org/Reported-by: NMarc Zyngier <maz@kernel.org>
Acked-by: NJames Morse <james.morse@arm.com>
Signed-off-by: NNathan Chancellor <nathan@kernel.org>
Link: https://lore.kernel.org/r/20220309191633.2307110-1-nathan@kernel.orgSigned-off-by: NCatalin Marinas <catalin.marinas@arm.com>

Pull HID fixes from Jiri Kosina:

 - sysfs attributes leak fix for Google Vivaldi driver (Dmitry Torokhov)

 - fix for potential out-of-bounds read in Thrustmaster driver (Pavel
   Skripkin)

 - error handling reference leak in Elo driver (Jiri Kosina)

 - a few new device IDs

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid:
  HID: nintendo: check the return value of alloc_workqueue()
  HID: vivaldi: fix sysfs attributes leak
  HID: hid-thrustmaster: fix OOB read in thrustmaster_interrupts
  HID: elo: Revert USB reference counting
  HID: Add support for open wheel and no attachment to T300
  HID: logitech-dj: add new lightspeed receiver id

Pull arm64 fixes from Catalin Marinas:

 - Fix compilation of eBPF object files that indirectly include
   mte-kasan.h.

 - Fix test for execute-only permissions with EPAN (Enhanced Privileged
   Access Never, ARMv8.7 feature).

* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
  arm64: kasan: fix include error in MTE functions
  arm64: Ensure execute-only permissions are not allowed without EPAN

In the recent Spectre BHB patches, there was a typo that is only
exposed in certain configurations: mcr p15,0,XX,c7,r5,4 should have
been mcr p15,0,XX,c7,c5,4
Reported-by: Nkernel test robot <lkp@intel.com>
Fixes: b9baf5c8 ("ARM: Spectre-BHB workaround")
Signed-off-by: NRussell King (Oracle) <rmk+kernel@armlinux.org.uk>
Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Fix `error: expected string literal in 'asm'`.
This happens when compiling an ebpf object file that includes
`net/net_namespace.h` from linux kernel headers.

Include trace:
     include/net/net_namespace.h:10
     include/linux/workqueue.h:9
     include/linux/timer.h:8
     include/linux/debugobjects.h:6
     include/linux/spinlock.h:90
     include/linux/workqueue.h:9
     arch/arm64/include/asm/spinlock.h:9
     arch/arm64/include/generated/asm/qrwlock.h:1
     include/asm-generic/qrwlock.h:14
     arch/arm64/include/asm/processor.h:33
     arch/arm64/include/asm/kasan.h:9
     arch/arm64/include/asm/mte-kasan.h:45
     arch/arm64/include/asm/mte-def.h:14
Signed-off-by: NPaul Semel <paul.semel@datadoghq.com>
Fixes: 2cb34276 ("arm64: kasan: simplify and inline MTE functions")
Cc: <stable@vger.kernel.org> # 5.12.x
Link: https://lore.kernel.org/r/bacb5387-2992-97e4-0c48-1ed925905bee@gmail.comSigned-off-by: NCatalin Marinas <catalin.marinas@arm.com>

It was missing a semicolon.
Signed-off-by: NEmmanuel Gil Peyrot <linkmauve@linkmauve.fr>
Reviewed-by: NNathan Chancellor <nathan@kernel.org>
Fixes: 25875aa7 ("ARM: include unprivileged BPF status in Spectre V2 reporting").
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Pull devicetree fixes from Rob Herring:

 - Fix pinctrl node name warnings in examples

 - Add missing 'mux-states' property in ti,tcan104x-can binding

* tag 'devicetree-fixes-for-5.17-3' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux:
  dt-bindings: phy: ti,tcan104x-can: Document mux-states property
  dt-bindings: mfd: Fix pinctrl node name warnings

Pull fuse fixes from Miklos Szeredi:

 - Fix an issue with splice on the fuse device

 - Fix a regression in the fileattr API conversion

 - Add a small userspace API improvement

* tag 'fuse-fixes-5.17-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse:
  fuse: fix pipe buffer lifetime for direct_io
  fuse: move FUSE_SUPER_MAGIC definition to magic.h
  fuse: fix fileattr op failure

Merge tag 'arm64-spectre-bhb-for-v5.17-2' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux

Pull arm64 spectre fixes from James Morse:
 "ARM64 Spectre-BHB mitigations:

   - Make EL1 vectors per-cpu

   - Add mitigation sequences to the EL1 and EL2 vectors on vulnerble
     CPUs

   - Implement ARCH_WORKAROUND_3 for KVM guests

   - Report Vulnerable when unprivileged eBPF is enabled"

* tag 'arm64-spectre-bhb-for-v5.17-2' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
  arm64: proton-pack: Include unprivileged eBPF status in Spectre v2 mitigation reporting
  arm64: Use the clearbhb instruction in mitigations
  KVM: arm64: Allow SMCCC_ARCH_WORKAROUND_3 to be discovered and migrated
  arm64: Mitigate spectre style branch history side channels
  arm64: proton-pack: Report Spectre-BHB vulnerabilities as part of Spectre-v2
  arm64: Add percpu vectors for EL1
  arm64: entry: Add macro for reading symbol addresses from the trampoline
  arm64: entry: Add vectors that have the bhb mitigation sequences
  arm64: entry: Add non-kpti __bp_harden_el1_vectors for mitigations
  arm64: entry: Allow the trampoline text to occupy multiple pages
  arm64: entry: Make the kpti trampoline's kpti sequence optional
  arm64: entry: Move trampoline macros out of ifdef'd section
  arm64: entry: Don't assume tramp_vectors is the start of the vectors
  arm64: entry: Allow tramp_alias to access symbols after the 4K boundary
  arm64: entry: Move the trampoline data page before the text page
  arm64: entry: Free up another register on kpti's tramp_exit path
  arm64: entry: Make the trampoline cleanup optional
  KVM: arm64: Allow indirect vectors to be used without SPECTRE_V3A
  arm64: spectre: Rename spectre_v4_patch_fw_mitigation_conduit
  arm64: entry.S: Add ventry overflow sanity checks

Pull ARM spectre fixes from Russell King:
 "ARM Spectre BHB mitigations.

  These patches add Spectre BHB migitations for the following Arm CPUs
  to the 32-bit ARM kernels:
   - Cortex A15
   - Cortex A57
   - Cortex A72
   - Cortex A73
   - Cortex A75
   - Brahma B15
  for CVE-2022-23960"

* tag 'for-linus-bhb' of git://git.armlinux.org.uk/~rmk/linux-arm:
  ARM: include unprivileged BPF status in Spectre V2 reporting
  ARM: Spectre-BHB workaround
  ARM: use LOADADDR() to get load address of sections
  ARM: early traps initialisation
  ARM: report Spectre v2 status through sysfs

On some boards, for routing CAN signals from controller to transceivers,
muxes might need to be set. This can be implemented using mux-states
property. Therefore, document the same in the respective bindings.
Signed-off-by: NAswath Govindraju <a-govindraju@ti.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NRob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20211216041012.16892-2-a-govindraju@ti.com

The recent addition pinctrl.yaml in commit c09acbc4 ("dt-bindings:
pinctrl: use pinctrl.yaml") resulted in some node name warnings:

Documentation/devicetree/bindings/mfd/cirrus,lochnagar.example.dt.yaml: \
 lochnagar-pinctrl: $nodename:0: 'lochnagar-pinctrl' does not match '^(pinctrl|pinmux)(@[0-9a-f]+)?$'
Documentation/devicetree/bindings/mfd/cirrus,madera.example.dt.yaml: \
 codec@1a: $nodename:0: 'codec@1a' does not match '^(pinctrl|pinmux)(@[0-9a-f]+)?$'
Documentation/devicetree/bindings/mfd/brcm,cru.example.dt.yaml: \
 pin-controller@1c0: $nodename:0: 'pin-controller@1c0' does not match '^(pinctrl|pinmux)(@[0-9a-f]+)?$'

Fix the node names to the preferred 'pinctrl'. For cirrus,madera,
nothing from pinctrl.yaml schema is used, so just drop the reference.

Fixes: c09acbc4 ("dt-bindings: pinctrl: use pinctrl.yaml")
Cc: Rafał Miłecki <rafal@milecki.pl>
Signed-off-by: NRob Herring <robh@kernel.org>
Acked-by: NCharles Keepax <ckeepax@opensource.cirrus.com>
Acked-by: NLee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20220303232350.2591143-1-robh@kernel.org

I'm leaving synaptics. Update my email address to my korg mail
address and add entries to .mailmap as well to map my work
addresses to korg mail address.
Signed-off-by: NJisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/ce7213bd-28ac-6580-466e-875e755fe0ae@synaptics.com'
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

This pull request updates the MAINTAINERS file for Broadcom SoCs, please
pull the following for 5.18:

- Kuldeep updates the Broadcom iProc entry to use the same up to date
Linux tree as the other Broadcom SoCs.

* tag 'arm-soc/for-5.18/maintainers' of https://github.com/Broadcom/stblinux:
  MAINTAINERS: Update git tree for Broadcom iProc SoCs

Link: https://lore.kernel.org/r/20220307194817.3754107-4-f.fainelli@gmail.comSigned-off-by: NArnd Bergmann <arnd@arndb.de>

The mitigations for Spectre-BHB are only applied when an exception
is taken, but when unprivileged BPF is enabled, userspace can
load BPF programs that can be used to exploit the problem.

When unprivileged BPF is enabled, report the vulnerable status via
the spectre_v2 sysfs file.
Signed-off-by: NRussell King (Oracle) <rmk+kernel@armlinux.org.uk>

This reverts commit 32568ae3.
Signed-off-by: NRobert Foss <robert.foss@linaro.org>
Reviewed-by: NChen-Yu Tsai <wenst@chromium.org>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NMatthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Revert DPI support from binding.

DPI support relies on the bus-type enum which does not yet support
Mipi DPI, since no v4l2_fwnode_bus_type has been defined for this
bus type.

When DPI for anx7625 was initially added, it assumed that
V4L2_FWNODE_BUS_TYPE_PARALLEL was the correct bus type for
representing DPI, which it is not.

In order to prevent adding this mis-usage to the ABI, let's revert
the support.
Signed-off-by: NRobert Foss <robert.foss@linaro.org>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Requesting quad mode for the FMC resulted in an error:

  &fmc {
         status = "okay";
 +       pinctrl-names = "default";
 +       pinctrl-0 = <&pinctrl_fwqspi_default>'

[    0.742963] aspeed-g6-pinctrl 1e6e2000.syscon:pinctrl: invalid function FWQSPID in map table


This is because the quad mode pins are a group of pins, not a function.

After applying this patch we can request the pins and the QSPI data
lines are muxed:

 # cat /sys/kernel/debug/pinctrl/1e6e2000.syscon\:pinctrl-aspeed-g6-pinctrl/pinmux-pins |grep 1e620000.spi
 pin 196 (AE12): device 1e620000.spi function FWSPID group FWQSPID
 pin 197 (AF12): device 1e620000.spi function FWSPID group FWQSPID
 pin 240 (Y1): device 1e620000.spi function FWSPID group FWQSPID
 pin 241 (Y2): device 1e620000.spi function FWSPID group FWQSPID
 pin 242 (Y3): device 1e620000.spi function FWSPID group FWQSPID
 pin 243 (Y4): device 1e620000.spi function FWSPID group FWQSPID

Fixes: f510f04c ("ARM: dts: aspeed: Add AST2600 pinmux nodes")
Signed-off-by: NJoel Stanley <joel@jms.id.au>
Reviewed-by: NAndrew Jeffery <andrew@aj.id.au>
Link: https://lore.kernel.org/r/20220304011010.974863-1-joel@jms.id.au
Link: https://lore.kernel.org/r/20220304011010.974863-1-joel@jms.id.au'
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Merge tag 'tegra-for-5.17-arm-dt-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into arm/fixes

ARM: tegra: Device tree fixes for v5.17

One more patch to fix up eDP panels on Nyan FHD models.

* tag 'tegra-for-5.17-arm-dt-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux:
  ARM: tegra: Move Nyan FHD panels to AUX bus
  ARM: tegra: Move panels to AUX bus

Link: https://lore.kernel.org/r/20220308084339.2199400-1-thierry.reding@gmail.comSigned-off-by: NArnd Bergmann <arnd@arndb.de>

max_seg_size is unsigned int and it can have a value up to 2^32
(for eg:-RZ_DMAC driver sets dma_set_max_seg_size as U32_MAX)
When this value is used in min_t() as an integer type, it becomes
-1 and the value of sgs becomes 0.

Fix this issue by replacing the 'int' data type with 'unsigned int'
in min_t().
Signed-off-by: NBiju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: NLad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20220307184843.9994-1-biju.das.jz@bp.renesas.comSigned-off-by: NMark Brown <broonie@kernel.org>

Commit 18107f8a ("arm64: Support execute-only permissions with
Enhanced PAN") re-introduced execute-only permissions when EPAN is
available. When EPAN is not available, arch_filter_pgprot() is supposed
to change a PAGE_EXECONLY permission into PAGE_READONLY_EXEC. However,
if BTI or MTE are present, such check does not detect the execute-only
pgprot in the presence of PTE_GP (BTI) or MT_NORMAL_TAGGED (MTE),
allowing the user to request PROT_EXEC with PROT_BTI or PROT_MTE.

Remove the arch_filter_pgprot() function, change the default VM_EXEC
permissions to PAGE_READONLY_EXEC and update the protection_map[] array
at core_initcall() if EPAN is detected.
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
Fixes: 18107f8a ("arm64: Support execute-only permissions with Enhanced PAN")
Cc: <stable@vger.kernel.org> # 5.13.x
Acked-by: NWill Deacon <will@kernel.org>
Reviewed-by: NVladimir Murzin <vladimir.murzin@arm.com>
Tested-by: NVladimir Murzin <vladimir.murzin@arm.com>

Compiler is not happy:

  warning: symbol 'gpio_sim_hog_config_item_ops' was not declared. Should it be static?

Fixes: cb8c474e ("gpio: sim: new testing module")
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NBartosz Golaszewski <brgl@bgdev.pl>

Pull x86 spectre fixes from Borislav Petkov:

 - Mitigate Spectre v2-type Branch History Buffer attacks on machines
   which support eIBRS, i.e., the hardware-assisted speculation
   restriction after it has been shown that such machines are vulnerable
   even with the hardware mitigation.

 - Do not use the default LFENCE-based Spectre v2 mitigation on AMD as
   it is insufficient to mitigate such attacks. Instead, switch to
   retpolines on all AMD by default.

 - Update the docs and add some warnings for the obviously vulnerable
   cmdline configurations.

* tag 'x86_bugs_for_v5.17' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/speculation: Warn about eIBRS + LFENCE + Unprivileged eBPF + SMT
  x86/speculation: Warn about Spectre v2 LFENCE mitigation
  x86/speculation: Update link to AMD speculation whitepaper
  x86/speculation: Use generic retpoline by default on AMD
  x86/speculation: Include unprivileged eBPF status in Spectre v2 mitigation reporting
  Documentation/hw-vuln: Update spectre doc
  x86/speculation: Add eIBRS + Retpoline options
  x86/speculation: Rename RETPOLINE_AMD to RETPOLINE_LFENCE

Use Krzysztof Kozlowski's @kernel.org account in maintainer entries.
Signed-off-by: NKrzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Link: https://lore.kernel.org/r/20220307172805.156760-1-krzysztof.kozlowski@canonical.com'
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Merge tag 'tegra-for-5.17-arm64-dt-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into arm/fixes

arm64: tegra: Device tree fixes for v5.17

This contains a single, last-minute fix to disable the display SMMU by
default because under some circumstances leaving it enabled by default
can cause SMMU faults on boot.

* tag 'tegra-for-5.17-arm64-dt-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux:
  arm64: tegra: Disable ISO SMMU for Tegra194

Link: https://lore.kernel.org/r/20220307182120.2169598-1-thierry.reding@gmail.comSigned-off-by: NArnd Bergmann <arnd@arndb.de>

Current git tree for Broadcom iProc SoCs is pretty outdated as it has
not updated for a long time. Fix the reference.
Signed-off-by: NKuldeep Singh <singh.kuldeep87k@gmail.com>

Pull MTD fix from Miquel Raynal:
 "As part of a previous changeset introducing support for the K3
  architecture, the OMAP_GPMC (a non visible symbol) got selected by the
  selection of MTD_NAND_OMAP2 instead of doing so from the architecture
  directly (like for the other users of these two drivers). Indeed, from
  a hardware perspective, the OMAP NAND controller needs the GPMC to
  work.

  This led to a robot error which got addressed in fix merge into -rc4.
  Unfortunately, the approach at this time still used "select" and lead
  to further build error reports (sparc64:allmodconfig).

  This time we switch to 'depends on' in order to prevent random
  misconfigurations. The different dependencies will however need a
  future cleanup"

* tag 'mtd/fixes-for-5.17-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux:
  mtd: rawnand: omap2: Actually prevent invalid configuration and build error