aboutsummaryrefslogtreecommitdiffstats
path: root/arch/arm64
AgeCommit message (Collapse)Author
2020-01-15Merge branch 'v5.2/standard/base' into v5.2/standard/cn96xxBruce Ashfield
2020-01-15Merge tag 'v5.2.29' into v5.2/standard/baseBruce Ashfield
This is the 5.2.29 stable release # gpg: Signature made Fri 10 Jan 2020 09:45:31 AM EST # gpg: using RSA key EBCE84042C07D1D6 # gpg: Can't check signature: No public key
2020-01-09arm64: uaccess: Ensure PAN is re-enabled after unhandled uaccess faultPavel Tatashin
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: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-01-05Merge branch 'v5.2/standard/base' into v5.2/standard/cn96xxBruce Ashfield
2020-01-05arm64: dts: k3-am6: Add FSS and OSPI nodesVignesh R
commit 32bad8b7367310ee86270f3c67f444d3c5bcff76 from https://git.ti.com/git/processor-sdk/processor-sdk-linux.git branch: processor-sdk-linux-4.19.y AM654 SoC has a Flash Subsystem(FSS) with two Cadence Octal SPI(OSPI) controllers. Add DT entries for the same. Reviewed-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Vignesh R <vigneshr@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Jun Miao <jun.miao@windriver.com> Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
2020-01-05arm64: dts: ti: k3-am654-base-board: Add OSPI entryVignesh R
commit 3a004451c7652bb9f6f2476ac4a1f3a070e8ed46 from https://git.ti.com/git/processor-sdk/processor-sdk-linux.git branch: processor-sdk-linux-4.19.y Add OSPI node and flash device entry Reviewed-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Vignesh R <vigneshr@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Jun Miao <jun.miao@windriver.com> Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
2020-01-02arm64: Drop the merge conflict markersKevin Hao
Drop the dangling conflict markers introduced by commit 08a005cc2d66 ("Merge branch 'v5.2/standard/base' into v5.2/standard/cn96xx"). Signed-off-by: Kevin Hao <haokexin@gmail.com> Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
2019-12-29Merge branch 'v5.2/standard/base' into v5.2/standard/cn96xxBruce Ashfield
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
2019-12-29Merge tag 'v5.2.28' into v5.2/standard/baseBruce Ashfield
This is the 5.2.28 stable release # gpg: Signature made Sun 29 Dec 2019 05:29:45 PM EST # gpg: using RSA key EBCE84042C07D1D6 # gpg: Can't check signature: No public key
2019-12-29arm64: errata: Update stale commentThierry Reding
commit 7a292b6c7c9c35afee01ce3b2248f705869d0ff1 upstream. 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> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2019-12-29arm64: apply ARM64_ERRATUM_843419 workaround for Brahma-B53 coreFlorian Fainelli
commit 1cf45b8fdbb87040e1d1bd793891089f4678aa41 upstream. The Broadcom Brahma-B53 core is susceptible to the issue described by ARM64_ERRATUM_843419 so this commit enables the workaround to be applied when executing on that core. Since there are now multiple entries to match, we must convert the existing ARM64_ERRATUM_843419 into an erratum list and use cpucap_multi_entry_cap_matches to match our entries. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2019-12-29arm64: Brahma-B53 is SSB and spectre v2 safeFlorian Fainelli
commit e059770cb1cdfbcbe3f1748f76005861cc79dd1a upstream. Add the Brahma-B53 CPU (all versions) to the whitelists of CPUs for the SSB and spectre v2 mitigations. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2019-12-29arm64: apply ARM64_ERRATUM_845719 workaround for Brahma-B53 coreDoug Berger
commit bfc97f9f199cb041cf897af3af096540948cc705 upstream. The Broadcom Brahma-B53 core is susceptible to the issue described by ARM64_ERRATUM_845719 so this commit enables the workaround to be applied when executing on that core. Since there are now multiple entries to match, we must convert the existing ARM64_ERRATUM_845719 into an erratum list. Signed-off-by: Doug Berger <opendmb@gmail.com> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2019-12-29arm64: cpufeature: Enable Qualcomm Falkor errata 1009 for KryoBjorn Andersson
commit 36c602dcdd872e9f9b91aae5266b6d7d72b69b96 upstream. The Kryo cores share errata 1009 with Falkor, so add their model definitions and enable it for them as well. Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> [will: Update entry in silicon-errata.rst] Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2019-12-29arm64: Do not mask out PTE_RDONLY in pte_same()Catalin Marinas
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: Paul Gortmaker <paul.gortmaker@windriver.com>
2019-12-18Merge branch 'v5.2/standard/base' into v5.2/standard/cn96xxBruce Ashfield
2019-12-18Merge tag 'v5.2.27' into v5.2/standard/baseBruce Ashfield
This is the 5.2.27 stable release # gpg: Signature made Mon 16 Dec 2019 10:43:54 PM EST # gpg: using RSA key EBCE84042C07D1D6 # gpg: Can't check signature: No public key
2019-12-16arm64: dts: ti: k3-am65-main: Fix gic-its node unit-addressSuman Anna
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: Paul Gortmaker <paul.gortmaker@windriver.com>
2019-12-16arm64: dts: imx8mm: Use correct clock for usdhc's ipg clkAnson Huang
commit a6a40d5688f2264afd40574ee1c92e5f824b34ba upstream. On i.MX8MM, usdhc's ipg clock is from IMX8MM_CLK_IPG_ROOT, assign it explicitly instead of using IMX8MM_CLK_DUMMY. Fixes: a05ea40eb384 ("arm64: dts: imx: Add i.mx8mm dtsi support") Signed-off-by: Anson Huang <Anson.Huang@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2019-12-16arm64: dts: imx8mq: Use correct clock for usdhc's ipg clkAnson Huang
commit b0759297f2c8dda455ff78a1d1ac95e261300ae3 upstream. On i.MX8MQ, usdhc's ipg clock is from IMX8MQ_CLK_IPG_ROOT, assign it explicitly instead of using IMX8MQ_CLK_DUMMY. Fixes: 748f908cc882 ("arm64: add basic DTS for i.MX8MQ") Signed-off-by: Anson Huang <Anson.Huang@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2019-12-16arm64: dts: lx2160a: Correct CPU core idle state nameRan Wang
commit 07159f67c77134dfdfdbdf3d8f657f5890de5b7f upstream. lx2160a support PW15 but not PW20, correct name to avoid confusing. Signed-off-by: Ran Wang <ran.wang_1@nxp.com> Fixes: 00c5ce8ac023 ("arm64: dts: lx2160a: add cpu idle support") Acked-by: Li Yang <leoyang.li@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2019-12-16arm64: dts: rockchip: fix RockPro64 sdmmc settingsSoeren Moch
commit 5234c14531152702a9f3e575cb552b7e9cea9f94 upstream. According to the RockPro64 schematic [1] the rk3399 sdmmc controller is connected to a microSD (TF card) slot. Remove the cap-mmc-highspeed property of the sdmmc controller, since no mmc card can be connected here. [1] http://files.pine64.org/doc/rockpro64/rockpro64_v21-SCH.pdf Fixes: e4f3fb490967 ("arm64: dts: rockchip: add initial dts support for Rockpro64") Signed-off-by: Soeren Moch <smoch@web.de> Link: https://lore.kernel.org/r/20191004203213.4995-1-smoch@web.de Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2019-12-16arm64: dts: zii-ultra: fix ARM regulator statesLucas Stach
commit 21094ba5c1f4b15df096e8f6247a50b6ab57c869 upstream. The GPIO controlled regulator for the ARM power supply is supplying the higher voltage when the GPIO is driven high. This is opposite to the similar regulator setup on the EVK board and is impacting stability of the board as the ARM domain has been supplied with a too low voltage when to faster OPPs are in use. Fixes: 4a13b3bec3b4 (arm64: dts: imx: add Zii Ultra board support) Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2019-12-16arm64: dts: rockchip: fix RockPro64 sdhci settingsSoeren Moch
commit 2558b3b1b11a1b32b336be2dd0aabfa6d35ddcb5 upstream. The RockPro64 schematics [1], [2] show that the rk3399 EMMC_STRB pin is connected to the RESET pin instead of the DATA_STROBE pin of the eMMC module. So the data strobe cannot be used for its intended purpose on this board, and so the HS400 eMMC mode is not functional. Limit the controller to HS200. [1] http://files.pine64.org/doc/rockpro64/rockpro64_v21-SCH.pdf [2] http://files.pine64.org/doc/rock64/PINE64_eMMC_Module_20170719.pdf Fixes: e4f3fb490967 ("arm64: dts: rockchip: add initial dts support for Rockpro64") Signed-off-by: Soeren Moch <smoch@web.de> Link: https://lore.kernel.org/r/20191003215036.15023-2-smoch@web.de Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2019-12-16arm64: dts: rockchip: fix RockPro64 vdd-log regulator settingsSoeren Moch
commit 0990c5e7573098117c69651821647c228483e31b upstream. The RockPro64 schematic [1] page 18 states a min voltage of 0.8V and a max voltage of 1.4V for the VDD_LOG pwm regulator. However, there is an additional note that the pwm parameter needs to be modified. From the schematics a voltage range of 0.8V to 1.7V can be calculated. Additional voltage measurements on the board show that this fix indeed leads to the correct voltage, while without this fix the voltage was set too high. [1] http://files.pine64.org/doc/rockpro64/rockpro64_v21-SCH.pdf Fixes: e4f3fb490967 ("arm64: dts: rockchip: add initial dts support for Rockpro64") Signed-off-by: Soeren Moch <smoch@web.de> Link: https://lore.kernel.org/r/20191003215036.15023-1-smoch@web.de Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2019-12-16arm64: dts: rockchip: fix Rockpro64 RK808 interrupt lineHugh Cole-Baker
commit deea9f5fc32040fd6f6132f2260ba410fb5cf98c upstream. Fix the pinctrl and interrupt specifier for RK808 to use GPIO3_B2. On the Rockpro64 schematic [1] page 16, it shows GPIO3_B2 used for the interrupt line PMIC_INT_L from the RK808, and there's a note which translates as: "PMU termination GPIO1_C5 changed to this". Tested by setting an RTC wakealarm and checking /proc/interrupts counters. Without this patch, neither the rockchip_gpio_irq counter for the RK808, nor the RTC alarm counter increment when the alarm time is reached. With this patch, both interrupt counters increment by 1 as expected. [1] http://files.pine64.org/doc/rockpro64/rockpro64_v21-SCH.pdf Fixes: e4f3fb490967 ("arm64: dts: rockchip: add initial dts support for Rockpro64") Signed-off-by: Hugh Cole-Baker <sigmaris@gmail.com> Link: https://lore.kernel.org/r/20190921131457.36258-1-sigmaris@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2019-12-16arm64: dts: Fix gpio to pinmux mappingRayagonda Kokatanur
commit 965f6603e3335a953f4f876792074cb36bf65f7f upstream. 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: Paul Gortmaker <paul.gortmaker@windriver.com>
2019-12-16arm64: dts: allwinner: a64: sopine-baseboard: Add PHY regulator delayJernej Skrabec
commit ccdf3aaa27ded6db9a93eed3ca7468bb2353b8fe upstream. 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: Paul Gortmaker <paul.gortmaker@windriver.com>
2019-12-16arm64: dts: allwinner: a64: Re-add PMU nodeAndre Przywara
commit 6b832a148717f1718f57805a9a4aa7f092582d15 upstream. As it was found recently, the Performance Monitoring Unit (PMU) on the Allwinner A64 SoC was not generating (the right) interrupts. With the SPI numbers from the manual the kernel did not receive any overflow interrupts, so perf was not happy at all. It turns out that the numbers were just off by 4, so the PMU interrupts are from 148 to 151, not from 152 to 155 as the manual describes. This was found by playing around with U-Boot, which typically does not use interrupts, so the GIC is fully available for experimentation: With *every* PPI and SPI enabled, an overflowing PMU cycle counter was found to set a bit in one of the GICD_ISPENDR registers, with careful counting this was determined to be number 148. Tested with perf record and perf top on a Pine64-LTS. Also tested with tasksetting to every core to confirm the assignment between IRQs and cores. This somewhat "revert-fixes" commit ed3e9406bcbc ("arm64: dts: allwinner: a64: Drop PMU node"). Fixes: 34a97fcc71c2 ("arm64: dts: allwinner: a64: Add PMU node") Fixes: ed3e9406bcbc ("arm64: dts: allwinner: a64: Drop PMU node") Signed-off-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2019-12-16arm64: dts: allwinner: a64: Drop PMU nodeVasily Khoruzhick
commit ed3e9406bcbc32f84dc4aa4cb4767852e5ab086c upstream. Looks like PMU in A64 is broken, it generates no interrupts at all and as result 'perf top' shows no events. Tested on Pine64-LTS. Fixes: 34a97fcc71c2 ("arm64: dts: allwinner: a64: Add PMU node") Cc: Harald Geyer <harald@ccbib.org> Cc: Jared D. McNeill <jmcneill@NetBSD.org> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com> Reviewed-by: Emmanuel Vadot <manu@FreeBSD.org> Signed-off-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2019-12-16arm64: dts: allwinner: a64: pine64-plus: Add PHY regulator delayJernej Skrabec
commit 2511366797fa6ab4a404b4b000ef7cd262aaafe8 upstream. 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: Paul Gortmaker <paul.gortmaker@windriver.com>
2019-12-12Merge branch 'v5.2/standard/cn96xx-merge' into v5.2/standard/cn96xxBruce Ashfield
2019-12-12Merge branch 'v5.2/standard/base' into v5.2/standard/cn96xxBruce Ashfield
2019-12-12Merge tag 'v5.2.26' into v5.2/standard/baseBruce Ashfield
This is the 5.2.26 stable release # gpg: Signature made Tue 10 Dec 2019 01:52:47 PM EST # gpg: using RSA key EBCE84042C07D1D6 # gpg: Can't check signature: No public key
2019-12-11arm64: Fix workaround for Marvell erratum 37119Maciej Czekaj
commit 89352f7e4fd4301e7a5f2043502bf5492fd3378c from git@git.assembla.com:cavium/WindRiver.linux.git Workaround for erratum 37119 used the alternative_insn macro in an incorrect way effectively producing nops instead of tlbi. Change-Id: I111e5bbcf3ef7007ad1acd63d33d1153ac451bb2 Signed-off-by: Maciej Czekaj <mczekaj@marvell.com> Reviewed-on: https://sj1git1.cavium.com/18098 Tested-by: sa_ip-sw-jenkins <sa_ip-sw-jenkins@marvell.com> Reviewed-by: Sunil Kovvuri Goutham <Sunil.Goutham@cavium.com> Signed-off-by: Kevin Hao <kexin.hao@windriver.com>
2019-12-10arm64: cpufeature: Enable Qualcomm Falkor/Kryo errata 1003Bjorn Andersson
commit d4af3c4b81f4cd5662baa6f1492f998d89783318 upstream. With the introduction of 'cce360b54ce6 ("arm64: capabilities: Filter the entries based on a given mask")' the Qualcomm Falkor/Kryo errata 1003 is no long applied. The result of not applying errata 1003 is that MSM8996 runs into various RCU stalls and fails to boot most of the times. Give 1003 a "type" to ensure they are not filtered out in update_cpu_capabilities(). Fixes: cce360b54ce6 ("arm64: capabilities: Filter the entries based on a given mask") Cc: stable@vger.kernel.org Reported-by: Mark Brown <broonie@kernel.org> Suggested-by: Will Deacon <will@kernel.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2019-12-10arm64: Ensure VM_WRITE|VM_SHARED ptes are clean by defaultCatalin Marinas
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: Paul Gortmaker <paul.gortmaker@windriver.com>
2019-12-10arm64: armv8_deprecated: Checking return value for memory allocationYunfeng Ye
commit 3e7c93bd04edfb0cae7dad1215544c9350254b8f upstream. 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: Paul Gortmaker <paul.gortmaker@windriver.com>
2019-12-10arm64: ftrace: Ensure synchronisation in PLT setup for Neoverse-N1 #1542419James Morse
commit dd8a1f13488438c6c220b7cafa500baaf21a6e53 upstream. 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: Paul Gortmaker <paul.gortmaker@windriver.com>
2019-12-10arm64: Fix incorrect irqflag restore for priority masking for compatJames Morse
commit f46f27a576cc3b1e3d45ea50bc06287aa46b04b2 upstream. Commit bd82d4bd2188 ("arm64: Fix incorrect irqflag restore for priority masking") added a macro to the entry.S call paths that leave the PSTATE.I bit set. This tells the pPNMI masking logic that interrupts are masked by the CPU, not by the PMR. This value is read back by local_daif_save(). Commit bd82d4bd2188 added this call to el0_svc, as el0_svc_handler is called with interrupts masked. el0_svc_compat was missed, but should be covered in the same way as both of these paths end up in el0_svc_common(), which expects to unmask interrupts. Fixes: bd82d4bd2188 ("arm64: Fix incorrect irqflag restore for priority masking") Signed-off-by: James Morse <james.morse@arm.com> Cc: Julien Thierry <julien.thierry.kdev@gmail.com> Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2019-11-27Merge branch 'v5.2/standard/cn96xx-merge' into v5.2/standard/cn96xxBruce Ashfield
2019-11-27Merge branch 'v5.2/standard/base' into v5.2/standard/cn96xxBruce Ashfield
2019-11-27arm64: dts: ti: k3-am65-main: Enable support for sdhci1Faiz Abbas
commit bb40213e83549b52e46baac3979046dc17e6b58a from branch ti-linux-4.19.y: git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git Add support for the 2nd Secure Digital Host controller instance present in TI's am654 SoC. Signed-off-by: Faiz Abbas <faiz_abbas@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Jun Miao <jun.miao@windriver.com> Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
2019-11-27arm64: dts: ti: k3-am654-base-board: Add Support for SD cardFaiz Abbas
commit 4a77a43537ba1aa31ac8792095e9e35253cabff7 from branch ti-linux-4.19.y: git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git The 2nd sdhci instance is connected to an SD card on am654-evm. Add board specific properties and pinmux for the same. Signed-off-by: Faiz Abbas <faiz_abbas@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Jun Miao <jun.miao@windriver.com> Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
2019-11-26arm64: Add workaround for Marvell erratum 37119Andrew Pinski
commit a8735dfd13887dac412adf0d8be69904486c0a60 from git@git.assembla.com:cavium/WindRiver.linux.git Enable workaround for erratum 37119. On some OcteonTX2 chips, while using the SSO workslots in userspace can cause problems as the cache are not invalidated correctly. To workaround this erratum, a local tlbi is placed before the eret. This TLBI does not need to invalidate anything so a tlbi against asid 0 is used. Change-Id: I0313daae25e8ccaaffb84f9b6db5e6859b693dfa Signed-off-by: Andrew Pinski <apinski@marvell.com> Reviewed-on: https://sj1git1.cavium.com/17086 Reviewed-by: Stanislaw Kardach <Stanislaw.Kardach@cavium.com> Reviewed-by: Sunil Kovvuri Goutham <Sunil.Goutham@cavium.com> Tested-by: Sunil Kovvuri Goutham <Sunil.Goutham@cavium.com> [Kevin: Use ERRATA_MIDR_RANGE_LIST macro to fix the duplicate entry warning for capability.] Signed-off-by: Kevin Hao <kexin.hao@windriver.com>
2019-11-26arm64: Add workaround for Cavium erratum 36890Andrew Pinski
commit 8aa39af7f78e6283cb4e82cd08f506fa5aa5a132 from git@git.assembla.com:cavium/WindRiver.linux.git On all ThunderX T88 passes, all OcteonTX T81 and T83 passes, and some OcteonTX2 passes (some T96xx and F95XX), the "dc zva" instruction has issues where old data would be in the cache in some cases. This happens when there are two different VAs pointing to the same PA; even with different asids. Change-Id: Ife8671af41822c4d6d6e4e7a24d005ee29d9dd17 Signed-off-by: Andrew Pinski <apinski@marvell.com> Reviewed-on: https://sj1git1.cavium.com/17082 Reviewed-by: Linu Cherian <lcherian@marvell.com> Tested-by: Linu Cherian <lcherian@marvell.com> [Kevin: Replace the config_sctlr_el1() with sysreg_clear_set(), and use ERRATA_MIDR_RANGE_LIST macro to fix the duplicate entry warning for capability.] Signed-off-by: Kevin Hao <kexin.hao@windriver.com>
2019-11-25arm64: Add MIDR encoding for some Marvell OcteonTX 2.Andrew Pinski
commit ee783a55c16a6b4362912ada5c5da883b8b97fc5 from git@git.assembla.com:cavium/WindRiver.linux.git This patch adds the MIDR encodings for Marvell's OcteonTX2. Change-Id: Iec5fdd375e78047f8becaba852b9f69a0dc02804 Signed-off-by: Andrew Pinski <apinski@marvell.com> Reviewed-on: https://sj1git1.cavium.com/17081 Reviewed-by: Linu Cherian <lcherian@marvell.com> Tested-by: Linu Cherian <lcherian@marvell.com> Signed-off-by: Kevin Hao <kexin.hao@windriver.com>
2019-11-10Merge branch 'v5.2/standard/base' into v5.2/standard/cn96xxBruce Ashfield
2019-11-10Merge tag 'v5.2.22' into v5.2/standard/baseBruce Ashfield
This is the 5.2.22 stable release # gpg: Signature made Sat 09 Nov 2019 08:56:23 PM EST # gpg: using RSA key EBCE84042C07D1D6 # gpg: Can't check signature: No public key
2019-11-09arm64/sve: Fix wrong free for task->thread.sve_stateMasayoshi Mizuma
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: Paul Gortmaker <paul.gortmaker@windriver.com>