- 05 12月, 2019 3 次提交
-
-
由 Will Deacon 提交于
[ 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: NArd Biesheuvel <ard.biesheuvel@linaro.org> Reported-by: N"kernelci.org bot" <bot@kernelci.org> Tested-by: NKevin Hilman <khilman@baylibre.com> Signed-off-by: NWill Deacon <will.deacon@arm.com> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 Suzuki K Poulose 提交于
[ 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: NSteve Capper <steve.capper@arm.com> Cc: Will Deacon <will.deacon@arm.com> Signed-off-by: NSuzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: NWill Deacon <will.deacon@arm.com> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 Steve Capper 提交于
[ 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: NSteve Capper <steve.capper@arm.com> Signed-off-by: NWill Deacon <will.deacon@arm.com> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
- 01 12月, 2019 2 次提交
-
-
由 Victor Kamensky 提交于
[ Upstream commit 98356eb0ae499c63e78073ccedd9a5fc5c563288 ] After 'a66649da 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: NKevin Brodsky <kevin.brodsky@arm.com> Signed-off-by: NVictor Kamensky <kamensky@cisco.com> Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 Andrey Ryabinin 提交于
[ 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.comSigned-off-by: NAndrey Ryabinin <aryabinin@virtuozzo.com> Reported-by: NKyeongdon 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: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
- 24 11月, 2019 2 次提交
-
-
由 Anshuman Khandual 提交于
[ 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: 1a2db300 ("arm64, numa: Add NUMA support for arm64 platforms") Acked-by: NPunit Agrawal <punit.agrawal@arm.com> Signed-off-by: NAnshuman Khandual <anshuman.khandual@arm.com> Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 Pavel 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: NMark Rutland <mark.rutland@arm.com> Tested-by: NMark Rutland <mark.rutland@arm.com> Cc: <stable@vger.kernel.org> Fixes: 338d4f49 ("arm64: kernel: Add support for Privileged Access Never") Signed-off-by: NPavel Tatashin <pasha.tatashin@soleen.com> [will: rewrote commit message] Signed-off-by: NWill Deacon <will@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 21 11月, 2019 22 次提交
-
-
由 Rob Herring 提交于
[ 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: NRob Herring <robh@kernel.org> Signed-off-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 Rob Herring 提交于
[ 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: NRob Herring <robh@kernel.org> Signed-off-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 Thierry Reding 提交于
[ 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: NThierry Reding <treding@nvidia.com> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 Rob Herring 提交于
[ 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: NRob Herring <robh@kernel.org> Acked-by: NLi Yang <leoyang.li@nxp.com> Signed-off-by: NShawn Guo <shawnguo@kernel.org> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 Vicente Bergas 提交于
[ 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: NVicente Bergas <vicencb@gmail.com> Signed-off-by: NHeiko Stuebner <heiko@sntech.de> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 Kishon Vijay Abraham I 提交于
[ 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: ea47eed3 ("arm64: dts: ti: Add Support for AM654 SoC") Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com> Acked-by: NTony Lindgren <tony@atomide.com> Acked-by: NVignesh R <vigneshr@ti.com> Acked-by: NNishanth Menon <nm@ti.com> Signed-off-by: NTero Kristo <t-kristo@ti.com> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 Rob Herring 提交于
[ 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: NRob Herring <robh@kernel.org> Signed-off-by: NHeiko Stuebner <heiko@sntech.de> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 Rob Herring 提交于
[ 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: NRob Herring <robh@kernel.org> Signed-off-by: NKevin Hilman <khilman@baylibre.com> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 Hari Vyas 提交于
[ 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: NHari Vyas <hari.vyas@broadcom.com> Signed-off-by: NWill Deacon <will.deacon@arm.com> Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 Rob Herring 提交于
[ 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: NRob Herring <robh@kernel.org> Acked-by: NScott Branden <sbranden@broadcom.com> Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 Geert Uytterhoeven 提交于
[ Upstream commit 7a590fe317488783a229e5a80e91868942e8463f ] usb2_phy1 accidentally uses the same clock/reset as usb2_phy0. Fixes: b5857630 ("arm64: dts: renesas: r8a77965: add usb2_phy nodes") Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: NSimon Horman <horms+renesas@verge.net.au> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 Geert Uytterhoeven 提交于
[ Upstream commit 99584d93e301d820d817bba2eb77b9152e13009c ] Should be "renesas,usbhs-r8a77965", not "renesas,usbhs-r8a7796". Fixes: a06e8af8 ("arm64: dts: renesas: r8a77965: add HS-USB node") Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: NSimon Horman <horms+renesas@verge.net.au> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 Magnus Damm 提交于
[ 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: NMagnus Damm <damm+renesas@opensource.se> Signed-off-by: NSimon Horman <horms+renesas@verge.net.au> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 Kieran Bingham 提交于
[ Upstream commit e3da41a6c28f9b61ea03df987f1c9ffffc8b8e60 ] Ensure that the ADV748x device addresses do not conflict, and group them together (visually in i2cdetect) Signed-off-by: NKieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by: NSimon Horman <horms+renesas@verge.net.au> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 Neil Armstrong 提交于
[ Upstream commit eaf8f57c0bf5451132932616ab62f9481adefb55 ] Use the correct compatible for the AXG ethernet mac node. Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com> Acked-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: NKevin Hilman <khilman@baylibre.com> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 Jerome Brunet 提交于
[ 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: NDa Xue <da@lessconfused.com> Signed-off-by: NJerome Brunet <jbrunet@baylibre.com> Signed-off-by: NKevin Hilman <khilman@baylibre.com> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 Vicente Bergas 提交于
[ Upstream commit bcdb578a5f5b4aea79441606ab7f0a2e076b4474 ] The pin is GPIO4-D1 not GPIO1-D1, see schematic, page 15 for reference. Signed-off-by: NVicente Bergas <vicencb@gmail.com> Signed-off-by: NHeiko Stuebner <heiko@sntech.de> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 Alan Tull 提交于
[ 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: NAlan Tull <atull@kernel.org> Signed-off-by: NDinh Nguyen <dinguyen@kernel.org> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 Aapo Vienamo 提交于
[ Upstream commit 6ff7705da8806de45ca1490194f0b4eb07725804 ] On p2180 sdmmc4 is powered from a fixed 1.8 V regulator. Signed-off-by: NAapo Vienamo <avienamo@nvidia.com> Reviewed-by: NMikko Perttunen <mperttunen@nvidia.com> Signed-off-by: NThierry Reding <treding@nvidia.com> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 Andre Przywara 提交于
[ 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: NAndre Przywara <andre.przywara@arm.com> Acked-by: NMaxime Ripard <maxime.ripard@bootlin.com> Signed-off-by: NChen-Yu Tsai <wens@csie.org> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 Andre Przywara 提交于
[ 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: NAndre Przywara <andre.przywara@arm.com> Tested-by: NMartin Lucina <martin@lucina.net> Acked-by: NMaxime Ripard <maxime.ripard@bootlin.com> Signed-off-by: NChen-Yu Tsai <wens@csie.org> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 Samuel Holland 提交于
[ 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: NSamuel Holland <samuel@sholland.org> Signed-off-by: NAndre Przywara <andre.przywara@arm.com> Acked-by: NMaxime Ripard <maxime.ripard@bootlin.com> Signed-off-by: NChen-Yu Tsai <wens@csie.org> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
- 13 11月, 2019 1 次提交
-
-
由 Catalin Marinas 提交于
commit 6767df245f4736d0cf0c6fb7cf9cf94b27414245 upstream. Following commit 73e86cb0 ("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 747a70e6 ("arm64: Fix copy-on-write referencing in HugeTLB") Fixes: 73e86cb0 ("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: NJohn Stultz <john.stultz@linaro.org> Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com> Signed-off-by: NWill Deacon <will@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 10 11月, 2019 4 次提交
-
-
由 Suman Anna 提交于
commit 389ce1a7c5279ebfb682fab220b4021b2bd49c8b upstream. The gic-its node unit-address has an additional zero compared to the actual reg value. Fix it. Fixes: ea47eed3 ("arm64: dts: ti: Add Support for AM654 SoC") Reported-by: NRobert Tivy <rtivy@ti.com> Signed-off-by: NSuman Anna <s-anna@ti.com> Signed-off-by: NTero Kristo <t-kristo@ti.com> Signed-off-by: NMathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Rayagonda Kokatanur 提交于
[ 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: 8aa428cc ("arm64: dts: Add pinctrl DT nodes for Stingray SOC") Signed-off-by: NRayagonda Kokatanur <rayagonda.kokatanur@broadcom.com> Reviewed-by: NRay Jui <ray.jui@broadcom.com> Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 Jernej Skrabec 提交于
[ 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: bdfe4ceb ("arm64: allwinner: a64: add Ethernet PHY regulator for several boards") Signed-off-by: NJernej Skrabec <jernej.skrabec@siol.net> Signed-off-by: NMaxime Ripard <mripard@kernel.org> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 Jernej Skrabec 提交于
[ 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: 94dcfdc7 ("arm64: allwinner: pine64-plus: Enable dwmac-sun8i") Suggested-by: NOndrej Jirman <megous@megous.com> Signed-off-by: NJernej Skrabec <jernej.skrabec@siol.net> Signed-off-by: NMaxime Ripard <mripard@kernel.org> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
- 06 11月, 2019 5 次提交
-
-
由 Catalin 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 73e86cb0 ("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: 73e86cb0 ("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: NCatalin Marinas <catalin.marinas@arm.com> Signed-off-by: NWill Deacon <will@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Yunfeng Ye 提交于
[ Upstream commit 3e7c93bd04edfb0cae7dad1215544c9350254b8f ] There are no return value checking when using kzalloc() and kcalloc() for memory allocation. so add it. Signed-off-by: NYunfeng Ye <yeyunfeng@huawei.com> Signed-off-by: NWill Deacon <will@kernel.org> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 James Morse 提交于
[ 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: NJames Morse <james.morse@arm.com> Signed-off-by: NWill Deacon <will@kernel.org> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 Hanjun Guo 提交于
[ 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: NHanjun Guo <hanjun.guo@linaro.org> Reviewed-by: NJohn Garry <john.garry@huawei.com> Reviewed-by: NZhangshaokun <zhangshaokun@hisilicon.com> Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 Hanjun Guo 提交于
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: NHanjun Guo <hanjun.guo@linaro.org> Reviewed-by: NJohn Garry <john.garry@huawei.com> Reviewed-by: NZhangshaokun <zhangshaokun@hisilicon.com> Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 29 10月, 2019 1 次提交
-
-
由 Marc Zyngier 提交于
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: NMarc Zyngier <marc.zyngier@arm.com> Signed-off-by: NWill Deacon <will@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-