summaryrefslogtreecommitdiffstats
path: root/arch/arm64
Commit message (Collapse)AuthorAgeFilesLines
* arm64: dts: exynos: Revert "Remove unneeded address space mapping for soc node"Marek Szyprowski2019-12-132-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | commit bed903167ae5b5532eda5d7db26de451bd232da5 upstream. 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> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* arm64: dts: meson-gxl-khadas-vim: fix GPIO lines namesNeil Armstrong2019-12-131-2/+2
| | | | | | | | | | | | | [ Upstream commit 5b78012636f537344bd551934387f5772c38ba80 ] The gpio line names were set in the pinctrl node instead of the gpio node, at the time it was merged, it worked, but was obviously wrong. This patch moves the properties to the gpio nodes. Fixes: 60795933b709 ("ARM64: dts: meson-gxl-khadas-vim: Add GPIO lines names") Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* arm64: dts: meson-gxbb-odroidc2: fix GPIO lines namesNeil Armstrong2019-12-131-2/+2
| | | | | | | | | | | | | [ Upstream commit 2165b006b65d609140dafafcb14cce5a4aaacbab ] The gpio line names were set in the pinctrl node instead of the gpio node, at the time it was merged, it worked, but was obviously wrong. This patch moves the properties to the gpio nodes. Fixes: b03c7d6438bb ("ARM64: dts: meson-gxbb-odroidc2: Add GPIO lines names") Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* arm64: dts: meson-gxbb-nanopi-k2: fix GPIO lines namesNeil Armstrong2019-12-131-2/+2
| | | | | | | | | | | | | [ Upstream commit f0783f5edb52af14ecaae6c5ce4f38e0a358f5d8 ] The gpio line names were set in the pinctrl node instead of the gpio node, at the time it was merged, it worked, but was obviously wrong. This patch moves the properties to the gpio nodes. Fixes: 12ada0513d7a ("ARM64: dts: meson-gxbb-nanopi-k2: Add GPIO lines names") Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* arm64: dts: meson-gxl-libretech-cc: fix GPIO lines namesNeil Armstrong2019-12-131-2/+2
| | | | | | | | | | | | | [ Upstream commit 11fa9774612decea87144d7f950a9c53a4fe3050 ] The gpio line names were set in the pinctrl node instead of the gpio node, at the time it was merged, it worked, but was obviously wrong. This patch moves the properties to the gpio nodes. Fixes: 47884c5c746e ("ARM64: dts: meson-gxl-libretech-cc: Add GPIO lines names") Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* arm64: dts: zynqmp: Fix node names which contain "_"Michal Simek2019-12-136-13/+13
| | | | | | | | | | | | | | | [ Upstream commit d1d4445abffb2b17e841d37b555b6f1364b571c1 ] s/_/-/ for node names. It fixes warnings like this: ... Warning (node_name_chars_strict): /cpu_opp_table: Character '_' not recommended in node name ... Issues reported by make dtbs W=12 Signed-off-by: Michal Simek <michal.simek@xilinx.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* arm64: tegra: Fix 'active-low' warning for Jetson TX1 regulatorJon Hunter2019-12-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | commit 1e5e929c009559bd7e898ac8e17a5d01037cb057 upstream. Commit 34993594181d ("arm64: tegra: Enable HDMI on Jetson TX1") added a regulator for HDMI on the Jetson TX1 platform. This regulator has an active high enable, but the GPIO specifier for enabling the regulator incorrectly defines it as active-low. This causes the following warning to occur on boot ... WARNING KERN regulator@10 GPIO handle specifies active low - ignored The fixed-regulator binding does not use the active-low flag from the gpio specifier and purely relies of the presence of the 'enable-active-high' property to determine if it is active high or low (if this property is omitted). Fix this warning by setting the GPIO to active-high in the GPIO specifier which aligns with the presense of the 'enable-active-high' property. Fixes: 34993594181d ("arm64: tegra: Enable HDMI on Jetson TX1") Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* arm64: dts: renesas: draak: Fix CVBS inputLaurent Pinchart2019-12-051-1/+1
| | | | | | | | | | | | | [ Upstream commit 6f61a2c8f1f6163c7e08c77c5f71df0427e4d2f6 ] A typo in the adv7180 DT node prevents successful probing of the VIN. Fix it. Fixes: 6a0942c20f5c ("arm64: dts: renesas: draak: Describe CVBS input") Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Acked-by: Jacopo Mondi <jacopo+renesas@jmondi.org> Signed-off-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
* arm64: preempt: Fix big-endian when checking preempt count in assemblyWill Deacon2019-12-052-9/+5
| | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 7faa313f05cad184e8b17750f0cbe5216ac6debb ] Commit 396244692232 ("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> Signed-off-by: Sasha Levin <sashal@kernel.org>
* arm64: smp: Handle errors reported by the firmwareSuzuki K Poulose2019-12-051-0/+1
| | | | | | | | | | | | | | | | [ Upstream commit f357b3a7e17af7736d67d8267edc1ed3d1dd9391 ] The __cpu_up() routine ignores the errors reported by the firmware for a CPU bringup operation and looks for the error status set by the booting CPU. If the CPU never entered the kernel, we could end up in assuming stale error status, which otherwise would have been set/cleared appropriately by the booting CPU. Reported-by: Steve Capper <steve.capper@arm.com> Cc: Will Deacon <will.deacon@arm.com> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* arm64: mm: Prevent mismatched 52-bit VA supportSteve Capper2019-12-052-0/+31
| | | | | | | | | | | | | | | | | | | | | | [ Upstream commit a96a33b1ca57dbea4285893dedf290aeb8eb090b ] For cases where there is a mismatch in ARMv8.2-LVA support between CPUs we have to be careful in allowing secondary CPUs to boot if 52-bit virtual addresses have already been enabled on the boot CPU. This patch adds code to the secondary startup path. If the boot CPU has enabled 52-bit VAs then ID_AA64MMFR2_EL1 is checked to see if the secondary can also enable 52-bit support. If not, the secondary is prevented from booting and an error message is displayed indicating why. Technically this patch could be implemented using the cpufeature code when considering 52-bit userspace support. However, we employ low level checks here as the cpufeature code won't be able to run if we have mismatched 52-bit kernel va support. Signed-off-by: Steve Capper <steve.capper@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* arm64: makefile fix build of .i file in external module caseVictor Kamensky2019-12-011-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 98356eb0ae499c63e78073ccedd9a5fc5c563288 ] After 'a66649dab350 arm64: fix vdso-offsets.h dependency' if one will try to build .i file in case of external kernel module, build fails complaining that prepare0 target is missing. This issue came up with SystemTap when it tries to build variety of .i files for its own generated kernel modules trying to figure given kernel features/capabilities. The issue is that prepare0 is defined in top level Makefile only if KBUILD_EXTMOD is not defined. .i file rule depends on prepare and in case KBUILD_EXTMOD defined top level Makefile contains empty rule for prepare. But after mentioned commit arch/arm64/Makefile would introduce dependency on prepare0 through its own prepare target. Fix it to put proper ifdef KBUILD_EXTMOD around code introduced by mentioned commit. It matches what top level Makefile does. Acked-by: Kevin Brodsky <kevin.brodsky@arm.com> Signed-off-by: Victor Kamensky <kamensky@cisco.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* arm64: lib: use C string functions with KASAN enabledAndrey Ryabinin2019-12-0110-16/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 19a2ca0fb560fd7be7b5293c6b652c6d6078dcde ] ARM64 has asm implementation of memchr(), memcmp(), str[r]chr(), str[n]cmp(), str[n]len(). KASAN don't see memory accesses in asm code, thus it can potentially miss many bugs. Ifdef out __HAVE_ARCH_* defines of these functions when KASAN is enabled, so the generic implementations from lib/string.c will be used. We can't just remove the asm functions because efistub uses them. And we can't have two non-weak functions either, so declare the asm functions as weak. Link: http://lkml.kernel.org/r/20180920135631.23833-2-aryabinin@virtuozzo.com Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com> Reported-by: Kyeongdon Kim <kyeongdon.kim@lge.com> Cc: Alexander Potapenko <glider@google.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* arm64/numa: Report correct memblock range for the dummy nodeAnshuman Khandual2019-11-241-1/+1
| | | | | | | | | | | | | | | [ Upstream commit 77cfe950901e5c13aca2df6437a05f39dd9a929b ] The dummy node ID is marked into all memory ranges on the system. So the dummy node really extends the entire memblock.memory. Hence report correct extent information for the dummy node using memblock range helper functions instead of the range [0LLU, PFN_PHYS(max_pfn) - 1)]. Fixes: 1a2db30034 ("arm64, numa: Add NUMA support for arm64 platforms") Acked-by: Punit Agrawal <punit.agrawal@arm.com> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* arm64: uaccess: Ensure PAN is re-enabled after unhandled uaccess faultPavel Tatashin2019-11-244-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 94bb804e1e6f0a9a77acf20d7c70ea141c6c821e upstream. A number of our uaccess routines ('__arch_clear_user()' and '__arch_copy_{in,from,to}_user()') fail to re-enable PAN if they encounter an unhandled fault whilst accessing userspace. For CPUs implementing both hardware PAN and UAO, this bug has no effect when both extensions are in use by the kernel. For CPUs implementing hardware PAN but not UAO, this means that a kernel using hardware PAN may execute portions of code with PAN inadvertently disabled, opening us up to potential security vulnerabilities that rely on userspace access from within the kernel which would usually be prevented by this mechanism. In other words, parts of the kernel run the same way as they would on a CPU without PAN implemented/emulated at all. For CPUs not implementing hardware PAN and instead relying on software emulation via 'CONFIG_ARM64_SW_TTBR0_PAN=y', the impact is unfortunately much worse. Calling 'schedule()' with software PAN disabled means that the next task will execute in the kernel using the page-table and ASID of the previous process even after 'switch_mm()', since the actual hardware switch is deferred until return to userspace. At this point, or if there is a intermediate call to 'uaccess_enable()', the page-table and ASID of the new process are installed. Sadly, due to the changes introduced by KPTI, this is not an atomic operation and there is a very small window (two instructions) where the CPU is configured with the page-table of the old task and the ASID of the new task; a speculative access in this state is disastrous because it would corrupt the TLB entries for the new task with mappings from the previous address space. As Pavel explains: | I was able to reproduce memory corruption problem on Broadcom's SoC | ARMv8-A like this: | | Enable software perf-events with PERF_SAMPLE_CALLCHAIN so userland's | stack is accessed and copied. | | The test program performed the following on every CPU and forking | many processes: | | unsigned long *map = mmap(NULL, PAGE_SIZE, PROT_READ|PROT_WRITE, | MAP_SHARED | MAP_ANONYMOUS, -1, 0); | map[0] = getpid(); | sched_yield(); | if (map[0] != getpid()) { | fprintf(stderr, "Corruption detected!"); | } | munmap(map, PAGE_SIZE); | | From time to time I was getting map[0] to contain pid for a | different process. Ensure that PAN is re-enabled when returning after an unhandled user fault from our uaccess routines. Cc: Catalin Marinas <catalin.marinas@arm.com> Reviewed-by: Mark Rutland <mark.rutland@arm.com> Tested-by: Mark Rutland <mark.rutland@arm.com> Cc: <stable@vger.kernel.org> Fixes: 338d4f49d6f7 ("arm64: kernel: Add support for Privileged Access Never") Signed-off-by: Pavel Tatashin <pasha.tatashin@soleen.com> [will: rewrote commit message] Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* arm64: dts: lg: Fix SPI controller node namesRob Herring2019-11-202-4/+4
| | | | | | | | | | | | [ Upstream commit 09bae3b64cb580c95329bd8d16f08f0a5cb81ec9 ] SPI controller nodes should be named 'spi' rather than 'ssp'. Fixing the name enables dtc SPI bus checks. Cc: Chanho Min <chanho.min@lge.com> Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
* arm64: dts: amd: Fix SPI bus warningsRob Herring2019-11-201-2/+2
| | | | | | | | | | | | | | | | | [ Upstream commit e9f0878c4b2004ac19581274c1ae4c61ae3ca70e ] dtc has new checks for SPI buses. Fix the warnings in node names. arch/arm64/boot/dts/amd/amd-overdrive.dtb: Warning (spi_bus_bridge): /smb/ssp@e1030000: node name for SPI buses should be 'spi' arch/arm64/boot/dts/amd/amd-overdrive-rev-b0.dtb: Warning (spi_bus_bridge): /smb/ssp@e1030000: node name for SPI buses should be 'spi' arch/arm64/boot/dts/amd/amd-overdrive-rev-b1.dtb: Warning (spi_bus_bridge): /smb/ssp@e1030000: node name for SPI buses should be 'spi' Cc: Brijesh Singh <brijeshkumar.singh@amd.com> Cc: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
* arm64: tegra: I2C on Tegra194 is not compatible with Tegra114Thierry Reding2019-11-201-8/+8
| | | | | | | | | | [ Upstream commit d9fd22447ba59a9b53a202fade977e82bfba8d8d ] Tegra194 contains a version of the I2C controller that is no longer compatible with the version found in Tegra114. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* arm64: dts: fsl: Fix I2C and SPI bus warningsRob Herring2019-11-205-10/+10
| | | | | | | | | | | | | | | | | [ Upstream commit b739c177e1aeab532f355493439a1901b85be38c ] dtc has new checks for I2C and SPI buses. Fix the SPI bus node names and warnings in unit-addresses. arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dtb: Warning (i2c_bus_reg): /soc/i2c@2180000/eeprom@57: I2C bus unit address format error, expected "53" arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dtb: Warning (i2c_bus_reg): /soc/i2c@2180000/eeprom@56: I2C bus unit address format error, expected "52" Cc: Shawn Guo <shawnguo@kernel.org> Cc: Li Yang <leoyang.li@nxp.com> Signed-off-by: Rob Herring <robh@kernel.org> Acked-by: Li Yang <leoyang.li@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* arm64: dts: rockchip: Fix microSD in rk3399 sapphire boardVicente Bergas2019-11-201-1/+23
| | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 88a20edf76091ee7f1bb459b89d714d53f0f8940 ] The microSD card slot in the Sapphire board is not working because of several issues: 1.- The vmmc power supply is missing in the DTS. It is capable of 3.0V and has a GPIO-based enable control. 2.- The vqmmc power supply can provide up to 3.3V, but it is capped in the DTS to just 3.0V because of the vmmc capability. This results in a conflict from the mmc driver requesting an unsupportable voltage range from 3.3V to 3.0V (min > max) as reported in dmesg. So, extend the range up to 3.3V. The hw should be able to stand this 0.3V tolerance. See mmc_regulator_set_vqmmc in drivers/mmc/core/core.c. 3.- The card detect signal is non-working. There is a known conflict with jtag, but the workaround in drivers/soc/rockchip/grf.c does not work. Adding the broken-cd attribute to the DTS fixes the issue. Signed-off-by: Vicente Bergas <vicencb@gmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
* arm64: dts: ti: k3-am65: Change #address-cells and #size-cells of ↵Kishon Vijay Abraham I2019-11-202-27/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | interconnect to 2 [ Upstream commit 3bc1572068e3896b60d86f9c0fb56d1cef28201c ] AM65 has two PCIe controllers and each PCIe controller has '2' address spaces one within the 4GB address space of the SoC and the other above the 4GB address space of the SoC (cbass_main) in addition to the register space. The size of the address space above the 4GB SoC address space is 4GB. These address ranges will be used by CPU/DMA to access the PCIe address space. In order to represent the address space above the 4GB SoC address space and to represent the size of this address space as 4GB, change address-cells and size-cells of interconnect to 2. Since OSPI has similar need in MCU Domain Memory Map, change address-cells and size-cells of cbass_mcu interconnect also to 2. Fixes: ea47eed33a3fe3d919 ("arm64: dts: ti: Add Support for AM654 SoC") Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Acked-by: Vignesh R <vigneshr@ti.com> Acked-by: Nishanth Menon <nm@ti.com> Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* arm64: dts: rockchip: Fix I2C bus unit-address error on rk3399-puma-haikouRob Herring2019-11-201-1/+1
| | | | | | | | | | | | | | [ Upstream commit 501500e65fa96f899230d66153fefd780f08dd34 ] dtc has new checks for I2C buses. Fix the warnings in unit-addresses. arch/arm64/boot/dts/rockchip/rk3399-puma-haikou.dtb: Warning (i2c_bus_reg): /i2c@ff3d0000/codec@0a: I2C bus unit address format error, expected "a" Cc: Heiko Stuebner <heiko@sntech.de> Cc: linux-rockchip@lists.infradead.org Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
* arm64: dts: meson: Fix erroneous SPI bus warningsRob Herring2019-11-202-2/+2
| | | | | | | | | | | | | | | | | [ Upstream commit 68ecb5c1920c5b98b1e717fd2349fba2ee5d4031 ] dtc has new checks for SPI buses. The meson dts files have a node named spi' which causes false positive warnings. As the node is a pinctrl child node, change the node name to be 'spi-pins' to fix the warnings. arch/arm64/boot/dts/amlogic/meson-gxbb-nanopi-k2.dtb: Warning (spi_bus_bridge): /soc/periphs@c8834000/pinctrl@4b0/spi: incorrect #address-cells for SPI bus Cc: Carlo Caione <carlo@caione.org> Cc: Kevin Hilman <khilman@baylibre.com> Cc: linux-amlogic@lists.infradead.org Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* arm64: fix for bad_mode() handler to always result in panicHari Vyas2019-11-201-1/+0
| | | | | | | | | | | | | | | | | | [ Upstream commit e4ba15debcfd27f60d43da940a58108783bff2a6 ] The bad_mode() handler is called if we encounter an uunknown exception, with the expectation that the subsequent call to panic() will halt the system. Unfortunately, if the exception calling bad_mode() is taken from EL0, then the call to die() can end up killing the current user task and calling schedule() instead of falling through to panic(). Remove the die() call altogether, since we really want to bring down the machine in this "impossible" case. Signed-off-by: Hari Vyas <hari.vyas@broadcom.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* arm64: dts: broadcom: Fix I2C and SPI bus warningsRob Herring2019-11-203-5/+5
| | | | | | | | | | | | | | | | | | | | | [ Upstream commit 7cdbe45da1a189e744e6801aebb462ee47235580 ] dtc has new checks for I2C and SPI buses. Fix the warnings in node names and unit-addresses. arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dtb: Warning (i2c_bus_reg): /hsls/i2c@e0000/pcf8574@20: I2C bus unit address format error, expected "27" arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dtb: Warning (i2c_bus_reg): /hsls/i2c@e0000/pcf8574@20: I2C bus unit address format error, expected "27" arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dtb: Warning (spi_bus_bridge): /hsls/ssp@180000: node name for SPI buses should be 'spi' arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dtb: Warning (spi_bus_bridge): /hsls/ssp@190000: node name for SPI buses should be 'spi' Cc: Ray Jui <rjui@broadcom.com> Cc: Scott Branden <sbranden@broadcom.com> Cc: Jon Mason <jonmason@broadcom.com> Cc: bcm-kernel-feedback-list@broadcom.com Signed-off-by: Rob Herring <robh@kernel.org> Acked-by: Scott Branden <sbranden@broadcom.com> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* arm64: dts: renesas: r8a77965: Fix clock/reset for usb2_phy1Geert Uytterhoeven2019-11-201-2/+2
| | | | | | | | | | | | [ Upstream commit 7a590fe317488783a229e5a80e91868942e8463f ] usb2_phy1 accidentally uses the same clock/reset as usb2_phy0. Fixes: b5857630a829a8d5 ("arm64: dts: renesas: r8a77965: add usb2_phy nodes") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
* arm64: dts: renesas: r8a77965: Fix HS-USB compatibleGeert Uytterhoeven2019-11-201-1/+1
| | | | | | | | | | | | [ Upstream commit 99584d93e301d820d817bba2eb77b9152e13009c ] Should be "renesas,usbhs-r8a77965", not "renesas,usbhs-r8a7796". Fixes: a06e8af801760a98 ("arm64: dts: renesas: r8a77965: add HS-USB node") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
* arm64: dts: renesas: r8a77965: Attach the SYS-DMAC to the IPMMUMagnus Damm2019-11-201-0/+24
| | | | | | | | | | | | [ Upstream commit 4d76ad7d9de05506f1ee9a7b22416440468be090 ] For R-Car M3-N hook up SYS-DMAC0, SYS-DMAC1 and SYS-DMAC2 to IPMMU-DS0 and IPMMU-DS1 in same way as for R-Car M3-W. This follows the R-Car Gen3 Rev.1.00 (April 2018) datasheet. Signed-off-by: Magnus Damm <damm+renesas@opensource.se> Signed-off-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
* arm64: dts: renesas: salvator-common: adv748x: Override secondary addressesKieran Bingham2019-11-201-1/+4
| | | | | | | | | | | [ Upstream commit e3da41a6c28f9b61ea03df987f1c9ffffc8b8e60 ] Ensure that the ADV748x device addresses do not conflict, and group them together (visually in i2cdetect) Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
* arm64: dts: meson-axg: use the proper compatible for ethmacNeil Armstrong2019-11-201-1/+1
| | | | | | | | | | | [ Upstream commit eaf8f57c0bf5451132932616ab62f9481adefb55 ] Use the correct compatible for the AXG ethernet mac node. Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* arm64: dts: meson: libretech: update board modelJerome Brunet2019-11-201-1/+1
| | | | | | | | | | | | | [ Upstream commit b7eb0e26cc4a212fde09144cd49d4103170d2b9e ] There is actually several different libretech board with the CC suffix so the model name is not appropriate here. Update to something more specific Reported-by: Da Xue <da@lessconfused.com> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* arm64: dts: rockchip: Fix VCC5V0_HOST_EN on rk3399-sapphireVicente Bergas2019-11-201-1/+1
| | | | | | | | | | [ Upstream commit bcdb578a5f5b4aea79441606ab7f0a2e076b4474 ] The pin is GPIO4-D1 not GPIO1-D1, see schematic, page 15 for reference. Signed-off-by: Vicente Bergas <vicencb@gmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
* arm64: dts: stratix10: i2c clock running out of specAlan Tull2019-11-201-0/+2
| | | | | | | | | | | | [ Upstream commit c8da1d15b8a4957f105ad77bb1404d72e304566f ] DesignWare I2C controller was observed running at 105.93kHz rather than the specified 100kHz. Adjust device tree settings to bring it within spec (a slightly conservative 98 MHz). Signed-off-by: Alan Tull <atull@kernel.org> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* arm64: dts: tegra210-p2180: Correct sdmmc4 vqmmc-supplyAapo Vienamo2019-11-201-0/+1
| | | | | | | | | | | [ Upstream commit 6ff7705da8806de45ca1490194f0b4eb07725804 ] On p2180 sdmmc4 is powered from a fixed 1.8 V regulator. Signed-off-by: Aapo Vienamo <avienamo@nvidia.com> Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* arm64: dts: allwinner: a64: NanoPi-A64: Fix DCDC1 voltageAndre Przywara2019-11-201-3/+3
| | | | | | | | | | | | | | | [ Upstream commit 480f58cdbe392d4387a2193b6131a277e0111dd0 ] According to the NanoPi-A64 schematics, DCDC1 is connected to a voltage rail named "VDD_SYS_3.3V". All users seem to expect 3.3V here: the Ethernet PHY, the uSD card slot, the camera interface and the GPIO pins on the headers. Fix up the voltage on the regulator to lift it up to 3.3V. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Acked-by: Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* arm64: dts: allwinner: a64: Olinuxino: fix DRAM voltageAndre Przywara2019-11-201-2/+6
| | | | | | | | | | | | | | | | | | | [ Upstream commit 93366b49a35f3a190052734b3f32c8fe2535b53f ] The Olinuxino board uses DDR3L chips which are supposed to be driven with 1.35V. The reset default of the AXP is properly set to 1.36V. While technically the chips can also run at 1.5 volts, changing the voltage on the fly while booting Linux is asking for trouble. Also running at a lower voltage saves power. So fix the DCDC5 value to match the actual board design. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Tested-by: Martin Lucina <martin@lucina.net> Acked-by: Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* arm64: dts: allwinner: a64: Orange Pi Win: Fix SD card nodeSamuel Holland2019-11-201-1/+3
| | | | | | | | | | | | | | | | [ Upstream commit 09b964afca14d0594b2b2f265df3d987e2f43867 ] The Orange Pi Win has a microSD card slot which is connected via all four SD data lines. As the DT was not mentioning this fact, we got the default single bit transfers, losing out on performance. Also, as microSD does not have a write protect switch, we disable this feature in the DT node. Signed-off-by: Samuel Holland <samuel@sholland.org> Signed-off-by: Andre Przywara <andre.przywara@arm.com> Acked-by: Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* arm64: Do not mask out PTE_RDONLY in pte_same()Catalin Marinas2019-11-121-17/+0
| | | | | | | | | | | | | | | | | | | | | | | commit 6767df245f4736d0cf0c6fb7cf9cf94b27414245 upstream. Following commit 73e86cb03cf2 ("arm64: Move PTE_RDONLY bit handling out of set_pte_at()"), the PTE_RDONLY bit is no longer managed by set_pte_at() but built into the PAGE_* attribute definitions. Consequently, pte_same() must include this bit when checking two PTEs for equality. Remove the arm64-specific pte_same() function, practically reverting commit 747a70e60b72 ("arm64: Fix copy-on-write referencing in HugeTLB") Fixes: 73e86cb03cf2 ("arm64: Move PTE_RDONLY bit handling out of set_pte_at()") Cc: <stable@vger.kernel.org> # 4.14.x- Cc: Will Deacon <will@kernel.org> Cc: Steve Capper <steve.capper@arm.com> Reported-by: John Stultz <john.stultz@linaro.org> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* arm64: dts: ti: k3-am65-main: Fix gic-its node unit-addressSuman Anna2019-11-101-1/+1
| | | | | | | | | | | | | | | commit 389ce1a7c5279ebfb682fab220b4021b2bd49c8b upstream. The gic-its node unit-address has an additional zero compared to the actual reg value. Fix it. Fixes: ea47eed33a3f ("arm64: dts: ti: Add Support for AM654 SoC") Reported-by: Robert Tivy <rtivy@ti.com> Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* arm64: dts: Fix gpio to pinmux mappingRayagonda Kokatanur2019-11-102-4/+4
| | | | | | | | | | | | | | [ Upstream commit 965f6603e3335a953f4f876792074cb36bf65f7f ] There are total of 151 non-secure gpio (0-150) and four pins of pinmux (91, 92, 93 and 94) are not mapped to any gpio pin, hence update same in DT. Fixes: 8aa428cc1e2e ("arm64: dts: Add pinctrl DT nodes for Stingray SOC") Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com> Reviewed-by: Ray Jui <ray.jui@broadcom.com> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* arm64: dts: allwinner: a64: sopine-baseboard: Add PHY regulator delayJernej Skrabec2019-11-101-0/+6
| | | | | | | | | | | | | | | | | | | | | | [ Upstream commit ccdf3aaa27ded6db9a93eed3ca7468bb2353b8fe ] It turns out that sopine-baseboard needs same fix as pine64-plus for ethernet PHY. Here too Realtek ethernet PHY chip needs additional power on delay to properly initialize. Datasheet mentions that chip needs 30 ms to be properly powered on and that it needs some more time to be initialized. Fix that by adding 100ms ramp delay to regulator responsible for powering PHY. Note that issue was found out and fix tested on pine64-lts, but it's basically the same as sopine-baseboard, only layout and connectors differ. Fixes: bdfe4cebea11 ("arm64: allwinner: a64: add Ethernet PHY regulator for several boards") Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* arm64: dts: allwinner: a64: pine64-plus: Add PHY regulator delayJernej Skrabec2019-11-101-0/+9
| | | | | | | | | | | | | | | | | | [ Upstream commit 2511366797fa6ab4a404b4b000ef7cd262aaafe8 ] Depending on kernel and bootloader configuration, it's possible that Realtek ethernet PHY isn't powered on properly. According to the datasheet, it needs 30ms to power up and then some more time before it can be used. Fix that by adding 100ms ramp delay to regulator responsible for powering PHY. Fixes: 94dcfdc77fc5 ("arm64: allwinner: pine64-plus: Enable dwmac-sun8i") Suggested-by: Ondrej Jirman <megous@megous.com> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* arm64: Ensure VM_WRITE|VM_SHARED ptes are clean by defaultCatalin Marinas2019-11-061-7/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit aa57157be69fb599bd4c38a4b75c5aad74a60ec0 upstream. Shared and writable mappings (__S.1.) should be clean (!dirty) initially and made dirty on a subsequent write either through the hardware DBM (dirty bit management) mechanism or through a write page fault. A clean pte for the arm64 kernel is one that has PTE_RDONLY set and PTE_DIRTY clear. The PAGE_SHARED{,_EXEC} attributes have PTE_WRITE set (PTE_DBM) and PTE_DIRTY clear. Prior to commit 73e86cb03cf2 ("arm64: Move PTE_RDONLY bit handling out of set_pte_at()"), it was the responsibility of set_pte_at() to set the PTE_RDONLY bit and mark the pte clean if the software PTE_DIRTY bit was not set. However, the above commit removed the pte_sw_dirty() check and the subsequent setting of PTE_RDONLY in set_pte_at() while leaving the PAGE_SHARED{,_EXEC} definitions unchanged. The result is that shared+writable mappings are now dirty by default Fix the above by explicitly setting PTE_RDONLY in PAGE_SHARED{,_EXEC}. In addition, remove the superfluous PTE_DIRTY bit from the kernel PROT_* attributes. Fixes: 73e86cb03cf2 ("arm64: Move PTE_RDONLY bit handling out of set_pte_at()") Cc: <stable@vger.kernel.org> # 4.14.x- Cc: Will Deacon <will@kernel.org> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* arm64: armv8_deprecated: Checking return value for memory allocationYunfeng Ye2019-11-061-0/+5
| | | | | | | | | | | [ Upstream commit 3e7c93bd04edfb0cae7dad1215544c9350254b8f ] There are no return value checking when using kzalloc() and kcalloc() for memory allocation. so add it. Signed-off-by: Yunfeng Ye <yeyunfeng@huawei.com> Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* arm64: ftrace: Ensure synchronisation in PLT setup for Neoverse-N1 #1542419James Morse2019-11-061-3/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit dd8a1f13488438c6c220b7cafa500baaf21a6e53 ] CPUs affected by Neoverse-N1 #1542419 may execute a stale instruction if it was recently modified. The affected sequence requires freshly written instructions to be executable before a branch to them is updated. There are very few places in the kernel that modify executable text, all but one come with sufficient synchronisation: * The module loader's flush_module_icache() calls flush_icache_range(), which does a kick_all_cpus_sync() * bpf_int_jit_compile() calls flush_icache_range(). * Kprobes calls aarch64_insn_patch_text(), which does its work in stop_machine(). * static keys and ftrace both patch between nops and branches to existing kernel code (not generated code). The affected sequence is the interaction between ftrace and modules. The module PLT is cleaned using __flush_icache_range() as the trampoline shouldn't be executable until we update the branch to it. Drop the double-underscore so that this path runs kick_all_cpus_sync() too. Signed-off-by: James Morse <james.morse@arm.com> Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* arm64: kpti: Whitelist HiSilicon Taishan v110 CPUsHanjun Guo2019-11-061-0/+1
| | | | | | | | | | | | | | [ Upstream commit 0ecc471a2cb7d4d386089445a727f47b59dc9b6e ] HiSilicon Taishan v110 CPUs didn't implement CSV3 field of the ID_AA64PFR0_EL1 and are not susceptible to Meltdown, so whitelist the MIDR in kpti_safe_list[] table. Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org> Reviewed-by: John Garry <john.garry@huawei.com> Reviewed-by: Zhangshaokun <zhangshaokun@hisilicon.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* arm64: Add MIDR encoding for HiSilicon Taishan CPUsHanjun Guo2019-11-061-0/+4
| | | | | | | | | | | | | | | commit efd00c722ca855745fcc35a7e6675b5a782a3fc8 upstream. Adding the MIDR encodings for HiSilicon Taishan v110 CPUs, which is used in Kunpeng ARM64 server SoCs. TSV110 is the abbreviation of Taishan v110. Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org> Reviewed-by: John Garry <john.garry@huawei.com> Reviewed-by: Zhangshaokun <zhangshaokun@hisilicon.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* arm64: Enable workaround for Cavium TX2 erratum 219 when running SMTMarc Zyngier2019-10-291-0/+33
| | | | | | | | | | | | | | commit 93916beb70143c46bf1d2bacf814be3a124b253b upstream. It appears that the only case where we need to apply the TX2_219_TVM mitigation is when the core is in SMT mode. So let's condition the enabling on detecting a CPU whose MPIDR_EL1.Aff0 is non-zero. Cc: <stable@vger.kernel.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* arm64/sve: Fix wrong free for task->thread.sve_stateMasayoshi Mizuma2019-10-171-17/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 4585fc59c0e813188d6a4c5de1f6976fce461fc2 upstream. 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> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* arm64: topology: Use PPTT to determine if PE is a threadJeremy Linton2019-10-171-4/+15
| | | | | | | | | | | | | | | | | Commit 98dc19902a0b2e5348e43d6a2c39a0a7d0fc639e upstream. ACPI 6.3 adds a thread flag to represent if a CPU/PE is actually a thread. Given that the MPIDR_MT bit may not represent this information consistently on homogeneous machines we should prefer the PPTT flag if its available. Signed-off-by: Jeremy Linton <jeremy.linton@arm.com> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> Reviewed-by: Robert Richter <rrichter@marvell.com> [will: made acpi_cpu_is_threaded() return 'bool'] Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
generated by cgit v1.2.3 (git 2.25.1) at 2024-10-28 19:24:45 +0000