summaryrefslogtreecommitdiff
path: root/arch/arm
AgeCommit message (Collapse)AuthorFilesLines
2020-08-21ARM: 8992/1: Fix unwind_frame for clang-built kernelsNathan Huckleberry1-0/+24
commit b4d5ec9b39f8b31d98f65bc5577b5d15d93795d7 upstream. Since clang does not push pc and sp in function prologues, the current implementation of unwind_frame does not work. By using the previous frame's lr/fp instead of saved pc/sp we get valid unwinds on clang-built kernels. The bounds check on next frame pointer must be changed as well since there are 8 less bytes between frames. This fixes /proc/<pid>/stack. Link: https://github.com/ClangBuiltLinux/linux/issues/912 Reported-by: Miles Chen <miles.chen@mediatek.com> Tested-by: Miles Chen <miles.chen@mediatek.com> Cc: stable@vger.kernel.org Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Nathan Huckleberry <nhuck@google.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-08-21ARM: socfpga: PM: add missing put_device() call in ↵Yu Kuai1-3/+5
socfpga_setup_ocram_self_refresh() [ Upstream commit 3ad7b4e8f89d6bcc9887ca701cf2745a6aedb1a0 ] if of_find_device_by_node() succeed, socfpga_setup_ocram_self_refresh doesn't have a corresponding put_device(). Thus add a jump target to fix the exception handling for this function implementation. Fixes: 44fd8c7d4005 ("ARM: socfpga: support suspend to ram") Signed-off-by: Yu Kuai <yukuai3@huawei.com> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-08-21ARM: at91: pm: add missing put_device() call in at91_pm_sram_init()yu kuai1-3/+8
[ Upstream commit f87a4f022c44e5b87e842a9f3e644fba87e8385f ] if of_find_device_by_node() succeed, at91_pm_sram_init() doesn't have a corresponding put_device(). Thus add a jump target to fix the exception handling for this function implementation. Fixes: d2e467905596 ("ARM: at91: pm: use the mmio-sram pool to access SRAM") Signed-off-by: yu kuai <yukuai3@huawei.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20200604123301.3905837-1-yukuai3@huawei.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-08-07ARM: 8702/1: head-common.S: Clear lr before jumping to start_kernel()Geert Uytterhoeven1-0/+1
commit 59b6359dd92d18f5dc04b14a4c926fa08ab66f7c upstream. If CONFIG_DEBUG_LOCK_ALLOC=y, the kernel log is spammed with a few hundred identical messages: unwind: Unknown symbol address c0800300 unwind: Index not found c0800300 c0800300 is the return address from the last subroutine call (to __memzero()) in __mmap_switched(). Apparently having this address in the link register confuses the unwinder. To fix this, reset the link register to zero before jumping to start_kernel(). Fixes: 9520b1a1b5f7a348 ("ARM: head-common.S: speed up startup code") Suggested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
2020-08-07ARM: percpu.h: fix build errorGrygorii Strashko1-0/+2
commit aa54ea903abb02303bf55855fb51e3fcee135d70 upstream. Fix build error for the case: defined(CONFIG_SMP) && !defined(CONFIG_CPU_V6) config: keystone_defconfig CC arch/arm/kernel/signal.o In file included from ../include/linux/random.h:14, from ../arch/arm/kernel/signal.c:8: ../arch/arm/include/asm/percpu.h: In function ‘__my_cpu_offset’: ../arch/arm/include/asm/percpu.h:29:34: error: ‘current_stack_pointer’ undeclared (first use in this function); did you mean ‘user_stack_pointer’? : "Q" (*(const unsigned long *)current_stack_pointer)); ^~~~~~~~~~~~~~~~~~~~~ user_stack_pointer Fixes: f227e3ec3b5c ("random32: update the net random state on interrupt and activity") Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-08-05ARM: 8986/1: hw_breakpoint: Don't invoke overflow handler on uaccess watchpointsWill Deacon1-5/+22
commit eec13b42d41b0f3339dcf0c4da43734427c68620 upstream. Unprivileged memory accesses generated by the so-called "translated" instructions (e.g. LDRT) in kernel mode can cause user watchpoints to fire unexpectedly. In such cases, the hw_breakpoint logic will invoke the user overflow handler which will typically raise a SIGTRAP back to the current task. This is futile when returning back to the kernel because (a) the signal won't have been delivered and (b) userspace can't handle the thing anyway. Avoid invoking the user overflow handler for watchpoints triggered by kernel uaccess routines, and instead single-step over the faulting instruction as we would if no overflow handler had been installed. Cc: <stable@vger.kernel.org> Fixes: f81ef4a920c8 ("ARM: 6356/1: hw-breakpoint: add ARM backend for the hw-breakpoint framework") Reported-by: Luis Machado <luis.machado@linaro.org> Tested-by: Luis Machado <luis.machado@linaro.org> Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-22ARM: dts: socfpga: Align L2 cache-controller nodename with dtschemaKrzysztof Kozlowski2-2/+2
[ Upstream commit d7adfe5ffed9faa05f8926223086b101e14f700d ] Fix dtschema validator warnings like: l2-cache@fffff000: $nodename:0: 'l2-cache@fffff000' does not match '^(cache-controller|cpu)(@[0-9a-f,]+)*$' Fixes: 475dc86d08de ("arm: dts: socfpga: Add a base DTSI for Altera's Arria10 SOC") Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-07-22ARM: imx6: add missing put_device() call in imx6q_suspend_init()yu kuai1-4/+6
[ Upstream commit 4845446036fc9c13f43b54a65c9b757c14f5141b ] if of_find_device_by_node() succeed, imx6q_suspend_init() doesn't have a corresponding put_device(). Thus add a jump target to fix the exception handling for this function implementation. Signed-off-by: yu kuai <yukuai3@huawei.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-07-22ARM: dts: omap4-droid4: Fix spi configuration and increase rateTony Lindgren1-1/+3
[ Upstream commit 0df12a01f4857495816b05f048c4c31439446e35 ] We can currently sometimes get "RXS timed out" errors and "EOT timed out" errors with spi transfers. These errors can be made easy to reproduce by reading the cpcap iio values in a loop while keeping the CPUs busy by also reading /dev/urandom. The "RXS timed out" errors we can fix by adding spi-cpol and spi-cpha in addition to the spi-cs-high property we already have. The "EOT timed out" errors we can fix by increasing the spi clock rate to 9.6 MHz. Looks similar MC13783 PMIC says it works at spi clock rates up to 20 MHz, so let's assume we can pick any rate up to 20 MHz also for cpcap. Cc: maemo-leste@lists.dyne.org Cc: Merlijn Wajer <merlijn@wizzup.org> Cc: Pavel Machek <pavel@ucw.cz> Cc: Sebastian Reichel <sre@kernel.org> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-30ARM: imx5: add missing put_device() call in imx_suspend_alloc_ocram()yu kuai1-2/+4
[ Upstream commit 586745f1598ccf71b0a5a6df2222dee0a865954e ] if of_find_device_by_node() succeed, imx_suspend_alloc_ocram() doesn't have a corresponding put_device(). Thus add a jump target to fix the exception handling for this function implementation. Fixes: 1579c7b9fe01 ("ARM: imx53: Set DDR pins to high impedance when in suspend to RAM.") Signed-off-by: yu kuai <yukuai3@huawei.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-30ARM: dts: NSP: Correct FA2 mailbox nodeMatthew Hagan1-3/+3
[ Upstream commit ac4e106d8934a5894811fc263f4b03fc8ed0fb7a ] The FA2 mailbox is specified at 0x18025000 but should actually be 0x18025c00, length 0x400 according to socregs_nsp.h and board_bu.c. Also the interrupt was off by one and should be GIC SPI 151 instead of 150. Fixes: 17d517172300 ("ARM: dts: NSP: Add mailbox (PDC) to NSP") Signed-off-by: Matthew Hagan <mnhagan88@gmail.com> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-25ARM: integrator: Add some Kconfig selectionsLinus Walleij1-3/+4
[ Upstream commit d2854bbe5f5c4b4bec8061caf4f2e603d8819446 ] The CMA and DMA_CMA Kconfig options need to be selected by the Integrator in order to produce boot console on some Integrator systems. The REGULATOR and REGULATOR_FIXED_VOLTAGE need to be selected in order to boot the system from an external MMC card when using MMCI/PL181 from the device tree probe path. Select these things directly from the Kconfig so we are sure to be able to bring the systems up with console from any device tree. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-20ARM: tegra: Correct PL310 Auxiliary Control Register initializationDmitry Osipenko1-2/+2
commit 35509737c8f958944e059d501255a0bf18361ba0 upstream. The PL310 Auxiliary Control Register shouldn't have the "Full line of zero" optimization bit being set before L2 cache is enabled. The L2X0 driver takes care of enabling the optimization by itself. This patch fixes a noisy error message on Tegra20 and Tegra30 telling that cache optimization is erroneously enabled without enabling it for the CPU: L2C-310: enabling full line of zeros but not enabled in Cortex-A9 Cc: <stable@vger.kernel.org> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Tested-by: Nicolas Chauvet <kwizart@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-06-20ARM: 8978/1: mm: make act_mm() respect THREAD_SIZELinus Walleij1-1/+2
[ Upstream commit e1de94380af588bdf6ad6f0cc1f75004c35bc096 ] Recent work with KASan exposed the folling hard-coded bitmask in arch/arm/mm/proc-macros.S: bic rd, sp, #8128 bic rd, rd, #63 This forms the bitmask 0x1FFF that is coinciding with (PAGE_SIZE << THREAD_SIZE_ORDER) - 1, this code was assuming that THREAD_SIZE is always 8K (8192). As KASan was increasing THREAD_SIZE_ORDER to 2, I ran into this bug. Fix it by this little oneline suggested by Ard: bic rd, sp, #(THREAD_SIZE - 1) & ~63 Where THREAD_SIZE is defined using THREAD_SIZE_ORDER. We have to also include <linux/const.h> since the THREAD_SIZE expands to use the _AC() macro. Cc: Ard Biesheuvel <ardb@kernel.org> Cc: Florian Fainelli <f.fainelli@gmail.com> Suggested-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-20ARM: 8977/1: ptrace: Fix mask for thumb breakpoint hookFredrik Strupe1-2/+2
[ Upstream commit 3866f217aaa81bf7165c7f27362eee5d7919c496 ] call_undef_hook() in traps.c applies the same instr_mask for both 16-bit and 32-bit thumb instructions. If instr_mask then is only 16 bits wide (0xffff as opposed to 0xffffffff), the first half-word of 32-bit thumb instructions will be masked out. This makes the function match 32-bit thumb instructions where the second half-word is equal to instr_val, regardless of the first half-word. The result in this case is that all undefined 32-bit thumb instructions with the second half-word equal to 0xde01 (udf #1) work as breakpoints and will raise a SIGTRAP instead of a SIGILL, instead of just the one intended 16-bit instruction. An example of such an instruction is 0xeaa0de01, which is unallocated according to Arm ARM and should raise a SIGILL, but instead raises a SIGTRAP. This patch fixes the issue by setting all the bits in instr_mask, which will still match the intended 16-bit thumb instruction (where the upper half is always 0), but not any 32-bit thumb instructions. Cc: Oleg Nesterov <oleg@redhat.com> Signed-off-by: Fredrik Strupe <fredrik@strupe.net> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-03ARM: dts: bcm2835-rpi-zero-w: Fix led polarityVincent Stehlé1-1/+1
[ Upstream commit 58bb90ab415562eededb932455046924e65df342 ] The status "ACT" led on the Raspberry Pi Zero W is on when GPIO 47 is low. This has been verified on a board and somewhat confirmed by both the GPIO name ("STATUS_LED_N") and the reduced schematics [1]. [1]: https://www.raspberrypi.org/documentation/hardware/raspberrypi/schematics/rpi_SCH_ZeroW_1p1_reduced.pdf Fixes: 2c7c040c73e9 ("ARM: dts: bcm2835: Add Raspberry Pi Zero W") Signed-off-by: Vincent Stehlé <vincent.stehle@laposte.net> Cc: Stefan Wahren <stefan.wahren@i2se.com> Cc: Florian Fainelli <f.fainelli@gmail.com> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-03ARM: dts/imx6q-bx50v3: Set display interface clock parentsRobert Beckett4-25/+15
[ Upstream commit 665e7c73a7724a393b4ec92d1ae1e029925ef2b7 ] Avoid LDB and IPU DI clocks both using the same parent. LDB requires pasthrough clock to avoid breaking timing while IPU DI does not. Force IPU DI clocks to use IMX6QDL_CLK_PLL2_PFD0_352M as parent and LDB to use IMX6QDL_CLK_PLL5_VIDEO_DIV. This fixes an issue where attempting atomic modeset while using HDMI and display port at the same time causes LDB clock programming to destroy the programming of HDMI that was done during the same modeset. Cc: stable@vger.kernel.org Signed-off-by: Robert Beckett <bob.beckett@collabora.com> [Use IMX6QDL_CLK_PLL2_PFD0_352M instead of IMX6QDL_CLK_PLL2_PFD2_396M originally chosen by Robert Beckett to avoid affecting eMMC clock by DRM atomic updates] Signed-off-by: Ian Ray <ian.ray@ge.com> [Squash Robert's and Ian's commits for bisectability, update patch description and add stable tag] Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-03ARM: dts: imx6q-bx50v3: Add internal switchSebastian Reichel1-0/+62
[ Upstream commit e26dead442689a861358f33126210b0f8de615a9 ] B850v3, B650v3 and B450v3 all have a GPIO bit banged MDIO bus to communicate with a Marvell switch. On all devices the switch is connected to a PCI based network card, which needs to be referenced by DT, so this also adds the common PCI root node. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-03ARM: uaccess: fix DACR mismatch with nested exceptionsRussell King1-5/+20
[ Upstream commit 71f8af1110101facfad68989ff91f88f8e2c3e22 ] Tomas Paukrt reports that his SAM9X60 based system (ARM926, ARMv5TJ) fails to fix up alignment faults, eventually resulting in a kernel oops. The problem occurs when using CONFIG_CPU_USE_DOMAINS with commit e6978e4bf181 ("ARM: save and reset the address limit when entering an exception"). This is because the address limit is set back to TASK_SIZE on exception entry, and, although it is restored on exception exit, the domain register is not. Hence, this sequence can occur: interrupt pt_regs->addr_limit = addr_limit // USER_DS addr_limit = USER_DS alignment exception __probe_kernel_read() old_fs = get_fs() // USER_DS set_fs(KERNEL_DS) addr_limit = KERNEL_DS dacr.kernel = DOMAIN_MANAGER interrupt pt_regs->addr_limit = addr_limit // KERNEL_DS addr_limit = USER_DS alignment exception __probe_kernel_read() old_fs = get_fs() // USER_DS set_fs(KERNEL_DS) addr_limit = KERNEL_DS dacr.kernel = DOMAIN_MANAGER ... set_fs(old_fs) addr_limit = USER_DS dacr.kernel = DOMAIN_CLIENT ... addr_limit = pt_regs->addr_limit // KERNEL_DS interrupt returns At this point, addr_limit is correctly restored to KERNEL_DS for __probe_kernel_read() to continue execution, but dacr.kernel is not, it has been reset by the set_fs(old_fs) to DOMAIN_CLIENT. This would not have happened prior to the mentioned commit, because addr_limit would remain KERNEL_DS, so get_fs() would have returned KERNEL_DS, and so would correctly nest. This commit fixes the problem by also saving the DACR on exception entry if either CONFIG_CPU_SW_DOMAIN_PAN or CONFIG_CPU_USE_DOMAINS are enabled, and resetting the DACR appropriately on exception entry to match addr_limit and PAN settings. Fixes: e6978e4bf181 ("ARM: save and reset the address limit when entering an exception") Reported-by: Tomas Paukrt <tomas.paukrt@advantech.cz> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-03ARM: uaccess: integrate uaccess_save and uaccess_restoreRussell King1-17/+13
[ Upstream commit 8ede890b0bcebe8c760aacfe20e934d98c3dc6aa ] Integrate uaccess_save / uaccess_restore macros into the new uaccess_entry / uaccess_exit macros respectively. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-03ARM: uaccess: consolidate uaccess asm to asm/uaccess-asm.hRussell King4-89/+112
[ Upstream commit 747ffc2fcf969eff9309d7f2d1d61cb8b9e1bb40 ] Consolidate the user access assembly code to asm/uaccess-asm.h. This moves the csdb, check_uaccess, uaccess_mask_range_ptr, uaccess_enable, uaccess_disable, uaccess_save, uaccess_restore macros, and creates two new ones for exception entry and exit - uaccess_entry and uaccess_exit. This makes the uaccess_save and uaccess_restore macros private to asm/uaccess-asm.h. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-03ARM: 8843/1: use unified assembler in headersStefan Agner3-14/+14
[ Upstream commit c001899a5d6c2d7a0f3b75b2307ddef137fb46a6 ] Use unified assembler syntax (UAL) in headers. Divided syntax is considered deprecated. This will also allow to build the kernel using LLVM's integrated assembler. Signed-off-by: Stefan Agner <stefan@agner.ch> Acked-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-03ARM: dts: rockchip: fix pinctrl sub nodename for spi in rk322x.dtsiJohan Jonker1-2/+2
[ Upstream commit 855bdca1781c79eb661f89c8944c4a719ce720e8 ] A test with the command below gives these errors: arch/arm/boot/dts/rk3229-evb.dt.yaml: spi-0: '#address-cells' is a required property arch/arm/boot/dts/rk3229-evb.dt.yaml: spi-1: '#address-cells' is a required property arch/arm/boot/dts/rk3229-xms6.dt.yaml: spi-0: '#address-cells' is a required property arch/arm/boot/dts/rk3229-xms6.dt.yaml: spi-1: '#address-cells' is a required property The $nodename pattern for spi nodes is "^spi(@.*|-[0-9a-f])*$". To prevent warnings rename 'spi-0' and 'spi-1' pinctrl sub nodenames to 'spi0' and 'spi1' in 'rk322x.dtsi'. make ARCH=arm dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/spi/spi-controller.yaml Signed-off-by: Johan Jonker <jbx6244@gmail.com> Link: https://lore.kernel.org/r/20200424123923.8192-1-jbx6244@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-03ARM: dts: rockchip: fix phy nodename for rk3228-evbJohan Jonker1-1/+1
[ Upstream commit 287e0d538fcec2f6e8eb1e565bf0749f3b90186d ] A test with the command below gives for example this error: arch/arm/boot/dts/rk3228-evb.dt.yaml: phy@0: '#phy-cells' is a required property The phy nodename is normally used by a phy-handle. This node is however compatible with "ethernet-phy-id1234.d400", "ethernet-phy-ieee802.3-c22" which is just been added to 'ethernet-phy.yaml'. So change nodename to 'ethernet-phy' for which '#phy-cells' is not a required property make ARCH=arm dtbs_check DT_SCHEMA_FILES=~/.local/lib/python3.5/site-packages/dtschema/schemas/ phy/phy-provider.yaml Signed-off-by: Johan Jonker <jbx6244@gmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20200416170321.4216-1-jbx6244@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-05-27ARM: futex: Address build warningThomas Gleixner1-2/+7
[ Upstream commit 8101b5a1531f3390b3a69fa7934c70a8fd6566ad ] Stephen reported the following build warning on a ARM multi_v7_defconfig build with GCC 9.2.1: kernel/futex.c: In function 'do_futex': kernel/futex.c:1676:17: warning: 'oldval' may be used uninitialized in this function [-Wmaybe-uninitialized] 1676 | return oldval == cmparg; | ~~~~~~~^~~~~~~~~ kernel/futex.c:1652:6: note: 'oldval' was declared here 1652 | int oldval, ret; | ^~~~~~ introduced by commit a08971e9488d ("futex: arch_futex_atomic_op_inuser() calling conventions change"). While that change should not make any difference it confuses GCC which fails to work out that oldval is not referenced when the return value is not zero. GCC fails to properly analyze arch_futex_atomic_op_inuser(). It's not the early return, the issue is with the assembly macros. GCC fails to detect that those either set 'ret' to 0 and set oldval or set 'ret' to -EFAULT which makes oldval uninteresting. The store to the callsite supplied oldval pointer is conditional on ret == 0. The straight forward way to solve this is to make the store unconditional. Aside of addressing the build warning this makes sense anyway because it removes the conditional from the fastpath. In the error case the stored value is uninteresting and the extra store does not matter at all. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lkml.kernel.org/r/87pncao2ph.fsf@nanos.tec.linutronix.de Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-05-20ARM: dts: r8a7740: Add missing extal2 to CPG nodeGeert Uytterhoeven1-1/+1
commit e47cb97f153193d4b41ca8d48127da14513d54c7 upstream. The Clock Pulse Generator (CPG) device node lacks the extal2 clock. This may lead to a failure registering the "r" clock, or to a wrong parent for the "usb24s" clock, depending on MD_CK2 pin configuration and boot loader CPG_USBCKCR register configuration. This went unnoticed, as this does not affect the single upstream board configuration, which relies on the first clock input only. Fixes: d9ffd583bf345e2e ("ARM: shmobile: r8a7740: add SoC clocks to DTS") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Ulrich Hecht <uli+renesas@fpond.eu> Link: https://lore.kernel.org/r/20200508095918.6061-1-geert+renesas@glider.be Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-20ARM: dts: r8a73a4: Add missing CMT1 interruptsGeert Uytterhoeven1-1/+8
commit 0f739fdfe9e5ce668bd6d3210f310df282321837 upstream. The R-Mobile APE6 Compare Match Timer 1 generates 8 interrupts, one for each channel, but currently only 1 is described. Fix this by adding the missing interrupts. Fixes: f7b65230019b9dac ("ARM: shmobile: r8a73a4: Add CMT1 node") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20200408090926.25201-1-geert+renesas@glider.be Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-20ARM: dts: imx27-phytec-phycard-s-rdk: Fix the I2C1 pinctrl entriesFabio Estevam1-2/+2
commit 0caf34350a25907515d929a9c77b9b206aac6d1e upstream. The I2C2 pins are already used and the following errors are seen: imx27-pinctrl 10015000.iomuxc: pin MX27_PAD_I2C2_SDA already requested by 10012000.i2c; cannot claim for 1001d000.i2c imx27-pinctrl 10015000.iomuxc: pin-69 (1001d000.i2c) status -22 imx27-pinctrl 10015000.iomuxc: could not request pin 69 (MX27_PAD_I2C2_SDA) from group i2c2grp on device 10015000.iomuxc imx-i2c 1001d000.i2c: Error applying setting, reverse things back imx-i2c: probe of 1001d000.i2c failed with error -22 Fix it by adding the correct I2C1 IOMUX entries for the pinctrl_i2c1 group. Cc: <stable@vger.kernel.org> Fixes: 61664d0b432a ("ARM: dts: imx27 phyCARD-S pinctrl") Signed-off-by: Fabio Estevam <festevam@gmail.com> Reviewed-by: Stefan Riedmueller <s.riedmueller@phytec.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-20ARM: dts: dra7: Fix bus_dma_limit for PCIeKishon Vijay Abraham I1-2/+2
commit 90d4d3f4ea45370d482fa609dbae4d2281b4074f upstream. Even though commit cfb5d65f2595 ("ARM: dts: dra7: Add bus_dma_limit for L3 bus") added bus_dma_limit for L3 bus, the PCIe controller gets incorrect value of bus_dma_limit. Fix it by adding empty dma-ranges property to axi@0 and axi@1 (parent device tree node of PCIe controller). Cc: stable@kernel.org Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-02ARM: dts: bcm283x: Disable dsi0 nodeNicolas Saenz Julienne1-0/+1
commit 90444b958461a5f8fc299ece0fe17eab15cba1e1 upstream. Since its inception the module was meant to be disabled by default, but the original commit failed to add the relevant property. Fixes: 4aba4cf82054 ("ARM: dts: bcm2835: Add the DSI module nodes and clocks") Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Reviewed-by: Eric Anholt <eric@anholt.net> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-02ARM: imx: provide v7_cpu_resume() only on ARM_CPU_SUSPEND=yAhmad Fatoum1-0/+2
commit f1baca8896ae18e12c45552a4c4ae2086aa7e02c upstream. 512a928affd5 ("ARM: imx: build v7_cpu_resume() unconditionally") introduced an unintended linker error for i.MX6 configurations that have ARM_CPU_SUSPEND=n which can happen if neither CONFIG_PM, CONFIG_CPU_IDLE, nor ARM_PSCI_FW are selected. Fix this by having v7_cpu_resume() compiled only when cpu_resume() it calls is available as well. The C declaration for the function remains unguarded to avoid future code inadvertently using a stub and introducing a regression to the bug the original commit fixed. Cc: <stable@vger.kernel.org> Fixes: 512a928affd5 ("ARM: imx: build v7_cpu_resume() unconditionally") Reported-by: Clemens Gruber <clemens.gruber@pqgruber.com> Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Tested-by: Roland Hieber <rhi@pengutronix.de> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-24arm, bpf: Fix bugs with ALU64 {RSH, ARSH} BPF_K shift by 0Luke Nelson1-2/+10
commit bb9562cf5c67813034c96afb50bd21130a504441 upstream. The current arm BPF JIT does not correctly compile RSH or ARSH when the immediate shift amount is 0. This causes the "rsh64 by 0 imm" and "arsh64 by 0 imm" BPF selftests to hang the kernel by reaching an instruction the verifier determines to be unreachable. The root cause is in how immediate right shifts are encoded on arm. For LSR and ASR (logical and arithmetic right shift), a bit-pattern of 00000 in the immediate encodes a shift amount of 32. When the BPF immediate is 0, the generated code shifts by 32 instead of the expected behavior (a no-op). This patch fixes the bugs by adding an additional check if the BPF immediate is 0. After the change, the above mentioned BPF selftests pass. Fixes: 39c13c204bb11 ("arm: eBPF JIT compiler") Co-developed-by: Xi Wang <xi.wang@gmail.com> Signed-off-by: Xi Wang <xi.wang@gmail.com> Signed-off-by: Luke Nelson <luke.r.nels@gmail.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20200408181229.10909-1-luke.r.nels@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-02ARM: bcm2835-rpi-zero-w: Add missing pinctrl nameNick Hudson1-0/+1
commit 6687c201fdc3139315c2ea7ef96c157672805cdc upstream. Define the sdhci pinctrl state as "default" so it gets applied correctly and to match all other RPis. Fixes: 2c7c040c73e9 ("ARM: dts: bcm2835: Add Raspberry Pi Zero W") Signed-off-by: Nick Hudson <skrll@netbsd.org> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-02ARM: dts: oxnas: Fix clear-mask propertySungbo Eo2-4/+4
commit deeabb4c1341a12bf8b599e6a2f4cfa4fd74738c upstream. Disable all rps-irq interrupts during driver initialization to prevent an accidental interrupt on GIC. Fixes: 84316f4ef141 ("ARM: boot: dts: Add Oxford Semiconductor OX810SE dtsi") Fixes: 38d4a53733f5 ("ARM: dts: Add support for OX820 and Pogoplug V3") Signed-off-by: Sungbo Eo <mans0n@gorani.run> Acked-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-02ARM: dts: omap5: Add bus_dma_limit for L3 busRoger Quadros1-0/+1
commit dfa7ea303f56a3a8b1ed3b91ef35af2da67ca4ee upstream. The L3 interconnect's memory map is from 0x0 to 0xffffffff. Out of this, System memory (SDRAM) can be accessed from 0x80000000 to 0xffffffff (2GB) OMAP5 does support 4GB of SDRAM but upper 2GB can only be accessed by the MPU subsystem. Add the dma-ranges property to reflect the physical address limit of the L3 bus. Cc: stable@kernel.org Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-02ARM: dts: dra7: Add bus_dma_limit for L3 busRoger Quadros1-0/+1
commit cfb5d65f25959f724081bae8445a0241db606af6 upstream. The L3 interconnect's memory map is from 0x0 to 0xffffffff. Out of this, System memory (SDRAM) can be accessed from 0x80000000 to 0xffffffff (2GB) DRA7 does support 4GB of SDRAM but upper 2GB can only be accessed by the MPU subsystem. Add the dma-ranges property to reflect the physical address limit of the L3 bus. Issues ere observed only with SATA on DRA7-EVM with 4GB RAM and CONFIG_ARM_LPAE enabled. This is because the controller supports 64-bit DMA and its driver sets the dma_mask to 64-bit thus resulting in DMA accesses beyond L3 limit of 2G. Setting the correct bus_dma_limit fixes the issue. Signed-off-by: Roger Quadros <rogerq@ti.com> Cc: stable@kernel.org Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-02ARM: dts: dra7: Add "dma-ranges" property to PCIe RC DT nodesKishon Vijay Abraham I1-0/+2
[ Upstream commit 27f13774654ea6bd0b6fc9b97cce8d19e5735661 ] 'dma-ranges' in a PCI bridge node does correctly set dma masks for PCI devices not described in the DT. Certain DRA7 platforms (e.g., DRA76) has RAM above 32-bit boundary (accessible with LPAE config) though the PCIe bridge will be able to access only 32-bits. Add 'dma-ranges' property in PCIe RC DT nodes to indicate the host bridge can access only 32 bits. Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-03-20ARM: 8958/1: rename missed uaccess .fixup sectionKees Cook1-1/+1
commit f87b1c49bc675da30d8e1e8f4b60b800312c7b90 upstream. When the uaccess .fixup section was renamed to .text.fixup, one case was missed. Under ld.bfd, the orphaned section was moved close to .text (since they share the "ax" bits), so things would work normally on uaccess faults. Under ld.lld, the orphaned section was placed outside the .text section, making it unreachable. Link: https://github.com/ClangBuiltLinux/linux/issues/282 Link: https://bugs.chromium.org/p/chromium/issues/detail?id=1020633#c44 Link: https://lore.kernel.org/r/nycvar.YSQ.7.76.1912032147340.17114@knanqh.ubzr Link: https://lore.kernel.org/lkml/202002071754.F5F073F1D@keescook/ Fixes: c4a84ae39b4a5 ("ARM: 8322/1: keep .text and .fixup regions closer together") Cc: stable@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-20ARM: 8957/1: VDSO: Match ARMv8 timer in cntvct_functional()Florian Fainelli1-0/+2
commit 45939ce292b4b11159719faaf60aba7d58d5fe33 upstream. It is possible for a system with an ARMv8 timer to run a 32-bit kernel. When this happens we will unconditionally have the vDSO code remove the __vdso_gettimeofday and __vdso_clock_gettime symbols because cntvct_functional() returns false since it does not match that compatibility string. Fixes: ecf99a439105 ("ARM: 8331/1: VDSO initialization, mapping, and synchronization") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-11ARM: imx: build v7_cpu_resume() unconditionallyAhmad Fatoum4-16/+28
commit 512a928affd51c2dc631401e56ad5ee5d5dd68b6 upstream. This function is not only needed by the platform suspend code, but is also reused as the CPU resume function when the ARM cores can be powered down completely in deep idle, which is the case on i.MX6SX and i.MX6UL(L). Providing the static inline stub whenever CONFIG_SUSPEND is disabled means that those platforms will hang on resume from cpuidle if suspend is disabled. So there are two problems: - The static inline stub masks the linker error - The function is not available where needed Fix both by just building the function unconditionally, when CONFIG_SOC_IMX6 is enabled. The actual code is three instructions long, so it's arguably ok to just leave it in for all i.MX6 kernel configurations. Fixes: 05136f0897b5 ("ARM: imx: support arm power off in cpuidle for i.mx6sx") Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Signed-off-by: Rouven Czerwinski <r.czerwinski@pengutronix.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-11ARM: dts: ls1021a: Restore MDIO compatible to gianfarVladimir Oltean1-2/+2
commit 7155c44624d061692b4c13aa8343f119c67d4fc0 upstream. The difference between "fsl,etsec2-mdio" and "gianfar" has to do with the .get_tbipa function, which calculates the address of the TBIPA register automatically, if not explicitly specified. [ see drivers/net/ethernet/freescale/fsl_pq_mdio.c ]. On LS1021A, the TBIPA register is at offset 0x30 within the port register block, which is what the "gianfar" method of calculating addresses actually does. Luckily, the bad "compatible" is inconsequential for ls1021a.dtsi, because the TBIPA register is explicitly specified via the second "reg" (<0x0 0x2d10030 0x0 0x4>), so the "get_tbipa" function is dead code. Nonetheless it's good to restore it to its correct value. Background discussion: https://www.spinics.net/lists/stable/msg361156.html Fixes: c7861adbe37f ("ARM: dts: ls1021: Fix SGMII PCS link remaining down after PHY disconnect") Reported-by: Pavel Machek <pavel@denx.de> Signed-off-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-11arm: dts: dra76x: Fix mmc3 max-frequencyFaiz Abbas1-0/+5
commit fa63c0039787b8fbacf4d6a51e3ff44288f5b90b upstream. dra76x is not affected by i887 which requires mmc3 node to be limited to a max frequency of 64 MHz. Fix this by overwriting the correct value in the the dra76 specific dtsi. Fixes: 895bd4b3e5ec ("ARM: dts: Add support for dra76-evm") Cc: stable@vger.kernel.org Signed-off-by: Faiz Abbas <faiz_abbas@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-02-28ARM: 8951/1: Fix Kexec compilation issue.Vincenzo Frascino1-1/+1
[ Upstream commit 76950f7162cad51d2200ebd22c620c14af38f718 ] To perform the reserve_crashkernel() operation kexec uses SECTION_SIZE to find a memblock in a range. SECTION_SIZE is not defined for nommu systems. Trying to compile kexec in these conditions results in a build error: linux/arch/arm/kernel/setup.c: In function ‘reserve_crashkernel’: linux/arch/arm/kernel/setup.c:1016:25: error: ‘SECTION_SIZE’ undeclared (first use in this function); did you mean ‘SECTIONS_WIDTH’? crash_size, SECTION_SIZE); ^~~~~~~~~~~~ SECTIONS_WIDTH linux/arch/arm/kernel/setup.c:1016:25: note: each undeclared identifier is reported only once for each function it appears in linux/scripts/Makefile.build:265: recipe for target 'arch/arm/kernel/setup.o' failed Make KEXEC depend on MMU to fix the compilation issue. Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-02-28ARM: dts: r8a7779: Add device node for ARM global timerGeert Uytterhoeven1-0/+8
[ Upstream commit 8443ffd1bbd5be74e9b12db234746d12e8ea93e2 ] Add a device node for the global timer, which is part of the Cortex-A9 MPCore. The global timer can serve as an accurate (4 ns) clock source for scheduling and delay loops. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20191211135222.26770-4-geert+renesas@glider.be Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-02-28ARM: dts: imx6: rdu2: Disable WP for USDHC2 and USDHC3Andrey Smirnov1-4/+2
[ Upstream commit cd58a174e58649426fb43d7456e5f7d7eab58af1 ] RDU2 production units come with resistor connecting WP pin to correpsonding GPIO DNPed for both SD card slots. Drop any WP related configuration and mark both slots with "disable-wp". Reported-by: Chris Healy <cphealy@gmail.com> Reviewed-by: Chris Healy <cphealy@gmail.com> Reviewed-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Fabio Estevam <festevam@gmail.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-02-28ARM: 8723/2: always assume the "unified" syntax for assembly codeNicolas Pitre3-82/+8
[ Upstream commit 75fea300d73ae5b18957949a53ec770daaeb6fc2 ] The GNU assembler has implemented the "unified syntax" parsing since 2005. This "unified" syntax is required when the kernel is built in Thumb2 mode. However the "unified" syntax is a mixed bag of features, including not requiring a `#' prefix with immediate operands. This leads to situations where some code builds just fine in Thumb2 mode and fails to build in ARM mode if that prefix is missing. This behavior discrepancy makes build tests less valuable, forcing both ARM and Thumb2 builds for proper coverage. Let's "fix" this issue by always using the "unified" syntax for both ARM and Thumb2 mode. Given that the documented minimum binutils version that properly builds the kernel is version 2.20 released in 2010, we can assume that any toolchain capable of building the latest kernel is also "unified syntax" capable. Whith this, a bunch of macros used to mask some differences between both syntaxes can be removed, with the side effect of making LTO easier. Suggested-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-02-15ARM: 8949/1: mm: mark free_memmap as __initOlof Johansson1-1/+1
commit 31f3010e60522ede237fb145a63b4af5a41718c2 upstream. As of commit ac7c3e4ff401 ("compiler: enable CONFIG_OPTIMIZE_INLINING forcibly"), free_memmap() might not always be inlined, and thus is triggering a section warning: WARNING: vmlinux.o(.text.unlikely+0x904): Section mismatch in reference from the function free_memmap() to the function .meminit.text:memblock_free() Mark it as __init, since the faller (free_unused_memmap) already is. Fixes: ac7c3e4ff401 ("compiler: enable CONFIG_OPTIMIZE_INLINING forcibly") Signed-off-by: Olof Johansson <olof@lixom.net> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-02-15ARM: dts: at91: sama5d3: define clock rate range for tcb1Alexandre Belloni1-0/+1
commit a7e0f3fc01df4b1b7077df777c37feae8c9e8b6d upstream. The clock rate range for the TCB1 clock is missing. define it in the device tree. Reported-by: Karl Rudbæk Olsen <karl@micro-technic.com> Fixes: d2e8190b7916 ("ARM: at91/dt: define sama5d3 clocks") Link: https://lore.kernel.org/r/20200110172007.1253659-2-alexandre.belloni@bootlin.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-02-15ARM: dts: at91: sama5d3: fix maximum peripheral clock ratesAlexandre Belloni3-18/+18
commit ee0aa926ddb0bd8ba59e33e3803b3b5804e3f5da upstream. Currently the maximum rate for peripheral clock is calculated based on a typical 133MHz MCK. The maximum frequency is defined in the datasheet as a ratio to MCK. Some sama5d3 platforms are using a 166MHz MCK. Update the device trees to match the maximum rate based on 166MHz. Reported-by: Karl Rudbæk Olsen <karl@micro-technic.com> Fixes: d2e8190b7916 ("ARM: at91/dt: define sama5d3 clocks") Link: https://lore.kernel.org/r/20200110172007.1253659-1-alexandre.belloni@bootlin.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-02-15ARM: tegra: Enable PLLP bypass during Tegra124 LP1Stephen Warren1-0/+11
commit 1a3388d506bf5b45bb283e6a4c4706cfb4897333 upstream. For a little over a year, U-Boot has configured the flow controller to perform automatic RAM re-repair on off->on power transitions of the CPU rail[1]. This is mandatory for correct operation of Tegra124. However, RAM re-repair relies on certain clocks, which the kernel must enable and leave running. PLLP is one of those clocks. This clock is shut down during LP1 in order to save power. Enable bypass (which I believe routes osc_div_clk, essentially the crystal clock, to the PLL output) so that this clock signal toggles even though the PLL is not active. This is required so that LP1 power mode (system suspend) operates correctly. The bypass configuration must then be undone when resuming from LP1, so that all peripheral clocks run at the expected rate. Without this, many peripherals won't work correctly; for example, the UART baud rate would be incorrect. NVIDIA's downstream kernel code only does this if not compiled for Tegra30, so the added code is made conditional upon the chip ID. NVIDIA's downstream code makes this change conditional upon the active CPU cluster. The upstream kernel currently doesn't support cluster switching, so this patch doesn't test the active CPU cluster ID. [1] 3cc7942a4ae5 ARM: tegra: implement RAM repair Reported-by: Jonathan Hunter <jonathanh@nvidia.com> Cc: stable@vger.kernel.org Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.39.0) at 2024-07-10 00:26:59 +0300