aboutsummaryrefslogtreecommitdiffstats
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2019-10-02ARM: dts: imx6-colibri: Add missing pinmuxing to Toradex eval boardPhilippe Schenker1-0/+8
This patch adds some missing pinmuxing that is in the colibri standard to the dts. Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com> Acked-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> Reviewed-by: Oleksandr Suvorov <oleksandr.suvorov@toradex.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-10-02ARM: dts: imx6-apalis: Add touchscreens used on Toradex eval boardsPhilippe Schenker4-0/+70
This commit adds the touchscreen from Toradex so one can enable it. It is disabled by default because the pins are also used for PWM<B>, PWM<C>, aka pwm2, pwm3 which is the standard use for colibri boards. Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com> Acked-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> Reviewed-by: Oleksandr Suvorov <oleksandr.suvorov@toradex.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-10-02ARM: dts: imx6qdl-apalis: Add sleep state to can interfacesPhilippe Schenker1-6/+21
This patch prepares the devicetree for the new Ixora V1.2 where we are able to turn off the supply of the can transceiver. This implies to use a sleep state on transmission pins in order to prevent backfeeding. Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com> Acked-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-10-02ARM: dts: imx6qdl-colibri: Add missing pin declaration in iomuxcPhilippe Schenker1-0/+17
This adds the muxing for the optional pins usb-oc (overcurrent) and usb-id. Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com> Acked-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-10-02ARM: dts: imx7-colibri: Add touch controllersPhilippe Schenker1-0/+24
Add touch controller that is connected over an I2C bus. It is disabled by default because the pins are also used for PWM, which is the standard use for colibri boards. Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com> Acked-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> Reviewed-by: Oleksandr Suvorov <oleksandr.suvorov@toradex.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-10-02ARM: dts: imx7-colibri: fix 1.8V/UHS supportStefan Agner1-1/+22
Add pinmuxing and do not specify voltage restrictions for the usdhc instance available on the modules edge connector. This allows to use SD-cards with higher transfer modes if supported by the carrier board. Signed-off-by: Stefan Agner <stefan.agner@toradex.com> Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com> Acked-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-10-02ARM: dts: imx7-colibri: add GPIO wakeup keyStefan Agner2-1/+20
Add wakeup GPIO key which is able to wake the system from sleep modes (e.g. Suspend-to-Memory). Signed-off-by: Stefan Agner <stefan.agner@toradex.com> Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com> Acked-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-10-02ARM: dts: imx7ulp: remove mipi pll clock nodeFancy Fang1-13/+4
According to the IMX7ULP reference manual, the mipi pll clock comes from the MIPI PHY PLL output. So it should not be defined as a fixed clock. So remove this clock node and all the references to it. Signed-off-by: Fancy Fang <chen.fang@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-10-02ARM: dts: vf610-zii-scu4-aib: Drop "rs485-rts-delay" propertyAndrey Smirnov1-2/+0
LPUART driver does not support specifying "rs485-rts-delay" property. Drop it. Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Chris Healy <cphealy@gmail.com> Cc: Fabio Estevam <festevam@gmail.com> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-10-02ARM: dts: opos6ul/opos6uldev: rework device tree to support i.MX6ULLSébastien Szymanski7-565/+547
Rework the device trees of the OPOS6UL and OPOS6ULDev boards to support the OPOS6UL SoM with an i.MX6ULL SoC. The device trees are now as following: - imx6ul-imx6ull-opos6ul.dtsi common for both i.MX6UL and i.MX6ULL OPOS6UL SoM. - imx6ul-opos6ul.dtsi for i.MX6UL OPOS6UL SoM. It includes imx6ul.dtsi and imx6ul-imx6ull-opos6ul.dtsi. - imx6ull-opos6ul.dtsi for i.MX6ULL OPOS6UL SoM. It includes imx6ull.dtsi and imx6ul-imx6ull-opos6ul.dtsi. - imx6ul-imx6ull-opos6uldev.dtsi OPOS6ULDev base device tree. - imx6ul-opos6uldev.dts OPOS6ULDev board with an i.MX6UL OPOS6UL SoM. It includes imx6ul-opos6ul.dtsi and imx6ul-imx6ull-opos6uldevdtsi. - imx6ull-opos6uldev.dts OPOS6ULDev board with an i.MX6ULL OPOS6UL SoM. It includes imx6ull-opos6ul.dtsi and imx6ul-imx6ull-opos6uldevdtsi. Signed-off-by: Sébastien Szymanski <sebastien.szymanski@armadeus.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-10-01riscv: Fix memblock reservation for device tree blobAlbert Ou1-1/+11
This fixes an error with how the FDT blob is reserved in memblock. An incorrect physical address calculation exposed the FDT header to unintended corruption, which typically manifested with of_fdt_raw_init() faulting during late boot after fdt_totalsize() returned a wrong value. Systems with smaller physical memory sizes more frequently trigger this issue, as the kernel is more likely to allocate from the DMA32 zone where bbl places the DTB after the kernel image. Commit 671f9a3e2e24 ("RISC-V: Setup initial page tables in two stages") changed the mapping of the DTB to reside in the fixmap area. Consequently, early_init_fdt_reserve_self() cannot be used anymore in setup_bootmem() since it relies on __pa() to derive a physical address, which does not work with dtb_early_va that is no longer a valid kernel logical address. The reserved[0x1] region shows the effect of the pointer underflow resulting from the __pa(initial_boot_params) offset subtraction: [ 0.000000] MEMBLOCK configuration: [ 0.000000] memory size = 0x000000001fe00000 reserved size = 0x0000000000a2e514 [ 0.000000] memory.cnt = 0x1 [ 0.000000] memory[0x0] [0x0000000080200000-0x000000009fffffff], 0x000000001fe00000 bytes flags: 0x0 [ 0.000000] reserved.cnt = 0x2 [ 0.000000] reserved[0x0] [0x0000000080200000-0x0000000080c2dfeb], 0x0000000000a2dfec bytes flags: 0x0 [ 0.000000] reserved[0x1] [0xfffffff080100000-0xfffffff080100527], 0x0000000000000528 bytes flags: 0x0 With the fix applied: [ 0.000000] MEMBLOCK configuration: [ 0.000000] memory size = 0x000000001fe00000 reserved size = 0x0000000000a2e514 [ 0.000000] memory.cnt = 0x1 [ 0.000000] memory[0x0] [0x0000000080200000-0x000000009fffffff], 0x000000001fe00000 bytes flags: 0x0 [ 0.000000] reserved.cnt = 0x2 [ 0.000000] reserved[0x0] [0x0000000080200000-0x0000000080c2dfeb], 0x0000000000a2dfec bytes flags: 0x0 [ 0.000000] reserved[0x1] [0x0000000080e00000-0x0000000080e00527], 0x0000000000000528 bytes flags: 0x0 Fixes: 671f9a3e2e24 ("RISC-V: Setup initial page tables in two stages") Signed-off-by: Albert Ou <aou@eecs.berkeley.edu> Tested-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Anup Patel <anup@brainfault.org> Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com>
2019-10-01RISC-V: Clear load reservations while restoring hart contextsPalmer Dabbelt2-1/+21
This is almost entirely a comment. The bug is unlikely to manifest on existing hardware because there is a timeout on load reservations, but manifests on QEMU because there is no timeout. Signed-off-by: Palmer Dabbelt <palmer@sifive.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com>
2019-10-01x86/realmode: Explicitly set entry point via ENTRY in linker scriptNick Desaulniers1-0/+1
Linking with ld.lld via $ make LD=ld.lld produces the warning: ld.lld: warning: cannot find entry symbol _start; defaulting to 0x1000 Linking with ld.bfd shows the default entry is 0x1000: $ readelf -h arch/x86/realmode/rm/realmode.elf | grep Entry Entry point address: 0x1000 While ld.lld is being pedantic, just set the entry point explicitly, instead of depending on the implicit default. The symbol pa_text_start refers to the start of the .text section, which may not be at 0x1000 if the preceding sections listed in arch/x86/realmode/rm/realmode.lds.S were large enough. This matches behavior in arch/x86/boot/setup.ld. Reported-by: Sedat Dilek <sedat.dilek@gmail.com> Suggested-by: Borislav Petkov <bp@alien8.de> Suggested-by: Peter Smith <Peter.Smith@arm.com> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Borislav Petkov <bp@suse.de> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: clang-built-linux@googlegroups.com Cc: grimar@accesssoftek.com Cc: Ingo Molnar <mingo@redhat.com> Cc: maskray@google.com Cc: ruiu@google.com Cc: Thomas Gleixner <tglx@linutronix.de> Cc: x86-ml <x86@kernel.org> Link: https://lkml.kernel.org/r/20190925180908.54260-1-ndesaulniers@google.com Link: https://github.com/ClangBuiltLinux/linux/issues/216
2019-10-01MIPS: cpu-bugs64: Mark inline functions as __always_inlineJiaxun Yang1-6/+8
Commit ac7c3e4ff401 ("compiler: enable CONFIG_OPTIMIZE_INLINING forcibly") allows compiler to uninline functions marked as 'inline'. Leading to section mismatch in this case. Since we're using const variables to pass assembly flags, 'inline's can't be dropped. So we simply mark them as __always_inline. Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Cc: linux-mips@vger.kernel.org [paul.burton@mips.com: - Annotate these functions with __init, even if it only serves to inform human readers when the code can be used. - Drop the __always_inline from check_daddi() & check_daddiu() which don't use arguments as immediates in inline asm. - Rewrap the commit message.] Signed-off-by: Paul Burton <paul.burton@mips.com>
2019-10-01ARM: xen: unexport HYPERVISOR_platform_op functionStefano Stabellini1-1/+1
HYPERVISOR_platform_op() is an inline function and should not be exported. Since commit 15bfc2348d54 ("modpost: check for static EXPORT_SYMBOL* functions"), this causes a warning: WARNING: "HYPERVISOR_platform_op" [vmlinux] is a static EXPORT_SYMBOL_GPL Instead, export the underlying function called by the static inline: HYPERVISOR_platform_op_raw. Fixes: 15bfc2348d54 ("modpost: check for static EXPORT_SYMBOL* functions") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com> Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
2019-10-01arm64: dts: exynos: Rename Multi Core Timer node to "timer" on Exynos5433Krzysztof Kozlowski1-1/+1
The device node name should reflect generic class of a device so rename the Multi Core Timer node from "mct" to "timer". This will be also in sync with upcoming DT schema. No functional change. Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2019-10-01arm64: dts: exynos: Split phandle in dmas property on Exynos5433Maciej Falkowski1-2/+2
Change representation of phandle array as then dt-schema counts number of its items properly. Signed-off-by: Maciej Falkowski <m.falkowski@samsung.com> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2019-10-01arm64: dts: exynos: Swap clock order of sysmmu on Exynos5433Maciej Falkowski1-27/+27
dt-schema supports only order of names "aclk", "pclk". Swap some sysmmu definitions to make them compatible with schema. Signed-off-by: Maciej Falkowski <m.falkowski@samsung.com> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2019-10-01arm64: dts: exynos: Revert "Remove unneeded address space mapping for soc node"Marek Szyprowski2-6/+6
Commit ef72171b3621 ("arm64: dts: exynos: Remove unneeded address space mapping for soc node") changed the address and size cells in root node from 2 to 1, but /memory nodes for the affected boards were not updated. This went unnoticed on Exynos5433-based TM2(e) boards, because they use u-boot, which updates /memory node to the correct values. On the other hand, the mentioned commit broke boot on Exynos7-based Espresso board, which bootloader doesn't touch /memory node at all. This patch reverts commit ef72171b3621 ("arm64: dts: exynos: Remove unneeded address space mapping for soc node"), so Exynos5433 and Exynos7 SoCs again matches other ARM64 platforms with 64bit mappings in root node. Reported-by: Alim Akhtar <alim.akhtar@samsung.com> Fixes: ef72171b3621 ("arm64: dts: exynos: Remove unneeded address space mapping for soc node") Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Cc: <stable@vger.kernel.org> # 5.3.x: 72ddcf6aa224 arm64: dts: exynos: Move GPU under /soc node for Exynos5433 Cc: <stable@vger.kernel.org> # 5.3.x: ede87c3a2bdb arm64: dts: exynos: Move GPU under /soc node for Exynos7 Cc: <stable@vger.kernel.org> # 4.18.x Tested-by: Alim Akhtar <alim.akhtar@samsung.com> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2019-10-01arm64: dts: exynos: Move GPU under /soc node for Exynos7Marek Szyprowski1-11/+11
Mali GPU hardware module is a standard hardware module integrated to Exynos7 SoCs, so it should reside under the "/soc" node. The only SoC components which are placed in the DT root, are those, which are a part of CPUs: like ARM architected timers and ARM performance measurement units. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com> Tested-by: Alim Akhtar <alim.akhtar@samsung.com> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2019-10-01arm64: dts: exynos: Move GPU under /soc node for Exynos5433Marek Szyprowski1-51/+51
Mali GPU hardware module is a standard hardware module integrated to Exynos5433 SoCs, so it should reside under the "/soc" node. The only SoC components which are placed in the DT root, are those, which are a part of CPUs: like ARM architected timers and ARM performance measurement units. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2019-10-01x86: Use the correct SPDX License Identifier in headersNishad Kamdar3-3/+3
Correct the SPDX License Identifier format in a couple of headers. Suggested-by: Joe Perches <joe@perches.com> Signed-off-by: Nishad Kamdar <nishadkamdar@gmail.com> Signed-off-by: Borislav Petkov <bp@suse.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Sean Christopherson <sean.j.christopherson@intel.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Cc: Waiman Long <longman@redhat.com> Cc: x86-ml <x86@kernel.org> Link: https://lkml.kernel.org/r/697848ff866ade29e78e872525d7a3067642fd37.1555427420.git.nishadkamdar@gmail.com
2019-10-01ARM: dts: exynos: Add DMC device to Exynos5422 and Odroid XU3-family boardsLukasz Luba2-0/+188
Add description of Dynamic Memory Controller and PPMU counters to Exynos5422 and Odroid XU3/XU4/HC1 boards. They are used by exynos5422-dmc driver. There is a definition of the memory chip, which is then used during calculation of timings for each OPP. The algorithm in the driver needs these two sets to bound the timings. Signed-off-by: Lukasz Luba <l.luba@partner.samsung.com> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2019-10-01ARM: dts: exynos: Add syscon compatible to clock controller on Exynos542xLukasz Luba2-2/+2
In order to get the clock by phandle and use it with regmap it needs to be compatible with syscon. The DMC driver uses two registers from clock register set and needs the regmap of them. Signed-off-by: Lukasz Luba <l.luba@partner.samsung.com> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2019-10-01ARM: dts: ux500: Fix up the CPU thermal zoneLinus Walleij1-3/+8
This fixes up the default ux500 CPU thermal zone: - Set polling delay to 0 and explain why - Set passive polling delay to 250 - Remove restrictions from the CPU cooling device, we should use all cpufreq steps to cool down if needed. Link: https://lore.kernel.org/r/20191001074628.8122-1-linus.walleij@linaro.org Fixes: b786a05f6ce4 ("ARM: dts: ux500: Update thermal zone") Suggested-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Olof Johansson <olof@lixom.net>
2019-10-01x86/rdrand: Sanity-check RDRAND outputBorislav Petkov1-1/+21
It turned out recently that on certain AMD F15h and F16h machines, due to the BIOS dropping the ball after resume, yet again, RDRAND would not function anymore: c49a0a80137c ("x86/CPU/AMD: Clear RDRAND CPUID bit on AMD family 15h/16h") Add a silly test to the CPU bringup path, to sanity-check the random data RDRAND returns and scream as loudly as possible if that returned random data doesn't change. Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Borislav Petkov <bp@suse.de> Cc: Pu Wen <puwen@hygon.cn> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: x86-ml <x86@kernel.org> Link: https://lkml.kernel.org/r/CAHk-=wjWPDauemCmLTKbdMYFB0UveMszZpcrwoUkJRRWKrqaTw@mail.gmail.com
2019-10-01x86/microcode/intel: Issue the revision updated message only on the BSPBorislav Petkov1-2/+3
... in order to not pollute dmesg with a line for each updated microcode engine. Signed-off-by: Borislav Petkov <bp@suse.de> Cc: Ashok Raj <ashok.raj@intel.com> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jon Grimm <Jon.Grimm@amd.com> Cc: kanth.ghatraju@oracle.com Cc: konrad.wilk@oracle.com Cc: Mihai Carabas <mihai.carabas@oracle.com> Cc: patrick.colp@oracle.com Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: x86-ml <x86@kernel.org> Link: https://lkml.kernel.org/r/20190824085341.GC16813@zn.tnic
2019-10-01x86/microcode: Update late microcode in parallelAshok Raj1-15/+21
Microcode update was changed to be serialized due to restrictions after Spectre days. Updating serially on a large multi-socket system can be painful since it is being done on one CPU at a time. Cloud customers have expressed discontent as services disappear for a prolonged time. The restriction is that only one core (or only one thread of a core in the case of an SMT system) goes through the update while other cores (or respectively, SMT threads) are quiesced. Do the microcode update only on the first thread of each core while other siblings simply wait for this to complete. [ bp: Simplify, massage, cleanup comments. ] Signed-off-by: Ashok Raj <ashok.raj@intel.com> Signed-off-by: Mihai Carabas <mihai.carabas@oracle.com> Signed-off-by: Borislav Petkov <bp@suse.de> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jon Grimm <Jon.Grimm@amd.com> Cc: kanth.ghatraju@oracle.com Cc: konrad.wilk@oracle.com Cc: patrick.colp@oracle.com Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: x86-ml <x86@kernel.org> Link: https://lkml.kernel.org/r/1566506627-16536-2-git-send-email-mihai.carabas@oracle.com
2019-10-01kvm: vmx: Limit guest PMCs to those supported on the hostJim Mattson1-2/+5
KVM can only virtualize as many PMCs as the host supports. Limit the number of generic counters and fixed counters to the number of corresponding counters supported on the host, rather than to INTEL_PMC_MAX_GENERIC and INTEL_PMC_MAX_FIXED, respectively. Note that INTEL_PMC_MAX_GENERIC is currently 32, which exceeds the 18 contiguous MSR indices reserved by Intel for event selectors. Since the existing code relies on a contiguous range of MSR indices for event selectors, it can't possibly work for more than 18 general purpose counters. Fixes: f5132b01386b5a ("KVM: Expose a version 2 architectural PMU to a guests") Signed-off-by: Jim Mattson <jmattson@google.com> Reviewed-by: Marc Orr <marcorr@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-10-01crypto: arm/aes-ce - add dependency on AES libraryArd Biesheuvel1-0/+1
The ARM accelerated AES driver depends on the new AES library for its non-SIMD fallback so express this in its Kconfig declaration. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-10-01crypto: arm/aes-ce - build for v8 architecture explicitlyArd Biesheuvel1-0/+1
The NEON/Crypto Extensions based AES implementation for 32-bit ARM can be built in a kernel that targets ARMv6 CPUs and higher, even though the actual code will not be able to run on that generation, but it allows for a portable image to be generated that can will use the special instructions only when they are available. Since those instructions are part of a FPU profile rather than a CPU profile, we don't override the architecture in the assembler code, and most of the scalar code is simple enough to be ARMv6 compatible. However, that changes with commit c61b1607ed4fbbf2, which introduces calls to the movw/movt instructions, which are v7+ only. So override the architecture in the .S file to armv8-a, which matches the architecture specification in the crypto-neon-fp-armv8 FPU specificier that we already using. Note that using armv7-a here may trigger an issue with the upcoming Clang 10 release, which no longer permits .arch/.fpu combinations it views as incompatible. Reported-by: kbuild test robot <lkp@intel.com> Fixes: c61b1607ed4fbbf2 ("crypto: arm/aes-ce - implement ciphertext stealing ...") Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-10-01arm64/sve: Fix wrong free for task->thread.sve_stateMasayoshi Mizuma1-17/+15
The system which has SVE feature crashed because of the memory pointed by task->thread.sve_state was destroyed by someone. That is because sve_state is freed while the forking the child process. The child process has the pointer of sve_state which is same as the parent's because the child's task_struct is copied from the parent's one. If the copy_process() fails as an error on somewhere, for example, copy_creds(), then the sve_state is freed even if the parent is alive. The flow is as follows. copy_process p = dup_task_struct => arch_dup_task_struct *dst = *src; // copy the entire region. : retval = copy_creds if (retval < 0) goto bad_fork_free; : bad_fork_free: ... delayed_free_task(p); => free_task => arch_release_task_struct => fpsimd_release_task => __sve_free => kfree(task->thread.sve_state); // free the parent's sve_state Move child's sve_state = NULL and clearing TIF_SVE flag to arch_dup_task_struct() so that the child doesn't free the parent's one. There is no need to wait until copy_process() to clear TIF_SVE for dst, because the thread flags for dst are initialized already by copying the src task_struct. This change simplifies the code, so get rid of comments that are no longer needed. As a note, arm64 used to have thread_info on the stack. So it would not be possible to clear TIF_SVE until the stack is initialized. From commit c02433dd6de3 ("arm64: split thread_info from task stack"), the thread_info is part of the task, so it should be valid to modify the flag from arch_dup_task_struct(). Cc: stable@vger.kernel.org # 4.15.x- Fixes: bc0ee4760364 ("arm64/sve: Core task context handling") Signed-off-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com> Reported-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> Suggested-by: Dave Martin <Dave.Martin@arm.com> Reviewed-by: Dave Martin <Dave.Martin@arm.com> Tested-by: Julien Grall <julien.grall@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
2019-10-01arm64: errata: Update stale commentThierry Reding1-2/+2
Commit 73f381660959 ("arm64: Advertise mitigation of Spectre-v2, or lack thereof") renamed the caller of the install_bp_hardening_cb() function but forgot to update a comment, which can be confusing when trying to follow the code flow. Fixes: 73f381660959 ("arm64: Advertise mitigation of Spectre-v2, or lack thereof") Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Will Deacon <will@kernel.org>
2019-10-01x86/mce: Add Zhaoxin LMCE supportTony W Wang-oc3-4/+26
Newer Zhaoxin CPUs support LMCE compatible with Intel. Add support for that. [ bp: Export functions and massage. ] Signed-off-by: Tony W Wang-oc <TonyWWang-oc@zhaoxin.com> Signed-off-by: Borislav Petkov <bp@suse.de> Cc: CooperYan@zhaoxin.com Cc: DavidWang@zhaoxin.com Cc: HerryYang@zhaoxin.com Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: linux-edac <linux-edac@vger.kernel.org> Cc: QiyuanWang@zhaoxin.com Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Tony Luck <tony.luck@intel.com> Cc: x86-ml <x86@kernel.org> Link: https://lkml.kernel.org/r/1568787573-1297-5-git-send-email-TonyWWang-oc@zhaoxin.com
2019-10-01x86/mce: Add Zhaoxin CMCI supportTony W Wang-oc3-2/+33
All newer Zhaoxin CPUs support CMCI and are compatible with Intel's Machine-Check Architecture. Add that support for Zhaoxin CPUs. [ bp: Massage comments and export intel_init_cmci(). ] Signed-off-by: Tony W Wang-oc <TonyWWang-oc@zhaoxin.com> Signed-off-by: Borislav Petkov <bp@suse.de> Cc: CooperYan@zhaoxin.com Cc: DavidWang@zhaoxin.com Cc: HerryYang@zhaoxin.com Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: linux-edac <linux-edac@vger.kernel.org> Cc: QiyuanWang@zhaoxin.com Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Tony Luck <tony.luck@intel.com> Cc: x86-ml <x86@kernel.org> Link: https://lkml.kernel.org/r/1568787573-1297-4-git-send-email-TonyWWang-oc@zhaoxin.com
2019-10-01x86/mce: Add Zhaoxin MCE supportTony W Wang-oc1-13/+31
All newer Zhaoxin CPUs are compatible with Intel's Machine-Check Architecture, so add support for them. [ bp: Reflow comment in vendor_disable_error_reporting() and massage commit message. ] Signed-off-by: Tony W Wang-oc <TonyWWang-oc@zhaoxin.com> Signed-off-by: Borislav Petkov <bp@suse.de> Cc: CooperYan@zhaoxin.com Cc: DavidWang@zhaoxin.com Cc: HerryYang@zhaoxin.com Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: linux-edac <linux-edac@vger.kernel.org> Cc: QiyuanWang@zhaoxin.com Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Tony Luck <tony.luck@intel.com> Cc: x86-ml <x86@kernel.org> Link: https://lkml.kernel.org/r/1568787573-1297-2-git-send-email-TonyWWang-oc@zhaoxin.com
2019-10-01x86/insn: Fix awk regexp warningsAlexander Kapshuk1-2/+2
gawk 5.0.1 generates the following regexp warnings: GEN /home/sasha/torvalds/tools/objtool/arch/x86/lib/inat-tables.c awk: ../arch/x86/tools/gen-insn-attr-x86.awk:260: warning: regexp escape sequence `\:' is not a known regexp operator awk: ../arch/x86/tools/gen-insn-attr-x86.awk:350: (FILENAME=../arch/x86/lib/x86-opcode-map.txt FNR=41) warning: regexp escape sequence `\&' is not a known regexp operator Ealier versions of gawk are not known to generate these warnings. The gawk manual referenced below does not list characters ':' and '&' as needing escaping, so 'unescape' them. See https://www.gnu.org/software/gawk/manual/html_node/Escape-Sequences.html for more info. Running diff on the output generated by the script before and after applying the patch reported no differences. [ bp: Massage commit message. ] [ Caught the respective tools header discrepancy. ] Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Alexander Kapshuk <alexander.kapshuk@gmail.com> Signed-off-by: Borislav Petkov <bp@suse.de> Acked-by: Masami Hiramatsu <mhiramat@kernel.org> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: x86-ml <x86@kernel.org> Link: https://lkml.kernel.org/r/20190924044659.3785-1-alexander.kapshuk@gmail.com
2019-10-01x86/mce/amd: Make disable_err_thresholding() staticBorislav Petkov1-1/+1
No functional changes. Signed-off-by: Borislav Petkov <bp@suse.de> Cc: x86@kernel.org Link: https://lkml.kernel.org/r/20190928170539.2729-1-bp@alien8.de
2019-10-01x86/microcode/amd: Fix two -Wunused-but-set-variable warningsBorislav Petkov1-2/+2
The dummy variable is the high part of the microcode revision MSR which is defined as reserved. Mark it unused so that W=1 builds don't trigger the above warning. No functional changes. Signed-off-by: Borislav Petkov <bp@suse.de> Cc: x86@kernel.org Link: https://lkml.kernel.org/r/20190928162559.26294-1-bp@alien8.de
2019-10-01arch/x86/boot: Use prefix map to avoid embedded pathsBruce Ashfield2-0/+2
It was observed that the kernel embeds the absolute build path in the x86 boot image when the __FILE__ macro is expanded. > From https://bugzilla.yoctoproject.org/show_bug.cgi?id=13458: If you turn on the buildpaths QA test, or try a reproducible build, you discover that the kernel image contains build paths. $ strings bzImage-5.0.19-yocto-standard |grep tmp/ out of pgt_buf in /data/poky-tmp/reproducible/tmp/work-shared/qemux86-64/kernel-source/arch/x86/boot/compressed/kaslr_64.c!? But what's this in the top-level Makefile: $ git grep prefix-map Makefile:KBUILD_CFLAGS += $(call cc-option,-fmacro-prefix-map=$(srctree)/=) So the __FILE__ shouldn't be using the full path. However arch/x86/boot/compressed/Makefile has this: KBUILD_CFLAGS := -m$(BITS) -O2 So that clears KBUILD_FLAGS, removing the -fmacro-prefix-map option. Use -fmacro-prefix-map to have relative paths in the boot image too. [ bp: Massage commit message and put the KBUILD_CFLAGS addition in ..boot/Makefile after the KBUILD_AFLAGS assignment because gas doesn't support -fmacro-prefix-map. ] Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Borislav Petkov <bp@suse.de> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: George Rimar <grimar@accesssoftek.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Nathan Chancellor <natechancellor@gmail.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: x86-ml <x86@kernel.org> Link: https://lkml.kernel.org/r/20190926093226.8568-1-ross.burton@intel.com Link: https://bugzilla.kernel.org/show_bug.cgi?id=204333
2019-10-01x86/nmi: Remove stale EDAC include leftoverBorislav Petkov1-5/+0
db47d5f85646 ("x86/nmi, EDAC: Get rid of DRAM error reporting thru PCI SERR NMI") forgot to remove it. Drop it. Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lkml.kernel.org/r/20190923193807.30896-1-bp@alien8.de
2019-10-01arm64: defconfig: Enable R8A774B1 SoCBiju Das1-0/+1
Enable the Renesas RZ/G2N (R8A774B1) SoC in the ARM64 defconfig. Signed-off-by: Biju Das <biju.das@bp.renesas.com> Link: https://lore.kernel.org/r/1568725530-55241-3-git-send-email-biju.das@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2019-10-01ARM: dts: emev2: Add whitespace for GPIO nodesMagnus Damm1-0/+4
It turns out that the GPIO nodes for EMEV2 are missing whitespace, so focus on what is important in life and adjust the coding style to match the rest of the code base. Signed-off-by: Magnus Damm <damm+renesas@opensource.se> Link: https://lore.kernel.org/r/156877169225.29395.9771334507494949542.sendpatchset@octo Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2019-10-01ARM: dts: lager: Replace spaces by TABsGeert Uytterhoeven1-4/+4
Make it easier to compare the file with other similar files. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Link: https://lore.kernel.org/r/20190904120114.1894-3-geert+renesas@glider.be
2019-10-01ARM: dts: gose: Replace spaces by TABsGeert Uytterhoeven1-55/+55
Make it easier to compare the file with other similar files. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Link: https://lore.kernel.org/r/20190904120114.1894-2-geert+renesas@glider.be
2019-10-01arm64: dts: renesas: Add HiHope RZ/G2N main board supportBiju Das2-0/+27
Basic support for the HiHope RZ/G2N main board: - Memory, - Main crystal, - Serial console Signed-off-by: Biju Das <biju.das@bp.renesas.com> Link: https://lore.kernel.org/r/1568725530-55241-5-git-send-email-biju.das@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2019-10-01arm64: dts: renesas: Initial r8a774b1 SoC device treeBiju Das1-0/+472
Basic support for the RZ/G2N (R8A774B1) SoC. Added placeholders to avoid compilation error with the common platform code. Signed-off-by: Biju Das <biju.das@bp.renesas.com> Link: https://lore.kernel.org/r/1569589584-56917-1-git-send-email-biju.das@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2019-10-01arm64: dts: renesas: r8a774c0: Add dynamic power coefficientBiju Das1-0/+1
Describe the dynamic power coefficient of A53 CPUs. Based on work by Gaku Inami <gaku.inami.xw@bp.renesas.com> and others. Signed-off-by: Biju Das <biju.das@bp.renesas.com> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Link: https://lore.kernel.org/r/1568364608-46548-2-git-send-email-biju.das@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2019-10-01arm64: dts: renesas: r8a774c0: Create thermal zone to support IPABiju Das1-3/+16
Setup a thermal zone driven by SoC temperature sensor. Create passive trip points and bind them to CPUFreq cooling device that supports power extension. Based on the work done by Dien Pham <dien.pham.ry@renesas.com> and others for r8a77990 SoC. Signed-off-by: Biju Das <biju.das@bp.renesas.com> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Link: https://lore.kernel.org/r/1568364608-46548-1-git-send-email-biju.das@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2019-10-01arm64: dts: renesas: r8a77970: Fix PWM3Kieran Bingham1-1/+1
The pwm3 was incorrectly added with a compatible reference to the renesas,pwm-r8a7790 (H2) due to a single characther ommision. Fix the compatible string. Fixes: de625477c632 ("arm64: dts: renesas: r8a779{7|8}0: add PWM support") Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Link: https://lore.kernel.org/r/20190912103143.985-1-kieran.bingham+renesas@ideasonboard.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>