aboutsummaryrefslogtreecommitdiffstats
path: root/arch/arm64
AgeCommit message (Collapse)AuthorFilesLines
2020-05-13arm64: tegra: Kill off "simple-panel" compatiblesRob Herring1-1/+1
"simple-panel" is a Linux driver and has never been an accepted upstream compatible string, so remove it. Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Jonathan Hunter <jonathanh@nvidia.com> Cc: linux-tegra@vger.kernel.org Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-05-13arm64: dts: imx8qxp-mek: Do not use underscore in node nameFabio Estevam1-1/+1
Underscores are not recommended to be used in node names, so change the pinctrl IO expander node name. This change also makes the pinctrl node names to follow the convention used by other pinctrl group names. Signed-off-by: Fabio Estevam <festevam@gmail.com> Reviewed-by: Abel Vesa <abel.vesa@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2020-05-12arm64: dts: qcom: sc7180: Add "no-map" to cmd_db reserved areaDouglas Anderson1-0/+1
The example in the bindings and all the current users (except sc7180) have "no-map". I'm pretty sure we need it on sc7180 too. Add it. Reviewed-by: Stephen Boyd <swboyd@chromium.org> Fixes: e0abc5eb526e ("arm64: dts: qcom: sc7180: Add cmd_db reserved area") Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20200424085121.1.I9d1e84d30f488cdb5a957f582abaecd2c0b24d70@changeid Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-05-12arm64: dts: qcom: msm8916-samsung-a5u: Add touchscreenStephan Gerhold1-0/+35
A5U uses a Melfas MMS345L touchscreen that is connected to blsp_i2c5. Add it to the device tree. Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20200426140642.204395-5-stephan@gerhold.net Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-05-12arm64: dts: qcom: msm8916-samsung-a2015: Add touchscreen regulatorStephan Gerhold1-0/+25
A3U and A5U both use an extra touchscreen LDO regulator that provides 3.3V for the touch screen controller. Add it as fixed regulator to the common include. Cc: Michael Srba <Michael.Srba@seznam.cz> Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20200426140642.204395-4-stephan@gerhold.net Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-05-12arm64: dts: qcom: msm8916: Add blsp_i2c5Stephan Gerhold2-0/+39
MSM8916 has another I2C QUP controller that can be enabled on GPIO 18 and 19. Add blsp_i2c5 to msm8916.dtsi and disable it by default. Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20200426140642.204395-3-stephan@gerhold.net Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-05-12arm64: dts: qcom: msm8916: Add blsp_i2c1Stephan Gerhold2-0/+39
MSM8916 has another I2C QUP controller that can be enabled on GPIO 2 and 3. Add blsp_i2c1 to msm8916.dtsi and disable it by default. Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20200426140642.204395-2-stephan@gerhold.net Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-05-12arm64: dts: qcom: sc7180: Support ETMv4 power managementSai Prakash Ranjan1-0/+8
Now that deep idle states are properly supported on SC7180, we need to add "coresight-loses-context-with-cpu" property to avoid failure of trace session because of losing context on entering deep idle states. Reviewed-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> Link: https://lore.kernel.org/r/20200424111644.27970-1-saiprakash.ranjan@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-05-12arm64: bti: Fix support for userspace only BTIMark Brown1-0/+8
When setting PTE_MAYBE_GP we check system_supports_bti() but this is true for systems where only CONFIG_BTI is set causing us to enable BTI on some kernel text. Add an extra check for the kernel mode option, using an ifdef due to line length. Fixes: c8027285e366 ("arm64: Set GP bit in kernel page tables to enable BTI for the kernel") Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20200512113950.29996-1-broonie@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2020-05-12arm64: cpufeature: Add "or" to mitigations for multiple errataGeert Uytterhoeven1-3/+3
Several actions are not mitigations for a single erratum, but for multiple errata. However, printing a line like CPU features: detected: ARM errata 1165522, 1530923 may give the false impression that all three listed errata have been detected. This can confuse the user, who may think his Cortex-A55 is suddenly affected by a Cortex-A76 erratum. Add "or" to all descriptions for mitigations for multiple errata, to make it clear that only one or more of the errata printed are applicable, and not necessarily all of them. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20200512145255.5520-1-geert+renesas@glider.be Signed-off-by: Will Deacon <will@kernel.org>
2020-05-12arm64: kconfig: Update and comment GCC version check for kernel BTIWill Deacon1-1/+2
Some versions of GCC are known to suffer from a BTI code generation bug, meaning that CONFIG_CC_HAS_BRANCH_PROT_PAC_RET_BTI cannot be solely used to determine whether or not we can compile with kernel with BTI enabled. Update the BTI Kconfig entry to refer to the relevant GCC bugzilla entry (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94697) and update the check now that the fix has been merged into GCC release 10.1. Acked-by: Mark Brown <broonie@kernel.org> Signed-off-by: Will Deacon <will@kernel.org>
2020-05-12arm64: dts: renesas: r8a774c0-cat874: Add support for AISTARVISION MIPI Adapter V2.1Lad Prabhakar3-1/+168
This patch adds support for AISTARVISION MIPI Adapter V2.1 board connected to G2E board. Common file aistarvision-mipi-adapter-2.1.dtsi is created which have the camera endpoint nodes for imx219 and ov5645 so that this can be re-used with other G2x platforms. r8a774c0-ek874-mipi-2.1.dts file enables the required VIN/CSI nodes and by default ties ov5645 camera endpoint to CSI2. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://lore.kernel.org/r/1587397794-11237-1-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2020-05-12kbuild: remove unused AS assignmentMasahiro Yamada1-2/+0
$(AS) is not used anywhere in the kernel build, hence commit aa824e0c962b ("kbuild: remove AS variable") killed it. Remove the left-over code in arch/{arm,arm64}/Makefile. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Acked-by: Will Deacon <will@kernel.org>
2020-05-11arm64: dts: sdm845: Add "no-hpd" to sn65dsi86 on chezaDouglas Anderson1-0/+2
We don't have the HPD line hooked up to the bridge chip. Add it as suggested in the patch ("dt-bindings: drm/bridge: ti-sn65dsi86: Document no-hpd"). NOTE: this patch isn't expected to have any effect but just keeps us cleaner for the future. Currently the driver in Linux just assumes that nobody has HPD hooked up. This change allows us to later implement HPD support in the driver without messing up sdm845-cheza. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20200507143354.v5.6.I89df9b6094549b8149aa8b8347f7401c678055b0@changeid Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-05-11arch: arm64: dts: msm8996: Add CCI nodeLoic Poulain1-0/+37
Add CCI controller node, which can be used to communicate with camera sensors (I2C subset). MSM8996 CCI offers two masters, i2c-bus@0 and i2c-bus@1. Signed-off-by: Loic Poulain <loic.poulain@linaro.org> Link: https://lore.kernel.org/r/1587470425-13726-2-git-send-email-loic.poulain@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-05-11arm64: dts: msm8996: Fix CSI IRQ typesLoic Poulain1-10/+10
Each IRQ_TYPE_NONE interrupt causes a warning at boot. Fix that by defining an appropriate type. Fixes: e0531312e78f ("arm64: dts: qcom: msm8996: Add CAMSS support") Signed-off-by: Loic Poulain <loic.poulain@linaro.org> Link: https://lore.kernel.org/r/1587470425-13726-1-git-send-email-loic.poulain@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-05-11arm64: dts: qcom: sc7180: Update Q6V5 MSS nodeSibi Sankar2-4/+31
Add TCSR node and update MSS node to support MSA based Modem boot on SC7180 SoCs. Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Sibi Sankar <sibis@codeaurora.org> Link: https://lore.kernel.org/r/20200421143228.8981-8-sibis@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-05-11arm64: dts: qcom: sc7180: Add Q6V5 MSS nodeSibi Sankar1-0/+36
This patch adds Q6V5 MSS PAS remoteproc node for SC7180 SoCs. Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Sibi Sankar <sibis@codeaurora.org> Link: https://lore.kernel.org/r/20200421143228.8981-7-sibis@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-05-11arm64: dts: qcom: sc7180: Update reserved memory mapSibi Sankar2-2/+84
Add missing regions and remove unused regions from the reserved memory map, as described in version 5. Tested-by: Evan Green <evgreen@chromium.org> Signed-off-by: Sibi Sankar <sibis@codeaurora.org> Link: https://lore.kernel.org/r/20200421143228.8981-6-sibis@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-05-11arm64/crash_core: Export KERNELPACMASK in vmcoreinfoAmit Daniel Kachhap2-4/+4
Recently arm64 linux kernel added support for Armv8.3-A Pointer Authentication feature. If this feature is enabled in the kernel and the hardware supports address authentication then the return addresses are signed and stored in the stack to prevent ROP kind of attack. Kdump tool will now dump the kernel with signed lr values in the stack. Any user analysis tool for this kernel dump may need the kernel pac mask information in vmcoreinfo to generate the correct return address for stacktrace purpose as well as to resolve the symbol name. This patch is similar to commit ec6e822d1a22d0eef ("arm64: expose user PAC bit positions via ptrace") which exposes pac mask information via ptrace interfaces. The config gaurd ARM64_PTR_AUTH is removed form asm/compiler.h so macros like ptrauth_kernel_pac_mask can be used ungaurded. This config protection is confusing as the pointer authentication feature may be missing at runtime even though this config is present. Signed-off-by: Amit Daniel Kachhap <amit.kachhap@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Link: https://lore.kernel.org/r/1589202116-18265-1-git-send-email-amit.kachhap@arm.com Signed-off-by: Will Deacon <will@kernel.org>
2020-05-11bpf, arm64: Optimize ADD,SUB,JMP BPF_K using arm64 add/sub immediatesLuke Nelson2-6/+38
The current code for BPF_{ADD,SUB} BPF_K loads the BPF immediate to a temporary register before performing the addition/subtraction. Similarly, BPF_JMP BPF_K cases load the immediate to a temporary register before comparison. This patch introduces optimizations that use arm64 immediate add, sub, cmn, or cmp instructions when the BPF immediate fits. If the immediate does not fit, it falls back to using a temporary register. Example of generated code for BPF_ALU64_IMM(BPF_ADD, R0, 2): without optimization: 24: mov x10, #0x2 28: add x7, x7, x10 with optimization: 24: add x7, x7, #0x2 The code could use A64_{ADD,SUB}_I directly and check if it returns AARCH64_BREAK_FAULT, similar to how logical immediates are handled. However, aarch64_insn_gen_add_sub_imm from insn.c prints error messages when the immediate does not fit, and it's simpler to check if the immediate fits ahead of time. Co-developed-by: Xi Wang <xi.wang@gmail.com> Signed-off-by: Xi Wang <xi.wang@gmail.com> Signed-off-by: Luke Nelson <luke.r.nels@gmail.com> Acked-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/r/20200508181547.24783-4-luke.r.nels@gmail.com Signed-off-by: Will Deacon <will@kernel.org>
2020-05-11bpf, arm64: Optimize AND,OR,XOR,JSET BPF_K using arm64 logical immediatesLuke Nelson2-8/+43
The current code for BPF_{AND,OR,XOR,JSET} BPF_K loads the immediate to a temporary register before use. This patch changes the code to avoid using a temporary register when the BPF immediate is encodable using an arm64 logical immediate instruction. If the encoding fails (due to the immediate not being encodable), it falls back to using a temporary register. Example of generated code for BPF_ALU32_IMM(BPF_AND, R0, 0x80000001): without optimization: 24: mov w10, #0x8000ffff 28: movk w10, #0x1 2c: and w7, w7, w10 with optimization: 24: and w7, w7, #0x80000001 Since the encoding process is quite complex, the JIT reuses existing functionality in arch/arm64/kernel/insn.c for encoding logical immediates rather than duplicate it in the JIT. Co-developed-by: Xi Wang <xi.wang@gmail.com> Signed-off-by: Xi Wang <xi.wang@gmail.com> Signed-off-by: Luke Nelson <luke.r.nels@gmail.com> Acked-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/r/20200508181547.24783-3-luke.r.nels@gmail.com Signed-off-by: Will Deacon <will@kernel.org>
2020-05-11arm64: insn: Fix two bugs in encoding 32-bit logical immediatesLuke Nelson1-7/+7
This patch fixes two issues present in the current function for encoding arm64 logical immediates when using the 32-bit variants of instructions. First, the code does not correctly reject an all-ones 32-bit immediate, and returns an undefined instruction encoding. Second, the code incorrectly rejects some 32-bit immediates that are actually encodable as logical immediates. The root cause is that the code uses a default mask of 64-bit all-ones, even for 32-bit immediates. This causes an issue later on when the default mask is used to fill the top bits of the immediate with ones, shown here: /* * Pattern: 0..01..10..01..1 * * Fill the unused top bits with ones, and check if * the result is a valid immediate (all ones with a * contiguous ranges of zeroes). */ imm |= ~mask; if (!range_of_ones(~imm)) return AARCH64_BREAK_FAULT; To see the problem, consider an immediate of the form 0..01..10..01..1, where the upper 32 bits are zero, such as 0x80000001. The code checks if ~(imm | ~mask) contains a range of ones: the incorrect mask yields 1..10..01..10..0, which fails the check; the correct mask yields 0..01..10..0, which succeeds. The fix for both issues is to generate a correct mask based on the instruction immediate size, and use the mask to check for all-ones, all-zeroes, and values wider than the mask. Currently, arch/arm64/kvm/va_layout.c is the only user of this function, which uses 64-bit immediates and therefore won't trigger these bugs. We tested the new code against llvm-mc with all 1,302 encodable 32-bit logical immediates and all 5,334 encodable 64-bit logical immediates. Fixes: ef3935eeebff ("arm64: insn: Add encoder for bitwise operations using literals") Suggested-by: Will Deacon <will@kernel.org> Co-developed-by: Xi Wang <xi.wang@gmail.com> Signed-off-by: Xi Wang <xi.wang@gmail.com> Signed-off-by: Luke Nelson <luke.r.nels@gmail.com> Reviewed-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20200508181547.24783-2-luke.r.nels@gmail.com Signed-off-by: Will Deacon <will@kernel.org>
2020-05-11arm64: fix the flush_icache_range arguments in machine_kexecChristoph Hellwig1-0/+1
The second argument is the end "pointer", not the length. Fixes: d28f6df1305a ("arm64/kexec: Add core kexec support") Cc: <stable@vger.kernel.org> # 4.8.x- Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2020-05-08crypto: lib/sha1 - remove unnecessary includes of linux/cryptohash.hEric Biggers2-2/+0
<linux/cryptohash.h> sounds very generic and important, like it's the header to include if you're doing cryptographic hashing in the kernel. But actually it only includes the library implementation of the SHA-1 compression function (not even the full SHA-1). This should basically never be used anymore; SHA-1 is no longer considered secure, and there are much better ways to do cryptographic hashing in the kernel. Most files that include this header don't actually need it. So in preparation for removing it, remove all these unneeded includes of it. Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-05-08crypto: arm64/aes-glue - use crypto_shash_tfm_digest()Eric Biggers1-3/+1
Instead of manually allocating a 'struct shash_desc' on the stack and calling crypto_shash_digest(), switch to using the new helper function crypto_shash_tfm_digest() which does this for us. Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-05-07arm64: dts: ti: k3-am65/j721e-mcu: update cpts nodeGrygorii Strashko2-2/+6
Update CPTS node following DT binding update: - add reg and compatible properties - fix node name Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-07arm64: defconfig: Remove QCOM_GLINK_SSRBjorn Andersson1-1/+0
Remove the QCOM_GLINK_SSR option from the arm64 defconfig, as the module is assimilated by QCOM_GLINK - which is selected by other means. Acked-by: Chris Lew <clew@codeaurora.org> Acked-by: Rishabh Bhatnagar <rishabhb@codeaurora.org> Link: https://lore.kernel.org/r/20200423003736.2027371-5-bjorn.andersson@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-05-07Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linuxLinus Torvalds1-0/+2
Pull arm64 fix from Catalin Marinas: "Avoid potential NULL dereference in huge_pte_alloc() on pmd_alloc() failure" * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: arm64: hugetlb: avoid potential NULL dereference
2020-05-07arm64: vdso: Map the vDSO text with guarded pages when built for BTIMark Brown1-1/+5
The kernel is responsible for mapping the vDSO into userspace processes, including mapping the text section as executable. Handle the mapping of the vDSO for BTI similarly, mapping the text section as guarded pages so the BTI annotations in the vDSO become effective when they are present. This will mean that we can have BTI active for the vDSO in processes that do not otherwise support BTI. This should not be an issue for any expected use of the vDSO. Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Link: https://lore.kernel.org/r/20200506195138.22086-12-broonie@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2020-05-07arm64: vdso: Force the vDSO to be linked as BTI when built for BTIMark Brown1-1/+3
When the kernel and hence vDSO are built with BTI enabled force the linker to link the vDSO as BTI. This will cause the linker to warn if any of the input files do not have the BTI annotation, ensuring that we don't silently fail to provide a vDSO that is built and annotated for BTI when the kernel is being built with BTI. Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Link: https://lore.kernel.org/r/20200506195138.22086-11-broonie@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2020-05-07arm64: vdso: Annotate for BTIMark Brown3-0/+9
Generate BTI annotations for all assembly files included in the 64 bit vDSO. Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Link: https://lore.kernel.org/r/20200506195138.22086-10-broonie@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2020-05-07arm64: asm: Provide a mechanism for generating ELF note for BTIMark Brown1-0/+50
ELF files built for BTI should have a program property note section which identifies them as such. The linker expects to find this note in all object files it is linking into a BTI annotated output, the compiler will ensure that this happens for C files but for assembler files we need to do this in the source so provide a macro which can be used for this purpose. To support likely future requirements for additional notes we split the defininition of the flags to set for BTI code from the macro that creates the note itself. This is mainly for use in the vDSO which should be a normal ELF shared library and should therefore include BTI annotations when built for BTI. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20200506195138.22086-9-broonie@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2020-05-07arm64: bti: Provide Kconfig for kernel mode BTIMark Brown1-0/+19
Now that all the code is in place provide a Kconfig option allowing users to enable BTI for the kernel if their toolchain supports it, defaulting it on since this has security benefits. This is a separate configuration option since we currently don't support secondary CPUs that lack BTI if the boot CPU supports it. Code generation issues mean that current GCC 9 versions are not able to produce usable BTI binaries so we disable support for building with GCC versions prior to 10, once a fix is backported to GCC 9 the dependencies will be updated. Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Link: https://lore.kernel.org/r/20200506195138.22086-8-broonie@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2020-05-07arm64: mm: Mark executable text as guarded pagesMark Brown1-2/+2
When the kernel is built for BTI and running on a system which supports make all executable text guarded pages to ensure that loadable module and JITed BPF code is protected by BTI. Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Link: https://lore.kernel.org/r/20200506195138.22086-7-broonie@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2020-05-07arm64: bpf: Annotate JITed code for BTIMark Brown2-0/+20
In order to extend the protection offered by BTI to all code executing in kernel mode we need to annotate JITed BPF code appropriately for BTI. To do this we need to add a landing pad to the start of each BPF function and also immediately after the function prologue if we are emitting a function which can be tail called. Jumps within BPF functions are all to immediate offsets and therefore do not require landing pads. Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Link: https://lore.kernel.org/r/20200506195138.22086-6-broonie@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2020-05-07arm64: Set GP bit in kernel page tables to enable BTI for the kernelMark Brown3-0/+31
Now that the kernel is built with BTI annotations enable the feature by setting the GP bit in the stage 1 translation tables. This is done based on the features supported by the boot CPU so that we do not need to rewrite the translation tables. In order to avoid potential issues on big.LITTLE systems when there are a mix of BTI and non-BTI capable CPUs in the system when we have enabled kernel mode BTI we change BTI to be a _STRICT_BOOT_CPU_FEATURE when we have kernel BTI. This will prevent any CPUs that don't support BTI being started if the boot CPU supports BTI rather than simply not using BTI as we do when supporting BTI only in userspace. The main concern is the possibility of BTYPE being preserved by a CPU that does not implement BTI when a thread is migrated to it resulting in an incorrect state which could generate an exception when the thread migrates back to a CPU that does support BTI. If we encounter practical systems which mix BTI and non-BTI CPUs we will need to revisit this implementation. Since we currently do not generate landing pads in the BPF JIT we only map the base kernel text in this way. Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Link: https://lore.kernel.org/r/20200506195138.22086-5-broonie@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2020-05-07arm64: asm: Override SYM_FUNC_START when building the kernel with BTIMark Brown1-0/+46
When the kernel is built for BTI override SYM_FUNC_START and related macros to add a BTI landing pad to the start of all global functions, ensuring that they are BTI safe. The ; at the end of the BTI_x macros is for the benefit of the macro-generated functions in xen-hypercall.S. Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Link: https://lore.kernel.org/r/20200506195138.22086-4-broonie@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2020-05-07arm64: bti: Support building kernel C code using BTIMark Brown1-0/+4
When running with BTI enabled we need to ask the compiler to enable generation of BTI landing pads beyond those generated as a result of pointer authentication instructions being landing pads. Since the two features are practically speaking unlikely to be used separately we will make kernel mode BTI depend on pointer authentication in order to simplify the Makefile. Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Link: https://lore.kernel.org/r/20200506195138.22086-3-broonie@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2020-05-07arm64: Document why we enable PAC support for leaf functionsMark Brown1-0/+3
Document the fact that we enable pointer authentication protection for leaf functions since there is some narrow potential for ROP protection benefits and little overhead has been observed. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20200506195138.22086-2-broonie@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2020-05-07Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds4-15/+33
Pull kvm fixes from Paolo Bonzini: "Bugfixes, mostly for ARM and AMD, and more documentation. Slightly bigger than usual because I couldn't send out what was pending for rc4, but there is nothing worrisome going on. I have more fixes pending for guest debugging support (gdbstub) but I will send them next week" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: (22 commits) KVM: X86: Declare KVM_CAP_SET_GUEST_DEBUG properly KVM: selftests: Fix build for evmcs.h kvm: x86: Use KVM CPU capabilities to determine CR4 reserved bits KVM: VMX: Explicitly clear RFLAGS.CF and RFLAGS.ZF in VM-Exit RSB path docs/virt/kvm: Document configuring and running nested guests KVM: s390: Remove false WARN_ON_ONCE for the PQAP instruction kvm: ioapic: Restrict lazy EOI update to edge-triggered interrupts KVM: x86: Fixes posted interrupt check for IRQs delivery modes KVM: SVM: fill in kvm_run->debug.arch.dr[67] KVM: nVMX: Replace a BUG_ON(1) with BUG() to squash clang warning KVM: arm64: Fix 32bit PC wrap-around KVM: arm64: vgic-v4: Initialize GICv4.1 even in the absence of a virtual ITS KVM: arm64: Save/restore sp_el0 as part of __guest_enter KVM: arm64: Delete duplicated label in invalid_vector KVM: arm64: vgic-its: Fix memory leak on the error path of vgic_add_lpi() KVM: arm64: vgic-v3: Retire all pending LPIs on vcpu destroy KVM: arm: vgic-v2: Only use the virtual state when userspace accesses pending bits KVM: arm: vgic: Only use the virtual state when userspace accesses enable bits KVM: arm: vgic: Synchronize the whole guest on GIC{D,R}_I{S,C}ACTIVER read KVM: arm64: PSCI: Forbid 64bit functions for 32bit guests ...
2020-05-07arm64: vdso: Add --eh-frame-hdr to ldflagsVincenzo Frascino1-1/+1
LLVM's unwinder depends on the .eh_frame_hdr being present for unwinding. However, when compiling Linux with GCC, the section is not present in the vdso library object and when compiling with Clang, it is present, but it has zero length. With GCC the problem was not spotted because libgcc unwinder does not require the .eh_frame_hdr section to be present. Add --eh-frame-hdr to ldflags to correctly generate and populate the section for both GCC and LLVM. Fixes: 28b1a824a4f44 ("arm64: vdso: Substitute gettimeofday() with C implementation") Reported-by: Tamas Zsoldos <tamas.zsoldos@arm.com> Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com> Tested-by: Tamas Zsoldos <tamas.zsoldos@arm.com> Cc: Will Deacon <will@kernel.org> Cc: Catalin Marinas <catalin.marinas@arm.com> Link: https://lore.kernel.org/r/20200507104049.47834-1-vincenzo.frascino@arm.com Signed-off-by: Will Deacon <will@kernel.org>
2020-05-07arm64: dts: qcom: sdm845-cheza: Add iommus propertySibi Sankar1-0/+5
Add iommus property to remoteproc modem node. Following SMMU global faults are seen without it. arm-smmu 15000000.iommu: Unexpected global fault, this could be serious arm-smmu 15000000.iommu: GFSR 0x80000002, GFSYNR0 0x00000000, GFSYNR1 0x00000781, GFSYNR2 0x00000000 arm-smmu 15000000.iommu: Unexpected global fault, this could be serious arm-smmu 15000000.iommu: GFSR 0x80000002, GFSYNR0 0x00000000, GFSYNR1 0x00000461, GFSYNR2 0x00000000 Signed-off-by: Sibi Sankar <sibis@codeaurora.org> Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> Link: https://lore.kernel.org/r/38c607841e81664a2db69a27260cd7dfbd653458.1587407458.git.saiprakash.ranjan@codeaurora.org Signed-off-by: Will Deacon <will@kernel.org>
2020-05-07arm64: hugetlb: avoid potential NULL dereferenceMark Rutland1-0/+2
The static analyzer in GCC 10 spotted that in huge_pte_alloc() we may pass a NULL pmdp into pte_alloc_map() when pmd_alloc() returns NULL: | CC arch/arm64/mm/pageattr.o | CC arch/arm64/mm/hugetlbpage.o | from arch/arm64/mm/hugetlbpage.c:10: | arch/arm64/mm/hugetlbpage.c: In function ‘huge_pte_alloc’: | ./arch/arm64/include/asm/pgtable-types.h:28:24: warning: dereference of NULL ‘pmdp’ [CWE-690] [-Wanalyzer-null-dereference] | ./arch/arm64/include/asm/pgtable.h:436:26: note: in expansion of macro ‘pmd_val’ | arch/arm64/mm/hugetlbpage.c:242:10: note: in expansion of macro ‘pte_alloc_map’ | |arch/arm64/mm/hugetlbpage.c:232:10: | |./arch/arm64/include/asm/pgtable-types.h:28:24: | ./arch/arm64/include/asm/pgtable.h:436:26: note: in expansion of macro ‘pmd_val’ | arch/arm64/mm/hugetlbpage.c:242:10: note: in expansion of macro ‘pte_alloc_map’ This can only occur when the kernel cannot allocate a page, and so is unlikely to happen in practice before other systems start failing. We can avoid this by bailing out if pmd_alloc() fails, as we do earlier in the function if pud_alloc() fails. Fixes: 66b3923a1a0f ("arm64: hugetlb: add support for PTE contiguous bit") Signed-off-by: Mark Rutland <mark.rutland@arm.com> Reported-by: Kyrill Tkachov <kyrylo.tkachov@arm.com> Cc: <stable@vger.kernel.org> # 4.5.x- Cc: Will Deacon <will@kernel.org> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2020-05-07arm64: dts: hi6220: Add CTI optionsMike Leach1-8/+122
Adds in CTI device tree information for the Hikey620 board. Signed-off-by: Mike Leach <mike.leach@linaro.org> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Tested-by: Leo Yan <leo.yan@linaro.org> Signed-off-by: Wei Xu <xuwei5@hisilicon.com>
2020-05-06Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netDavid S. Miller4-9/+24
Conflicts were all overlapping changes. Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-07arm64: dts: hikey960: pinctrl: Fix spi2/spi3 pinconfLoic Poulain2-5/+5
Only the pinmux was selected, not the pinconf, leading to spi issues. Increase drive strength so that max speed (25Mhz) can be achieved. Signed-off-by: Loic Poulain <loic.poulain@linaro.org> Signed-off-by: Wei Xu <xuwei5@hisilicon.com>
2020-05-06arm64: dts: sdm845: add IPA iommus propertyAlex Elder1-0/+2
Add an "iommus" property to the IPA node in "sdm845.dtsi". It is required because there are two regions of memory the IPA accesses through an SMMU. The next few patches define and map those regions. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-06arm64: dts: qcom: sdm845: Add SoC compatible to MTPSibi Sankar1-1/+1
Add missing SoC compatible to SDM845 MTP board file. Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Amit Kucheria <amit.kucheria@linaro.org> Signed-off-by: Sibi Sankar <sibis@codeaurora.org> Link: https://lore.kernel.org/r/20200504202243.5476-2-sibis@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-05-06Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6Linus Torvalds3-8/+23
Pull crypto fixes from Herbert Xu: "This fixes a potential scheduling latency problem for the algorithms used by WireGuard" * 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: crypto: arch/nhpoly1305 - process in explicit 4k chunks crypto: arch/lib - limit simd usage to 4k chunks