With KASAN_VMALLOC and NEED_PER_CPU_PAGE_FIRST_CHUNK the kernel crashes:

  Unable to handle kernel paging request at virtual address ffff7000028f2000
  ...
  swapper pgtable: 64k pages, 48-bit VAs, pgdp=0000000042440000
  [ffff7000028f2000] pgd=000000063e7c0003, p4d=000000063e7c0003, pud=000000063e7c0003, pmd=000000063e7b0003, pte=0000000000000000
  Internal error: Oops: 96000007 [#1] PREEMPT SMP
  Modules linked in:
  CPU: 0 PID: 0 Comm: swapper Not tainted 5.13.0-rc4-00003-gc6e6e28f3f30-dirty #62
  Hardware name: linux,dummy-virt (DT)
  pstate: 200000c5 (nzCv daIF -PAN -UAO -TCO BTYPE=--)
  pc : kasan_check_range+0x90/0x1a0
  lr : memcpy+0x88/0xf4
  sp : ffff80001378fe20
  ...
  Call trace:
   kasan_check_range+0x90/0x1a0
   pcpu_page_first_chunk+0x3f0/0x568
   setup_per_cpu_areas+0xb8/0x184
   start_kernel+0x8c/0x328

The vm area used in vm_area_register_early() has no kasan shadow memory,
Let's add a new kasan_populate_early_vm_area_shadow() function to
populate the vm area shadow memory to fix the issue.

[wangkefeng.wang@huawei.com: fix redefinition of 'kasan_populate_early_vm_area_shadow']
  Link: https://lkml.kernel.org/r/20211011123211.3936196-1-wangkefeng.wang@huawei.com

Link: https://lkml.kernel.org/r/20210910053354.26721-4-wangkefeng.wang@huawei.comSigned-off-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Acked-by: Marco Elver <elver@google.com>		[KASAN]
Acked-by: Andrey Konovalov <andreyknvl@gmail.com>	[KASAN]
Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Percpu embedded first chunk allocator is the firstly option, but it
could fails on ARM64, eg,

  percpu: max_distance=0x5fcfdc640000 too large for vmalloc space 0x781fefff0000
  percpu: max_distance=0x600000540000 too large for vmalloc space 0x7dffb7ff0000
  percpu: max_distance=0x5fff9adb0000 too large for vmalloc space 0x5dffb7ff0000

then we could get

  WARNING: CPU: 15 PID: 461 at vmalloc.c:3087 pcpu_get_vm_areas+0x488/0x838

and the system could not boot successfully.

Let's implement page mapping percpu first chunk allocator as a fallback
to the embedding allocator to increase the robustness of the system.

Link: https://lkml.kernel.org/r/20210910053354.26721-3-wangkefeng.wang@huawei.comSigned-off-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
Cc: Andrey Konovalov <andreyknvl@gmail.com>
Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Marco Elver <elver@google.com>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This reverts commit 001ce978.

This upstream commit broke AOSP (post Android 12 merge) build
on RB5. The device either silently crashes into USB crash mode
after android boot animation or we see a blank blue screen
with following dpu errors in dmesg:

[  T444] hw recovery is not complete for ctl:3
[  T444] [drm:dpu_encoder_phys_vid_prepare_for_kickoff:539] [dpu error]enc31 intf1 ctl 3 reset failure: -22
[  T444] [drm:dpu_encoder_phys_vid_wait_for_commit_done:513] [dpu error]vblank timeout
[  T444] [drm:dpu_kms_wait_for_commit_done:454] [dpu error]wait for commit done returned -110
[    C7] [drm:dpu_encoder_frame_done_timeout:2127] [dpu error]enc31 frame done timeout
[  T444] [drm:dpu_encoder_phys_vid_wait_for_commit_done:513] [dpu error]vblank timeout
[  T444] [drm:dpu_kms_wait_for_commit_done:454] [dpu error]wait for commit done returned -110

Fixes: 001ce978 ("arm64: dts: qcom: sm8250: remove bus clock from the mdss node for sm8250 target")
Signed-off-by: NAmit Pundir <amit.pundir@linaro.org>
Signed-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20211014135410.4136412-1-dmitry.baryshkov@linaro.org

Expose the maximum amount of useable memory from the arm64 JIT.
Signed-off-by: NLorenz Bauer <lmb@cloudflare.com>
Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
Link: https://lore.kernel.org/bpf/20211014142554.53120-3-lmb@cloudflare.com

Previously we falsely relied on the PHY driver to unconditionally
enable the internal RX delay. Since the following fix for the PHY
driver this is not the case anymore:

commit 7b005a17 ("net: phy: mscc: configure both RX and TX internal
delays for RGMII")

In order to enable the delay we need to set the connection type to
"rgmii-rxid". Without the RX delay the ethernet is not functional at
all.

Fixes: 8668d8b2 ("arm64: dts: Add the Kontron i.MX8M Mini SoMs and baseboards")
Cc: stable@vger.kernel.org
Signed-off-by: NFrieder Schrempf <frieder.schrempf@kontron.de>
Signed-off-by: NShawn Guo <shawnguo@kernel.org>

The MCP2515 can be used with an SPI clock of up to 10 MHz. Set the
limit accordingly to prevent any performance issues caused by the
really low clock speed of 100 kHz.

This removes the arbitrarily low limit on the SPI frequency, that was
caused by a typo in the original dts.

Without this change, receiving CAN messages on the board beyond a
certain bitrate will cause overrun errors (see 'ip -det -stat link show
can0').

With this fix, receiving messages on the bus works without any overrun
errors for bitrates up to 1 MBit.

Fixes: 8668d8b2 ("arm64: dts: Add the Kontron i.MX8M Mini SoMs and baseboards")
Cc: stable@vger.kernel.org
Signed-off-by: NFrieder Schrempf <frieder.schrempf@kontron.de>
Signed-off-by: NShawn Guo <shawnguo@kernel.org>

The regulator reg_rst_eth2 should keep the reset signal of the USB ethernet
adapter deasserted anytime. Fix the polarity and mark it as always-on.

Anyway, using the regulator is only a workaround for the missing support of
specifying a reset GPIO for USB devices in a generic way. As we don't
have a solution for this at the moment, at least fix the current
workaround.

Fixes: 8668d8b2 ("arm64: dts: Add the Kontron i.MX8M Mini SoMs and baseboards")
Cc: stable@vger.kernel.org
Signed-off-by: NFrieder Schrempf <frieder.schrempf@kontron.de>
Signed-off-by: NShawn Guo <shawnguo@kernel.org>

According to the datasheet the typical value for VDD_SNVS should be
800 mV, so let's make sure that this is within the range of the
regulator.

Fixes: 8668d8b2 ("arm64: dts: Add the Kontron i.MX8M Mini SoMs and baseboards")
Cc: stable@vger.kernel.org
Signed-off-by: NFrieder Schrempf <frieder.schrempf@kontron.de>
Signed-off-by: NShawn Guo <shawnguo@kernel.org>

It looks like the voltages for the SOC and DRAM supply weren't properly
validated before. The datasheet and uboot-imx code tells us that VDD_SOC
should be 800 mV in suspend and 850 mV in run mode. VDD_DRAM should be
950 mV for DDR clock frequencies of up to 1.5 GHz.

Let's fix these values to make sure the voltages are within the required
range.

Fixes: 8668d8b2 ("arm64: dts: Add the Kontron i.MX8M Mini SoMs and baseboards")
Cc: stable@vger.kernel.org
Signed-off-by: NFrieder Schrempf <frieder.schrempf@kontron.de>
Signed-off-by: NShawn Guo <shawnguo@kernel.org>

For non-4K PAGE_SIZE configs, the largest gigantic huge page size is
CONT_PMD_SHIFT order. On arm64 with 64K PAGE_SIZE, the gigantic page is
16G. Therefore, one should be able to specify 'hugetlb_cma=16G' on the
kernel command line so that one gigantic page can be allocated from CMA.
However, when adding such an option the following message is produced:

hugetlb_cma: cma area should be at least 8796093022208 MiB

This is because the calculation for non-4K gigantic page order is
incorrect in the arm64 specific routine arm64_hugetlb_cma_reserve().

Fixes: abb7962a ("arm64/hugetlb: Reserve CMA areas for gigantic pages on 16K and 64K configs")
Cc: <stable@vger.kernel.org> # 5.9.x
Signed-off-by: NMike Kravetz <mike.kravetz@oracle.com>
Reviewed-by: NAnshuman Khandual <anshuman.khandual@arm.com>
Link: https://lore.kernel.org/r/20211005202529.213812-1-mike.kravetz@oracle.comSigned-off-by: NCatalin Marinas <catalin.marinas@arm.com>

Compile-testing drivers that require access to a firmware layer
fails when that firmware symbol is unavailable. This happened
twice this week:

 - My proposed to change to rework the QCOM_SCM firmware symbol
   broke on ppc64 and others.

 - The cs_dsp firmware patch added device specific firmware loader
   into drivers/firmware, which broke on the same set of
   architectures.

We should probably do the same thing for other subsystems as well,
but fix this one first as this is a dependency for other patches
getting merged.
Reviewed-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Reviewed-by: NCharles Keepax <ckeepax@opensource.cirrus.com>
Acked-by: NWill Deacon <will@kernel.org>
Acked-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Cc: Mark Brown <broonie@kernel.org>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Charles Keepax <ckeepax@opensource.cirrus.com>
Cc: Simon Trimmer <simont@opensource.cirrus.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Reviewed-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

The simple-pm-bus driver is mandatory for CONFIG_OF based platforms to work
with fw_devlink. So, always compile it in for CONFIG_OF and delete the
config since it's no longer necessary.
Tested-by: NUlf Hansson <ulf.hansson@linaro.org>
Tested-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Tested-by: NDamien Le Moal <damien.lemoal@wdc.com>
Cc: Rob Herring <robh+dt@kernel.org>
Signed-off-by: NSaravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20210929000735.585237-3-saravanak@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

VM_SHARED mappings are currently forbidden in a memslot with MTE to
prevent two VMs racing to sanitise the same page. However, this check
is performed while holding current->mm's mmap_lock, but fails to release
it. Fix this by releasing the lock when needed.

Fixes: ea7fc1bb ("KVM: arm64: Introduce MTE VM feature")
Signed-off-by: NQuentin Perret <qperret@google.com>
Signed-off-by: NMarc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20211005122031.809857-1-qperret@google.com

Some of the refcount manipulation helpers used at EL2 are instrumented
to catch a corrupted state, but not all of them are treated equally. Let's
make things more consistent by instrumenting hyp_page_ref_dec_and_test()
as well.
Acked-by: NWill Deacon <will@kernel.org>
Suggested-by: NWill Deacon <will@kernel.org>
Signed-off-by: NQuentin Perret <qperret@google.com>
Signed-off-by: NMarc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20211005090155.734578-6-qperret@google.com

The KVM page-table library refcounts the pages of concatenated stage-2
PGDs individually. However, when running KVM in protected mode, the
host's stage-2 PGD is currently managed by EL2 as a single high-order
compound page, which can cause the refcount of the tail pages to reach 0
when they shouldn't, hence corrupting the page-table.

Fix this by introducing a new hyp_split_page() helper in the EL2 page
allocator (matching the kernel's split_page() function), and make use of
it from host_s2_zalloc_pages_exact().

Fixes: 1025c8c0 ("KVM: arm64: Wrap the host with a stage 2")
Acked-by: NWill Deacon <will@kernel.org>
Suggested-by: NWill Deacon <will@kernel.org>
Signed-off-by: NQuentin Perret <qperret@google.com>
Signed-off-by: NMarc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20211005090155.734578-5-qperret@google.com

Fix invalid M2_RST# gpio pinmux.

Fixes: ef484dfc ("arm64: dts: imx: Add i.mx8mm/imx8mn Gateworks gw7902 dts support")
Cc: stable@vger.kernel.org
Signed-off-by: NTim Harvey <tharvey@gateworks.com>
Signed-off-by: NShawn Guo <shawnguo@kernel.org>

On the LS1028A this instance of the eSDHC controller is intended for
either an eMMC or eSDIO card. It doesn't provide a card detect pin and
its IO voltage is fixed at 1.8V.

Remove the bogus broken-cd property, instead add the non-removable
property. Fix the voltage-ranges property and set it to 1.8V only.

Fixes: 491d3a3f ("arm64: dts: ls1028a: Add esdhc node in dts")
Signed-off-by: NMichael Walle <michael@walle.cc>
Signed-off-by: NShawn Guo <shawnguo@kernel.org>

The buck2 output of the PMIC is the VDD core voltage of the cpu.
Switching off this will poweroff the CPU. Add the 'regulator-always-on'
property to avoid this.

Fixes: 8668d8b2 ("arm64: dts: Add the Kontron i.MX8M Mini SoMs and baseboards")
Signed-off-by: NHeiko Thiery <heiko.thiery@gmail.com>
Reviewed-by: NFrieder Schrempf <frieder.schrempf@kontron.de>
Signed-off-by: NShawn Guo <shawnguo@kernel.org>

Before commit 0e30f472 ("mtd: spi-nor: add support for DTR protocol"),
for all PP command, it only support 1-1-1 mode, no matter the tx setting
in dts. But after the upper commit, the logic change. It will choose
the best mode(fastest mode) which flash device and spi-nor host controller
both support.

qspi and fspi host controller do not support read 1-4-4 mode. so need to
set the tx to 1, let the common code finally select read 1-1-4 mode.
Signed-off-by: NHaibo Chen <haibo.chen@nxp.com>
Fixes: 0e30f472 ("mtd: spi-nor: add support for DTR protocol")
Signed-off-by: NShawn Guo <shawnguo@kernel.org>

Commit 078fb7aa ("arm: dts: vexpress: Fix addressing issues with
'motherboard-bus' nodes") broke booting on a couple of 32-bit VExpress
boards. The problem is #address-cells size changed, but interrupt-map
was not updated. This results in the timer interrupt (and all the
other motherboard interrupts) not getting mapped.

As the 'interrupt-map' properties are all just duplicates across boards,
just move them into vexpress-v2m.dtsi and vexpress-v2m-rs1.dtsi.
Strictly speaking, 'interrupt-map' is dependent on the parent
interrupt controller, but it's not likely we'll ever have a different
parent than GICv2 on these old platforms. If there was one,
'interrupt-map' can still be overridden.

Link: https://lore.kernel.org/r/20210924214221.1877686-1-robh@kernel.org
Fixes: 078fb7aa ("arm: dts: vexpress: Fix addressing issues with 'motherboard-bus' nodes")
Cc: Guillaume Tucker <guillaume.tucker@collabora.com>
Cc: Liviu Dudau <liviu.dudau@arm.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: linux-arm-kernel@lists.infradead.org
Reported-by: NReported-by: "kernelci.org bot" <bot@kernelci.org>
Signed-off-by: NRob Herring <robh@kernel.org>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

It adds the missing a2noc clocks required for QoS registers programming
per downstream kernel[1].

[1] https://source.codeaurora.org/quic/la/kernel/msm-4.4/tree/arch/arm/boot/dts/qcom/sdm660-bus.dtsi?h=LA.UM.8.2.r1-04800-sdm660.0#n43

Fixes: 045547a0 ("arm64: dts: qcom: sdm630: Add interconnect provider nodes")
Signed-off-by: NShawn Guo <shawn.guo@linaro.org>
Acked-by: NGeorgi Djakov <djakov@kernel.org>
Reviewed-by: NAngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
Signed-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20210824043435.23190-4-shawn.guo@linaro.org

Enable powerkey and resin nodes to let the board handle POWER and
Volume- keys properly.
Signed-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Tested-by: NAmit Pundir <amit.pundir@linaro.org>
Signed-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20210916151341.1797512-3-dmitry.baryshkov@linaro.org

Specify recovery and bootloader magic values to be programmed by the
qcom-pon driver. This allows the bootloader to handle
reboot-to-bootloader functionality.
Signed-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Tested-by: NAmit Pundir <amit.pundir@linaro.org>
Signed-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20210916151341.1797512-2-dmitry.baryshkov@linaro.org

Change pm8150 to use the qcom,pm8998-pon compatible string for the pon
in order to pass reboot mode properly.

Fixes: 5101f22a ("arm64: dts: qcom: pm8150: Add base dts file")
Signed-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Tested-by: NAmit Pundir <amit.pundir@linaro.org>
Signed-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20210916151341.1797512-1-dmitry.baryshkov@linaro.org

This reverts commit 437b38c5.

The memory semantics added in commit 437b38c5 causes SystemMemory
Operation region, whose address range is not described in the EFI memory
map to be mapped as NormalNC memory on arm64 platforms (through
acpi_os_map_memory() in acpi_ex_system_memory_space_handler()).

This triggers the following abort on an ARM64 Ampere eMAG machine,
because presumably the physical address range area backing the Opregion
does not support NormalNC memory attributes driven on the bus.

 Internal error: synchronous external abort: 96000410 [#1] SMP
 Modules linked in:
 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.14.0+ #462
 Hardware name: MiTAC RAPTOR EV-883832-X3-0001/RAPTOR, BIOS 0.14 02/22/2019
 pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[...snip...]
 Call trace:
  acpi_ex_system_memory_space_handler+0x26c/0x2c8
  acpi_ev_address_space_dispatch+0x228/0x2c4
  acpi_ex_access_region+0x114/0x268
  acpi_ex_field_datum_io+0x128/0x1b8
  acpi_ex_extract_from_field+0x14c/0x2ac
  acpi_ex_read_data_from_field+0x190/0x1b8
  acpi_ex_resolve_node_to_value+0x1ec/0x288
  acpi_ex_resolve_to_value+0x250/0x274
  acpi_ds_evaluate_name_path+0xac/0x124
  acpi_ds_exec_end_op+0x90/0x410
  acpi_ps_parse_loop+0x4ac/0x5d8
  acpi_ps_parse_aml+0xe0/0x2c8
  acpi_ps_execute_method+0x19c/0x1ac
  acpi_ns_evaluate+0x1f8/0x26c
  acpi_ns_init_one_device+0x104/0x140
  acpi_ns_walk_namespace+0x158/0x1d0
  acpi_ns_initialize_devices+0x194/0x218
  acpi_initialize_objects+0x48/0x50
  acpi_init+0xe0/0x498

If the Opregion address range is not present in the EFI memory map there
is no way for us to determine the memory attributes to use to map it -
defaulting to NormalNC does not work (and it is not correct on a memory
region that may have read side-effects) and therefore commit
437b38c5 should be reverted, which means reverting back to the
original behavior whereby address ranges that are mapped using
acpi_os_map_memory() default to the safe devicenGnRnE attributes on
ARM64 if the mapped address range is not defined in the EFI memory map.

Fixes: 437b38c5 ("ACPI: Add memory semantics to acpi_os_map_memory()")
Signed-off-by: NJia He <justin.he@arm.com>
Acked-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

A noted side-effect of commit 0c6c2d36 ("arm64: Generate cpucaps.h")
is that cpucaps are now sorted, changing the enumeration order. This
assumed no dependencies between cpucaps, which turned out not to be true
in one case. UNMAP_KERNEL_AT_EL0 currently needs to be processed after
WORKAROUND_CAVIUM_27456. ThunderX systems are incompatible with KPTI, so
unmap_kernel_at_el0() bails if WORKAROUND_CAVIUM_27456 is set. But because
of the sorting, WORKAROUND_CAVIUM_27456 will not yet have been considered
when unmap_kernel_at_el0() checks for it, so the kernel tries to
run w/ KPTI - and quickly falls over.

Because all ThunderX implementations have homogeneous CPUs, we can remove
this dependency by just checking the current CPU for the erratum.

Fixes: 0c6c2d36 ("arm64: Generate cpucaps.h")
Cc: <stable@vger.kernel.org> # 5.13.x
Signed-off-by: Ndann frazier <dann.frazier@canonical.com>
Suggested-by: NSuzuki K Poulose <suzuki.poulose@arm.com>
Reviewed-by: NSuzuki K Poulose <suzuki.poulose@arm.com>
Reviewed-by: NMark Brown <broonie@kernel.org>
Acked-by: NMarc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20210923145002.3394558-1-dann.frazier@canonical.comSigned-off-by: NCatalin Marinas <catalin.marinas@arm.com>

Invoke rseq_handle_notify_resume() from tracehook_notify_resume() now
that the two function are always called back-to-back by architectures
that have rseq.  The rseq helper is stubbed out for architectures that
don't support rseq, i.e. this is a nop across the board.

Note, tracehook_notify_resume() is horribly named and arguably does not
belong in tracehook.h as literally every line of code in it has nothing
to do with tracing.  But, that's been true since commit a42c6ded
("move key_repace_session_keyring() into tracehook_notify_resume()")
first usurped tracehook_notify_resume() back in 2012.  Punt cleaning that
mess up to future patches.

No functional change intended.
Acked-by: NMathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: NSean Christopherson <seanjc@google.com>
Message-Id: <20210901203030.1292304-3-seanjc@google.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

As with strlen(), the patches importing the updated str{n}cmp()
implementations were originally developed and tested before the
advent of CONFIG_KASAN_HW_TAGS, and have subsequently revealed
not to be MTE-safe. Since in-kernel MTE is still a rather niche
case, let it temporarily fall back to the generic C versions for
correctness until we can figure out the best fix.

Fixes: 758602c0 ("arm64: Import latest version of Cortex Strings' strcmp")
Fixes: 020b199b ("arm64: Import latest version of Cortex Strings' strncmp")
Cc: <stable@vger.kernel.org> # 5.14.x
Reported-by: NBranislav Rankov <branislav.rankov@arm.com>
Signed-off-by: NRobin Murphy <robin.murphy@arm.com>
Acked-by: NMark Rutland <mark.rutland@arm.com>
Link: https://lore.kernel.org/r/34dc4d12eec0adae49b0ac927df642ed10089d40.1631890770.git.robin.murphy@arm.comSigned-off-by: NCatalin Marinas <catalin.marinas@arm.com>

This lets us avoid doing unnecessary work on hardware that does not
support MTE, and will allow us to freely use MTE instructions in the
code called by mte_thread_switch().

Since this would mean that we do a redundant check in
mte_check_tfsr_el1(), remove it and add two checks now required in its
callers. This also avoids an unnecessary DSB+ISB sequence on the syscall
exit path for hardware not supporting MTE.

Fixes: 65812c69 ("arm64: mte: Enable async tag check fault")
Cc: <stable@vger.kernel.org> # 5.13.x
Signed-off-by: NPeter Collingbourne <pcc@google.com>
Link: https://linux-review.googlesource.com/id/I02fd000d1ef2c86c7d2952a7f099b254ec227a5d
Link: https://lore.kernel.org/r/20210915190336.398390-1-pcc@google.com
[catalin.marinas@arm.com: adjust the commit log slightly]
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>

Russell reported that since 5.13, KVM's probing of the PMU has
started to fail on his HW. As it turns out, there is an implicit
ordering dependency between the architectural PMU probing code and
and KVM's own probing. If, due to probe ordering reasons, KVM probes
before the PMU driver, it will fail to detect the PMU and prevent it
from being advertised to guests as well as the VMM.

Obviously, this is one probing too many, and we should be able to
deal with any ordering.

Add a callback from the PMU code into KVM to advertise the registration
of a host CPU PMU, allowing for any probing order.

Fixes: 5421db1b ("KVM: arm64: Divorce the perf code from oprofile helpers")
Reported-by: N"Russell King (Oracle)" <linux@armlinux.org.uk>
Tested-by: NRussell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: NMarc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/YUYRKVflRtUytzy5@shell.armlinux.org.uk
Cc: stable@vger.kernel.org

Add FORCE so that if_changed can detect the command line change.

We'll otherwise see a compilation warning since commit e1f86d7b
("kbuild: warn if FORCE is missing for if_changed(_dep,_rule) and
filechk").

arch/arm64/kvm/hyp/nvhe/Makefile:58: FORCE prerequisite is missing

Cc: David Brazdil <dbrazdil@google.com>
Cc: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: NZenghui Yu <yuzenghui@huawei.com>
Signed-off-by: NMarc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20210907052137.1059-1-yuzenghui@huawei.com

This should be the dai for display port. Without this set properly we
fail to get audio routed through external displays on trogdor. It looks
like we picked up v4[1] of this patch when there was a v7[2]. The v7
patch still had the wrong sound-dai but at least we can fix all this up
and audio works.

Cc: Srinivasa Rao Mandadapu <srivasam@qti.qualcomm.com>
Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Cc: Douglas Anderson <dianders@chromium.org>
Fixes: b22d313e ("arm64: dts: qcom: sc7180-trogdor: Add lpass dai link for HDMI")
Link: https://lore.kernel.org/r/20210721080549.28822-3-srivasam@qti.qualcomm.com [1]
Link: https://lore.kernel.org/r/20210726120910.20335-3-srivasam@codeaurora.org [2]
Signed-off-by: NStephen Boyd <swboyd@chromium.org>
Reviewed-by: NDouglas Anderson <dianders@chromium.org>
Signed-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20210811224141.1110495-1-swboyd@chromium.org

Upstream commit 2e01e0c2 ("arm64: dts: qcom: sdm850-yoga:
Enable IPA") shuffled reserved memory regions in sdm845.dtsi
to make firmware loading succeed and enable the ipa device on
sdm845-yoga but it broke the other common users of those
memory regions like Xiaomi Pocophone F1.

So this patch effectively revert those upstream commit changes
and move all the relevant changes to sdm850-lenovo-yoga-c630.dts
instead.

Fixes: 2e01e0c2 ("arm64: dts: qcom: sdm850-yoga: Enable IPA")
Signed-off-by: NAmit Pundir <amit.pundir@linaro.org>
Tested-by: NSteev Klimaszewski <steev@kali.org>
Tested-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20210916200554.2434439-1-amit.pundir@linaro.org

The 'motherboard-bus' node in Arm Ltd boards fails schema checks as
'simple-bus' child nodes must have a unit-address. The 'ranges' handling is
also wrong (or at least strange) as the mapping of SMC chip selects should
be in the 'arm,vexpress,v2m-p1' node rather than a generic 'simple-bus'
node. Either there's 1 too many levels of 'simple-bus' nodes or 'ranges'
should be moved down a level. The latter change is more simple, so let's do
that. As the 'ranges' value doesn't vary for a given motherboard instance,
we can move 'ranges' into the motherboard dtsi files.

Link: https://lore.kernel.org/r/20210819184239.1192395-6-robh@kernel.org
Cc: Andre Przywara <andre.przywara@arm.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NRob Herring <robh@kernel.org>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

__stack_chk_guard is setup once while init stage and never changed
after that.

Although the modification of this variable at runtime will usually
cause the kernel to crash (so does the attacker), it should be marked
as __ro_after_init, and it should not affect performance if it is
placed in the ro_after_init section.
Signed-off-by: NDan Li <ashimida@linux.alibaba.com>
Acked-by: NMark Rutland <mark.rutland@arm.com>
Link: https://lore.kernel.org/r/1631612642-102881-1-git-send-email-ashimida@linux.alibaba.comSigned-off-by: NCatalin Marinas <catalin.marinas@arm.com>

Remove all but the first include of linux/sched.h from process.c
Reported-by: NZeal Robot <zealci@zte.com.cn>
Signed-off-by: NLv Ruyi <lv.ruyi@zte.com.cn>
Acked-by: NMark Rutland <mark.rutland@arm.com>
Link: https://lore.kernel.org/r/20210902011126.29828-1-lv.ruyi@zte.com.cnSigned-off-by: NCatalin Marinas <catalin.marinas@arm.com>

When we need a buffer for SVE register state we call sve_alloc() to make
sure that one is there. In order to avoid repeated allocations and frees
we keep the buffer around unless we change vector length and just memset()
it to ensure a clean register state. The function that deals with this
takes the task to operate on as an argument, however in the case where we
do a memset() we initialise using the SVE state size for the current task
rather than the task passed as an argument.

This is only an issue in the case where we are setting the register state
for a task via ptrace and the task being configured has a different vector
length to the task tracing it. In the case where the buffer is larger in
the traced process we will leak old state from the traced process to
itself, in the case where the buffer is smaller in the traced process we
will overflow the buffer and corrupt memory.

Fixes: bc0ee476 ("arm64/sve: Core task context handling")
Cc: <stable@vger.kernel.org> # 4.15.x
Signed-off-by: NMark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20210909165356.10675-1-broonie@kernel.orgSigned-off-by: NCatalin Marinas <catalin.marinas@arm.com>

Drop the '#interrupt-cells' property in the motherboard node which has no
effect as the node is neither an interrupt-controller or interrupt-map
(that's in the parent node).

Drop 'model' as it is not used by software nor documented.

Drop 'arm,v2m-memory-map' as it is not used by software. The purpose was
to describe which memory map, but that's all described by the DT
already.

Link: https://lore.kernel.org/r/20210819184239.1192395-4-robh@kernel.org
Cc: Andre Przywara <andre.przywara@arm.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NRob Herring <robh@kernel.org>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

The arm,mhu bindings and driver do not define interrupt-names, so drop
the property to fix warnings:

  arch/arm64/boot/dts/arm/juno-r2.dt.yaml: mhu@2b1f0000: 'interrupt-names' does not match any of the regexes: 'pinctrl-[0-9]+'

Link: https://lore.kernel.org/r/20210820081733.83976-3-krzysztof.kozlowski@canonical.comAcked-by: NLiviu Dudau <liviu.dudau@arm.com>
Signed-off-by: NKrzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Align the watchdog and mmc device node names with the schema to fix
warnings like:

  mmci@50000: $nodename:0: 'mmci@50000' does not match '^mmc(@.*)?$'
  wdt@f0000: $nodename:0: 'wdt@f0000' does not match '^watchdog(@.*|-[0-9a-f])?$'

Link: https://lore.kernel.org/r/20210820081733.83976-1-krzysztof.kozlowski@canonical.comAcked-by: NLiviu Dudau <liviu.dudau@arm.com>
Signed-off-by: NKrzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>