Using shifts directly is error-prone and can cause inadvertent sign
extensions or build problems with older versions of binutils.
Consistent use of the _BITUL() macro makes these problems disappear.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Open-coding the pointer-auth HWCAPs is a mess and can be avoided by
reusing the multi-cap logic from the CPU errata framework.
Move the multi_entry_cap_matches code to cpufeature.h and reuse it for
the pointer auth HWCAPs.
Reviewed-by: Suzuki Poulose <suzuki.poulose@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
We can easily avoid defining the two meta-capabilities for the address
and generic keys, so remove them and instead just check both of the
architected and impdef capabilities when determining the level of system
support.
Reviewed-by: Suzuki Poulose <suzuki.poulose@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
We don't need to get at the per-thread keys from assembly at all, so
they can live alongside the rest of the per-thread register state in
thread_struct instead of thread_info.
This will also allow straighforward whitelisting of the keys for
hardened usercopy should we expose them via a ptrace request later on.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Add an arm64-specific prctl to allow a thread to reinitialize its
pointer authentication keys to random values. This can be useful when
exec() is not used for starting new processes, to ensure that different
processes still have different keys.
Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
When the kernel is unwinding userspace callchains, we can't expect that
the userspace consumer of these callchains has the data necessary to
strip the PAC from the stored LR.
This patch has the kernel strip the PAC from user stackframes when the
in-kernel unwinder is used. This only affects the LR value, and not the
FP.
This only affects the in-kernel unwinder. When userspace performs
unwinding, it is up to userspace to strip PACs as necessary (which can
be determined from DWARF information).
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Ramana Radhakrishnan <ramana.radhakrishnan@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
When pointer authentication is in use, data/instruction pointers have a
number of PAC bits inserted into them. The number and position of these
bits depends on the configured TCR_ELx.TxSZ and whether tagging is
enabled. ARMv8.3 allows tagging to differ for instruction and data
pointers.
For userspace debuggers to unwind the stack and/or to follow pointer
chains, they need to be able to remove the PAC bits before attempting to
use a pointer.
This patch adds a new structure with masks describing the location of
the PAC bits in userspace instruction and data pointers (i.e. those
addressable via TTBR0), which userspace can query via PTRACE_GETREGSET.
By clearing these bits from pointers (and replacing them with the value
of bit 55), userspace can acquire the PAC-less versions.
This new regset is exposed when the kernel is built with (user) pointer
authentication support, and the address authentication feature is
enabled. Otherwise, the regset is hidden.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Ramana Radhakrishnan <ramana.radhakrishnan@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
[will: Fix to use vabits_user instead of VA_BITS and rename macro]
Signed-off-by: Will Deacon <will.deacon@arm.com>
This patch adds basic support for pointer authentication, allowing
userspace to make use of APIAKey, APIBKey, APDAKey, APDBKey, and
APGAKey. The kernel maintains key values for each process (shared by all
threads within), which are initialised to random values at exec() time.
The ID_AA64ISAR1_EL1.{APA,API,GPA,GPI} fields are exposed to userspace,
to describe that pointer authentication instructions are available and
that the kernel is managing the keys. Two new hwcaps are added for the
same reason: PACA (for address authentication) and PACG (for generic
authentication).
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com>
Tested-by: Adam Wallis <awallis@codeaurora.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Ramana Radhakrishnan <ramana.radhakrishnan@arm.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
[will: Fix sizeof() usage and unroll address key initialisation]
Signed-off-by: Will Deacon <will.deacon@arm.com>
So that we can dynamically handle the presence of pointer authentication
functionality, wire up probing code in cpufeature.c.
From ARMv8.3 onwards, ID_AA64ISAR1 is no longer entirely RES0, and now
has four fields describing the presence of pointer authentication
functionality:
* APA - address authentication present, using an architected algorithm
* API - address authentication present, using an IMP DEF algorithm
* GPA - generic authentication present, using an architected algorithm
* GPI - generic authentication present, using an IMP DEF algorithm
This patch checks for both address and generic authentication,
separately. It is assumed that if all CPUs support an IMP DEF algorithm,
the same algorithm is used across all CPUs.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
To allow EL0 (and/or EL1) to use pointer authentication functionality,
we must ensure that pointer authentication instructions and accesses to
pointer authentication keys are not trapped to EL2.
This patch ensures that HCR_EL2 is configured appropriately when the
kernel is booted at EL2. For non-VHE kernels we set HCR_EL2.{API,APK},
ensuring that EL1 can access keys and permit EL0 use of instructions.
For VHE kernels host EL0 (TGE && E2H) is unaffected by these settings,
and it doesn't matter how we configure HCR_EL2.{API,APK}, so we don't
bother setting them.
This does not enable support for KVM guests, since KVM manages HCR_EL2
itself when running VMs.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com>
Acked-by: Christoffer Dall <christoffer.dall@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: kvmarm@lists.cs.columbia.edu
Signed-off-by: Will Deacon <will.deacon@arm.com>
In subsequent patches we're going to expose ptrauth to the host kernel
and userspace, but things are a bit trickier for guest kernels. For the
time being, let's hide ptrauth from KVM guests.
Regardless of how well-behaved the guest kernel is, guest userspace
could attempt to use ptrauth instructions, triggering a trap to EL2,
resulting in noise from kvm_handle_unknown_ec(). So let's write up a
handler for the PAC trap, which silently injects an UNDEF into the
guest, as if the feature were really missing.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com>
Reviewed-by: Andrew Jones <drjones@redhat.com>
Reviewed-by: Christoffer Dall <christoffer.dall@arm.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: kvmarm@lists.cs.columbia.edu
Signed-off-by: Will Deacon <will.deacon@arm.com>
In KVM we define the configuration of HCR_EL2 for a VHE HOST in
HCR_HOST_VHE_FLAGS, but we don't have a similar definition for the
non-VHE host flags, and open-code HCR_RW. Further, in head.S we
open-code the flags for VHE and non-VHE configurations.
In future, we're going to want to configure more flags for the host, so
lets add a HCR_HOST_NVHE_FLAGS defintion, and consistently use both
HCR_HOST_VHE_FLAGS and HCR_HOST_NVHE_FLAGS in the kvm code and head.S.
We now use mov_q to generate the HCR_EL2 value, as we use when
configuring other registers in head.S.
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com>
Reviewed-by: Christoffer Dall <christoffer.dall@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: kvmarm@lists.cs.columbia.edu
Signed-off-by: Will Deacon <will.deacon@arm.com>
The ARMv8.3 pointer authentication extension adds:
* New fields in ID_AA64ISAR1 to report the presence of pointer
authentication functionality.
* New control bits in SCTLR_ELx to enable this functionality.
* New system registers to hold the keys necessary for this
functionality.
* A new ESR_ELx.EC code used when the new instructions are affected by
configurable traps
This patch adds the relevant definitions to <asm/sysreg.h> and
<asm/esr.h> for these, to be used by subsequent patches.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
To make it clear which exceptions can't be taken to EL1 or EL2, add
comments next to the ESR_ELx_EC_* macro definitions.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Although the upper 32 bits of the PMEVTYPER<n>_EL0 registers are RES0,
we should treat the EXCLUDE_EL* bit definitions as unsigned so that we
avoid accidentally sign-extending the privilege filtering bit (bit 31)
into the upper half of the register.
Signed-off-by: Will Deacon <will.deacon@arm.com>
While the CSV3 field of the ID_AA64_PFR0 CPU ID register can be checked
to see if a CPU is susceptible to Meltdown and therefore requires kpti
to be enabled, existing CPUs do not implement this field.
We therefore whitelist all unaffected Cortex-A CPUs that do not implement
the CSV3 field.
Signed-off-by: Will Deacon <will.deacon@arm.com>
To some degree, most known AArch64 micro-architectures appear to be
able to issue ALU instructions in parellel to SIMD instructions
without affecting the SIMD throughput. This means we can use the ALU
to process a fifth ChaCha block while the SIMD is processing four
blocks in parallel.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Update the 4-way NEON ChaCha routine so it can handle input of any
length >64 bytes in its entirety, rather than having to call into
the 1-way routine and/or memcpy()s via temp buffers to handle the
tail of a ChaCha invocation that is not a multiple of 256 bytes.
On inputs that are a multiple of 256 bytes (and thus in tcrypt
benchmarks), performance drops by around 1% on Cortex-A57, while
performance for inputs drawn randomly from the range [64, 1024)
increases by around 30%.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Now that the ARM64 NEON implementation of ChaCha20 and XChaCha20 has
been refactored to support varying the number of rounds, add support for
XChaCha12. This is identical to XChaCha20 except for the number of
rounds, which is 12 instead of 20. This can be used by Adiantum.
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
In preparation for adding XChaCha12 support, rename/refactor the ARM64
NEON implementation of ChaCha20 to support different numbers of rounds.
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Add an XChaCha20 implementation that is hooked up to the ARM64 NEON
implementation of ChaCha20. This can be used by Adiantum.
A NEON implementation of single-block HChaCha20 is also added so that
XChaCha20 can use it rather than the generic implementation. This
required refactoring the ChaCha20 permutation into its own function.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Add an ARM64 NEON implementation of NHPoly1305, an ε-almost-∆-universal
hash function used in the Adiantum encryption mode. For now, only the
NH portion is actually NEON-accelerated; the Poly1305 part is less
performance-critical so is just implemented in C.
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> # big-endian
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Commit e8342cc795 ("enable CAAM crypto engine on QorIQ DPAA2 SoCs")
enabled CRYPTO_DEV_FSL_DPAA2_CAAM, which depends on FSL_MC_DPIO,
which is not set. Enable FSL_MC_BUS, and build FSL_MC_DPIO and
CRYPTO_DEV_FSL_DPAA2_CAAM as modules.
Signed-off-by: Marc Gonzalez <marc.w.gonzalez@free.fr>
[olof: refreshed due to churn]
Signed-off-by: Olof Johansson <olof@lixom.net>
Commit e78d57b2f8 ("pinctrl: mediatek: add pinctrl-moore that
implements the generic pinctrl dt-bindings") made PINCTRL_MT7622
depend on PINCTRL_MTK_MOORE, so it fell off in the refresh.
Add MTK_MOORE, which automatically enables MT7622.
Signed-off-by: Marc Gonzalez <marc.w.gonzalez@free.fr>
[olof: refresh and minor commit message reword]
Signed-off-by: Olof Johansson <olof@lixom.net>
Run the platform defconfig through kbuild, and handle the trivial case
where options merely move around.
Signed-off-by: Marc Gonzalez <marc.w.gonzalez@free.fr>
[olof: refreshed due to some recent churn]
Signed-off-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Olof Johansson <olof@lixom.net>
rockpro64 regulator fixes that cause stability issues
* tag 'v4.20-rockchip-dts64fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip:
arm64: dts: rockchip: fix rk3399-rockpro64 regulator gpios
Signed-off-by: Olof Johansson <olof@lixom.net>
Allwinner H3/H5 changes for 4.21
Our usual pull request with the changes shared between the H3 and H5 SoCs.
The major changes for this release are:
- Addition of the video engine for the H5
- H3 Camera support
- New board: Emlid Neutis N5, Mapleboard MP130
* tag 'sunxi-h3-h5-for-4.21' of https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux:
arm64: dts: allwinner: h5: Add Video Engine node
ARM/arm64: dts: allwinner: Move H3/H5 syscon label over to soc-specific nodes
arm64: dts: allwinner: h5: Add system-control node with SRAM C1
ARM: dts: sun8i: h3: Fix the system-control register range
ARM: dts: sun8i: Add the H3/H5 CSI controller
ARM: dts: sun8i-h3: Add dts for the Mapleboard MP130
arm64: dts: allwinner: new board - Emlid Neutis N5
dt-bindings: vendor-prefix: new vendor - Emlid
ARM: dts: sun8i-h3: add sy8106a to orange pi plus
Signed-off-by: Olof Johansson <olof@lixom.net>
Renesas ARM Based SoC Updates for v4.21
* pm-rmobile driver
- Move to drivers/soc/renesas/
- Clean up struct rmobile_pm_domain
* Renesas SoC Kconfig Symbols
- Move symbols for ARM and SoCs to drivers/soc/renesas/
- Hide ARCH_RZN1 to improve consistency
* SH-Mobile AG5 (sh73a0) SoC: Remove obsolete inclusion of <asm/smp_twd.h>
* Restrict TWD and SCU to Renesas ARM based SoCs where they are present
* Enable GPIOLIB on Renesas arm64 based SoCs to allow GPIO driver selection
* tag 'renesas-soc-for-v4.21' of https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas:
ARM: shmobile: R-Mobile: Move pm-rmobile to drivers/soc/renesas/
ARM: shmobile: R-Mobile: Clean up struct rmobile_pm_domain
ARM: shmobile: Move SoC Kconfig symbols to drivers/soc/renesas/
arm64: renesas: Move SoC Kconfig symbols to drivers/soc/renesas/
ARM: shmobile: Hide ARCH_RZN1 to improve consistency
ARM: shmobile: sh73a0: Remove obsolete inclusion of <asm/smp_twd.h>
ARM: shmobile: Restrict TWD support to SoCs that have it
ARM: shmobile: Restrict SCU support to SoCs that have it
arm64: renesas: Enable GPIOLIB to allow GPIO driver selection
Signed-off-by: Olof Johansson <olof@lixom.net>
Allwinner arm64 defconfig for 4.21
A bunch of patches to improve the coverage of Allwinner drivers in the
arm64 defconfig, mostly targeted at adding display drivers support.
* tag 'sunxi-config64-for-4.21' of https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux:
arm64: defconfig: Enable PWM_SUN4I
arm64: defconfig: Enable DRM_SUN8I_DW_HDMI
arm64: defconfig: Enable DRM_SUN8I_MIXER
arm64: defconfig: Enable MFD_AXP20X_I2C
Signed-off-by: Olof Johansson <olof@lixom.net>
Support for the onboard LEDs of the 2 96boards (ficus, rock960),
hdmi output for rockpro64, vpu node on rk3399 and adding the
always on 32kHz clock on rk3399-Gru to get a more complete clock
tree.
* tag 'v4.21-rockchip-dts64-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip:
arm64: dts: rockchip: Add on-board LED support on rk3399-rock960
arm64: dts: rockchip: Add on-board LED support on rk3399-ficus
arm64: dts: rockchip: enable hdmi output on rk3399-rockpro64
arm64: dts: rockchip: add VPU device node for RK3399
arm64: dts: rockchip: Add 32k clk on rk3399-gru
Signed-off-by: Olof Johansson <olof@lixom.net>
UniPhier ARM SoC DT updates for v4.21
- Add bindings for all SoCs/boards of UniPhier platform
- Move binding docs to socionext directory
- Add all CPUs in cooling maps
- Add MIO DMAC nodes
* tag 'uniphier-dt-v4.21' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-uniphier:
ARM: dts: uniphier: add MIO DMAC nodes
arm64: dts: uniphier: Add all CPUs in cooling maps
ARM: dts: uniphier: Add all CPUs in cooling maps
dt-bindings: uniphier: move cache-uniphier.txt to vendor directory
dt-bindings: uniphier: add bindings for UniPhier SoC family
Signed-off-by: Olof Johansson <olof@lixom.net>
Freescale arm64 device tree update for 4.21:
- Add device tree for LS1028A SoC and NXP FRWY & QDS boards support
based on this SoC.
- Add device tree for LX2160A SoC and NXP QDS & RDB boards support
based on this SoC.
- Add qdma devices for LS1043A and LS1046A SoC.
- Disable PCIe device by default in SoC device tree and let board level
device tree to enable as needed.
- Drop compatible string "snps,dw-pcie" from LayerScape PCIe devices to
avoid incorrect matching.
- Move fsl-mc device as a child node of soc node, and add missing
dma-ranges property for LS1088A SoC.
- Update LayerScape SoCs' cooling maps to include all devices affected
by individual trip points.
* tag 'imx-dt64-4.21' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux:
arm64: dts: ls1046a: add qdma device tree nodes
arm64: dts: ls1043a: add qdma device tree nodes
arm64: dts: ls1088a: Add missing dma-ranges property
arm64: dts: ls1088a: Move fsl-mc node
arm64: dts: fsl: Add all CPUs in cooling maps
arm64: dts: Add support for NXP LS1028A SoC
arm64: dts: layerscape: removed compatible string "snps,dw-pcie"
arm64: dts: fsl: Add the status property disable PCIe
arm64: dts: ls1012a: Add FRWY-LS1012A board support
arm64: dts: add LX2160AQDS board support
arm64: dts: add LX2160ARDB board support
arm64: dts: add QorIQ LX2160A SoC support
Signed-off-by: Olof Johansson <olof@lixom.net>
Samsung DTS ARM64 changes for v4.21
1. Update DWC3 hardware modules to Exynos5433 specific variant.
2. Update cooling maps to include all CPU devices in multiple DTS files.
* tag 'samsung-dt64-4.21' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux:
arm64: dts: exynos: Add all CPUs in cooling maps
arm64: dts: exynos: Update DWC3 modules on Exynos5433 SoCs
Signed-off-by: Olof Johansson <olof@lixom.net>
mvebu dt64 for 4.21 (part 1)
- complete the description of the clearfog-gt-8k board (Armada 8040
based board)
- declare eMMC on espressobin (Armada 3720 based board) which still
need to be enable by the bootloader as it is not present on all the
board.
- add a new version of the Macchiatobin (Armada 8040 based board): the
Single Shot (without the 10G 3310 PHYs).
* tag 'mvebu-dt64-4.21-1' of git://git.infradead.org/linux-mvebu:
arm64: dts: clearfog-gt-8k: describe mini-PCIe CON2 USB
arm64: dts: add support for Macchiatobin Single Shot board
arm64: dts: marvell: armada-37xx: Enable emmc on espressobin
arm64: dts: marvell: armada37xx: Add emmc/sdio pinctrl definition
arm64: dts: clearfog-gt-8k: enable mini-PCIe CON2 USB
arm64: dts: clearfog-gt-8k: 1G eth PHY reset signal
arm64: dts: clearfog-gt-8k: fix USB regulator gpio polarity
Signed-off-by: Olof Johansson <olof@lixom.net>
Qualcomm ARM64 Updates for v4.21 Part 2
* Switch to use dwc3-qcom glue driver on MSM8996
* Fix issue with xo clk name on MSM8998
* Add cooling maps on MSM8916
* Add UART nodes on SDM845
* Add camera subsystem support on MSM8996 and MSM8916
* tag 'qcom-arm64-for-4.21-2' of git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux:
arm64: dts: msm8996: Use dwc3-qcom glue driver for USB
arm64: dts: qcom: msm8998: Fixup clock to use xo_board
arm64: dts: qcom: sdm845: Add UART nodes
arm64: dts: qcom: msm8996: Add CAMSS support
arm64: dts: qcom: msm8996: Add VFE SMMU node
arm64: dts: qcom: Add pinctrls for camera sensors
arm64: dts: qcom: Add Camera Control Interface pinctrls
arm64: dts: qcom: msm8916: Add CAMSS support
arm64: dts: qcom: msm8916: Add IOMMU sub-node for VFE context bank
arm64: dts: msm8916: Add all CPUs in cooling maps
Signed-off-by: Olof Johansson <olof@lixom.net>
Allwinner arm64 DT changes for 4.21
Our usual set of arm64 DT changes, with the biggest additions being:
- Support for the video decoding engine in the A64
- Support for the audio codec in the A64
- USB Support in the H6
- HDMI Support in the H6
- EMAC Support in the H6
- New board: Orange Pi Lite2
* tag 'sunxi-dt64-for-4.21' of https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux: (27 commits)
arm64: dts: allwinner: a64: Fix up RTC device node and clock references
arm64: dts: allwinner: a64: Add Video Engine node
arm64: dts: allwinner: a64: Add support for the SRAM C1 section
arm64: dts: allwinner: a64: pinebook: enable power supplies
arm64: dts: allwinner: a64: sopine-baseboard: enable power supplies
arm64: dts: allwinner: axp803: add AC and battery power supplies
arm64: dts: allwinner: a64: bananapi-m64: Enable audio codec
arm64: dts: allwinner: a64: enable sound on Pinebook
arm64: dts: allwinner: a64: enable sound on Pine64 and SoPine
arm64: dts: allwinner: a64: add nodes necessary for analog sound support
arm64: dts: allwinner: h6: orangepi: Add device nodes for LEDs
arm64: dts: allwinner: h6: orangepi: Enable USB 2.0 host and OTG ports
arm64: dts: allwinner: h6: orangepi: Add board-wide 5V regulator
arm64: dts: allwinner: h6: fix EMAC compatible string sequence
arm64: dts: allwinner: a64: Add device node for Mali-400 GPU
dt-bindings: gpu: mali-utgard: Add compatible for A64 Mali
arm64: dts: allwinner: h6: enable USB2 on Pine H64
arm64: dts: allwinner: h6: add USB Vbus regulator for Pine H64
arm64: dts: allwinner: h6: add USB2-related device nodes
arm64: dts: allwinner: h6: Enable HDMI output on Pine H64 board
...
Signed-off-by: Olof Johansson <olof@lixom.net>
Allwinner DT changes for 4.21
This is a quite big pull request this time, with a huge number of changes
(and patches) due to us fixing the vast majority of the DTC warnings our DT
had.
We also have a bunch of other good, more meaningful, changes:
- Support for the new Allwinner T3 (rebranded R40) and f1c100s (armv5)
SoCs
- AXP803 PMIC AC Power supply support
- Rework of the oscillators tree
- Two new boards: the t3-cqa3t-bv3 and Lichee Pi Nano
Plus a few enhancements here and there.
* tag 'sunxi-dt-for-4.21' of https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux: (84 commits)
ARM: dts: sunxi: Fix PMU compatible strings
ARM: dts: sun8i: r40: Add RTC device node
ARM: dts: sunxi: h3/h5: Fix up RTC device node and clock references
ARM: dts: sun8i: a23/a33: Fix up RTC device node
ARM: dts: sun8i: r40: Add clock accuracy for external oscillators
ARM: dts: sunxi: h3/h5: Add clock accuracy for external oscillators
ARM: dts: sun8i: a33: Drop audio codec oversampling rate to 128 fs
ARM: dts: sun8i: h3: Remove unnecessary reserved memory node
ARM: dts: sun8i: a33: Remove unnecessary reserved memory node
ARM: dts: suniv: Add device tree for Lichee Pi Nano
ARM: dts: suniv: add initial DTSI file for F1C100s
ARM: dts: axp81x: add AC power supply subnode
ARM: dts: sun8i: v3s: Remove skeleton and memory to avoid warnings
ARM: dts: sun8i: v3s: Provide default muxing for relevant controllers
ARM: dts: sun8i: v3s: Change pinctrl nodes to avoid warning
ARM: dts: sun8i: v3s: Change LRADC node names to avoid warnings
ARM: dts: sun8i: h3: Remove leading zeros from unit-addresses
ARM: dts: sun8i: BPI-M2M: Remove i2c nodes
ARM: dts: sun8i: a23/a33: Provide default muxing for relevant controllers
ARM: dts: sunxi: reference: Move the muxing back to the common DTSI
...
Signed-off-by: Olof Johansson <olof@lixom.net>
This enables the use of per-task stack canary values if GCC has
support for emitting the stack canary reference relative to the
value of sp_el0, which holds the task struct pointer in the arm64
kernel.
The $(eval) extends KBUILD_CFLAGS at the moment the make rule is
applied, which means asm-offsets.o (which we rely on for the offset
value) is built without the arguments, and everything built afterwards
has the options set.
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Wire up the basic support for hot-adding memory. Since memory hotplug
is fairly tightly coupled to sparsemem, we tweak pfn_valid() to also
cross-check the presence of a section in the manner of the generic
implementation, before falling back to memblock to check for no-map
regions within a present section as before. By having arch_add_memory(()
create the linear mapping first, this then makes everything work in the
way that __add_section() expects.
We expect hotplug to be ACPI-driven, so the swapper_pg_dir updates
should be safe from races by virtue of the global device hotplug lock.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Commit 959bf2fd03 ("arm64: percpu: Rewrite per-cpu ops to allow use of
LSE atomics") introduced alternative code sequences for the arm64 percpu
atomics, so that the LSE instructions can be patched in at runtime if
they are supported by the CPU.
Unfortunately, when patching in the LSE sequence for a value-returning
pcpu atomic, the argument registers are the wrong way round. The
implementation of this_cpu_add_return() therefore ends up adding
uninitialised stack to the percpu variable and returning garbage.
As it turns out, there aren't very many users of the value-returning
percpu atomics in mainline and we only spotted this due to a failure in
the kprobes selftests. In this case, when attempting to single-step over
the out-of-line instruction slot, the debug monitors would not be
enabled because calling this_cpu_inc_return() on the kernel debug
monitor refcount would fail to detect the transition from 0. We would
consequently execute past the slot and take an undefined instruction
exception from the kernel, resulting in a BUG:
| kernel BUG at arch/arm64/kernel/traps.c:421!
| PREEMPT SMP
| pc : do_undefinstr+0x268/0x278
| lr : do_undefinstr+0x124/0x278
| Process swapper/0 (pid: 1, stack limit = 0x(____ptrval____))
| Call trace:
| do_undefinstr+0x268/0x278
| el1_undef+0x10/0x78
| 0xffff00000803c004
| init_kprobes+0x150/0x180
| do_one_initcall+0x74/0x178
| kernel_init_freeable+0x188/0x224
| kernel_init+0x10/0x100
| ret_from_fork+0x10/0x1c
Fix the argument order to get the value-returning pcpu atomics working
correctly when implemented using the LSE instructions.
Reported-by: Catalin Marinas <catalin.marinas@arm.com>
Tested-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
While we can export symbols from assembly files, CONFIG_MODVERIONS requires C
declarations of anyhting that's exported.
Let's account for this as other architectures do by placing these declarations
in <asm/asm-prototypes.h>, which kbuild will automatically use to generate
modversion information for assembly files.
Since we already define most prototypes in existing headers, we simply need to
include those headers in <asm/asm-prototypes.h>, and don't need to duplicate
these.
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
With the introduction of 52-bit virtual addressing for userspace, we are
now in a position where the virtual addressing capability of userspace
may exceed that of the kernel. Consequently, the VA_BITS definition
cannot be used blindly, since it reflects only the size of kernel
virtual addresses.
This patch introduces MAX_USER_VA_BITS which is either VA_BITS or 52
depending on whether 52-bit virtual addressing has been configured at
build time, removing a few places where the 52 is open-coded based on
explicit CONFIG_ guards.
Signed-off-by: Will Deacon <will.deacon@arm.com>
This patch enables arm64's bpf_int_jit_compile() to provide
bpf_line_info by calling bpf_prog_fill_jited_linfo().
Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
In some randconfig builds, the new CONFIG_ARM64_USER_VA_BITS_52
triggered a build failure:
arch/arm64/mm/proc.S:287: Error: immediate out of range
As it turns out, we were incorrectly setting PGTABLE_LEVELS here,
lacking any other default value.
This fixes the calculation of CONFIG_PGTABLE_LEVELS to consider
all combinations again.
Fixes: 68d23da437 ("arm64: Kconfig: Re-jig CONFIG options for 52-bit VA")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Commit 3962446922 ("arm64: preempt: Provide our own implementation of
asm/preempt.h") extended the preempt count field in struct thread_info
to 64 bits, so that it consists of a 32-bit count plus a 32-bit flag
indicating whether or not the current task needs rescheduling.
Whilst the asm-offsets definition of TSK_TI_PREEMPT was updated to point
to this new field, the assembly usage was left untouched meaning that a
32-bit load from TSK_TI_PREEMPT on a big-endian machine actually returns
the reschedule flag instead of the count.
Whilst we could fix this by pointing TSK_TI_PREEMPT at the count field,
we're actually better off reworking the two assembly users so that they
operate on the whole 64-bit value in favour of inspecting the thread
flags separately in order to determine whether a reschedule is needed.
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reported-by: "kernelci.org bot" <bot@kernelci.org>
Tested-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
