summaryrefslogtreecommitdiff
path: root/arch/arm64
AgeCommit message (Collapse)AuthorFilesLines
2021-01-26arm64: dts: rockchip: Add NanoPi M4B boardChen-Yu Tsai2-0/+53
The NanoPi M4B is a minor revision of the original M4. The differences against the original Nanopi M4 that are common with the other M4V2 revision include: - microphone header removed - power button added - recovery button added Additional changes specific to the M4B: - USB 3.0 hub removed; board now has 2x USB 3.0 type-A ports and 2x USB 2.0 ports - ADB toggle switch added; this changes the top USB 3.0 host port to a peripheral port - Type-C port no longer supports data or PD - WiFi/Bluetooth combo chip switched to AP6256, which supports BT 5.0 but only 1T1R (down from 2T2R) for WiFi Add a new dts file for the new board revision that shows the difference against the original. Signed-off-by: Chen-Yu Tsai <wens@csie.org> Link: https://lore.kernel.org/r/20210121162321.4538-5-wens@kernel.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2021-01-26arm64: dts: rockchip: Move ep-gpios property to nanopc-t4 from nanopi4Chen-Yu Tsai2-1/+1
Only the NanoPC T4 hs the PCIe reset pin routed to the SoC. For the NanoPi M4 family, no such signal is routed to the expansion header on the base board. As the schematics for the expansion board were not released, it is unclear how this is handled, but the likely answer is that the signal is always pulled high. Move the ep-gpios property from the common nanopi4.dtsi file to the board level nanopc-t4.dts file. This makes the nanopi-m4 lack ep-gpios, matching the board design. A companion patch "PCI: rockchip: make ep_gpio optional" for the Linux driver is required, as the driver currently requires the property to be present. Fixes: e7a095908227 ("arm64: dts: rockchip: Add devicetree for NanoPC-T4") Reviewed-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Chen-Yu Tsai <wens@csie.org> Link: https://lore.kernel.org/r/20210121162321.4538-4-wens@kernel.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2021-01-26KVM: arm64: Implement the TRNG hypervisor callArd Biesheuvel4-1/+94
Provide a hypervisor implementation of the ARM architected TRNG firmware interface described in ARM spec DEN0098. All function IDs are implemented, including both 32-bit and 64-bit versions of the TRNG_RND service, which is the centerpiece of the API. The API is backed by the kernel's entropy pool only, to avoid guests draining more precious direct entropy sources. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> [Andre: minor fixes, drop arch_get_random() usage] Signed-off-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210106103453.152275-6-andre.przywara@arm.com
2021-01-25ARM: bcm: Select BRCMSTB_L2_IRQ for bcm2835Maxime Ripard1-0/+1
The BCM2711 has a number of instances of interrupt controllers handled by the driver behind the BRCMSTB_L2_IRQ Kconfig option (irq-brcmstb-l2). Let's select that driver as part of the ARCH_BCM2835 Kconfig option. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Link: https://lore.kernel.org/r/20210111142309.193441-1-maxime@cerno.tech
2021-01-25arm64: defconfig: Enable nvmem's rmem driverNicolas Saenz Julienne1-0/+1
It'll be used by the RPi4 family of boards to access its bootloader configuration. Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Link: https://lore.kernel.org/r/20210112142342.7290-1-nsaenzjulienne@suse.de
2021-01-25arm64: dts: qcom: msm8994-kitakami: Add missing email in the copyrightKonrad Dybcio2-2/+2
I forgot to do this the first time around. Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org> Link: https://lore.kernel.org/r/20210118162432.107275-11-konrad.dybcio@somainline.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2021-01-25arm64: dts: qcom: msm8994/8994-kitakami: Fix up the memory mapKonrad Dybcio2-30/+60
The previous map was wrong. Fix it up. Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org> Link: https://lore.kernel.org/r/20210118162432.107275-10-konrad.dybcio@somainline.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2021-01-25arm64: dts: qcom: msm8994: Fix BLSP2_UART2 nodeKonrad Dybcio1-5/+7
Fix up the node to make the peripheral functional. Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org> Link: https://lore.kernel.org/r/20210118162432.107275-9-konrad.dybcio@somainline.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2021-01-25arm64: dts: qcom: msm8994-kitakami: Add VDD_GFX regulatorKonrad Dybcio1-0/+18
This is required for the GPU to function. Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org> Link: https://lore.kernel.org/r/20210118162432.107275-8-konrad.dybcio@somainline.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2021-01-25arm64: dts: qcom: msm8994-kitakami: Add uSD card supportKonrad Dybcio1-0/+10
Assign regulators and enable regulator-set-load on VMMC so as to provide sufficient power. Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org> Link: https://lore.kernel.org/r/20210118162432.107275-7-konrad.dybcio@somainline.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2021-01-25arm64: dts: qcom: msm8994-kitakami: Add Synaptics RMI touchscreenKonrad Dybcio2-1/+46
All Kitakami phones use Synaptics RMI4 touchscreens attached to the same i2c bus. Configure and enable it. Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org> Link: https://lore.kernel.org/r/20210118162432.107275-6-konrad.dybcio@somainline.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2021-01-25arm64: dts: qcom: msm/apq8994-kitakami: Add regulator configKonrad Dybcio7-59/+297
Add regulator config for all Kitakami devices, commonizing where applicable. Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org> Link: https://lore.kernel.org/r/20210118162432.107275-5-konrad.dybcio@somainline.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2021-01-25arm64: dts: qcom: msm8992/4: Rename vreg_vph_pwr to vph_pwrKonrad Dybcio2-5/+4
Rename the fixed regulator to follow the common naming scheme Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org> Link: https://lore.kernel.org/r/20210118162432.107275-4-konrad.dybcio@somainline.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2021-01-25arm64: dts: qcom: msm8992-libra: Update regulator configKonrad Dybcio1-22/+31
* Add PMI8994 RPM regulators * Add missing PM8994 LVSes * Add comments concerning "missing" regulators Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org> Link: https://lore.kernel.org/r/20210118162432.107275-3-konrad.dybcio@somainline.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2021-01-25arm64: dts: qcom: msm8992-bullhead: Update regulator configKonrad Dybcio1-12/+27
* Include pm(i)8994 dtsi * Add PMI8994 RPM regulators * Add comments concerning "missing" regulators Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org> Link: https://lore.kernel.org/r/20210118162432.107275-2-konrad.dybcio@somainline.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2021-01-25arm64: dts: qcom: Add support for remaining Sony Kitakami boardsKonrad Dybcio7-3/+97
This patch adds support for the following Xperias: * Z3+ [aka Z4 in some regions] (Ivy) * Z4 Tablet (Karin) * Z4 Tablet Wi-Fi (Karin_windy) [APQ8094] * Z5 Compact (Suzuran) * Z5 Premium (Satsuki) These devices are very similar in terms of hardware, with main differences being display panels. While at it, update comments describing hardware used: SMB charger seems to not be used after all, PMI8994 charger is in use instead. Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org> Link: https://lore.kernel.org/r/20210118162432.107275-1-konrad.dybcio@somainline.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2021-01-25arm64: dts: qcom: msm8992/4: Add RPM Power DomainsKonrad Dybcio2-0/+60
Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org> Link: https://lore.kernel.org/r/20210118161943.105733-2-konrad.dybcio@somainline.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2021-01-25KVM: arm64: Mark the page dirty only if the fault is handled successfullyYanan Wang1-5/+8
We now set the pfn dirty and mark the page dirty before calling fault handlers in user_mem_abort(), so we might end up having spurious dirty pages if update of permissions or mapping has failed. Let's move these two operations after the fault handlers, and they will be done only if the fault has been handled successfully. When an -EAGAIN errno is returned from the map handler, we hope to the vcpu to enter guest directly instead of exiting back to userspace, so adjust the return value at the end of function. Signed-off-by: Yanan Wang <wangyanan55@huawei.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210114121350.123684-4-wangyanan55@huawei.com
2021-01-25KVM: arm64: Filter out the case of only changing permissions from stage-2 ↵Yanan Wang2-11/+26
map path (1) During running time of a a VM with numbers of vCPUs, if some vCPUs access the same GPA almost at the same time and the stage-2 mapping of the GPA has not been built yet, as a result they will all cause translation faults. The first vCPU builds the mapping, and the followed ones end up updating the valid leaf PTE. Note that these vCPUs might want different access permissions (RO, RW, RX, RWX, etc.). (2) It's inevitable that we sometimes will update an existing valid leaf PTE in the map path, and we perform break-before-make in this case. Then more unnecessary translation faults could be caused if the *break stage* of BBM is just catched by other vCPUS. With (1) and (2), something unsatisfactory could happen: vCPU A causes a translation fault and builds the mapping with RW permissions, vCPU B then update the valid leaf PTE with break-before-make and permissions are updated back to RO. Besides, *break stage* of BBM may trigger more translation faults. Finally, some useless small loops could occur. We can make some optimization to solve above problems: When we need to update a valid leaf PTE in the map path, let's filter out the case where this update only change access permissions, and don't update the valid leaf PTE here in this case. Instead, let the vCPU enter back the guest and it will exit next time to go through the relax_perms path without break-before-make if it still wants more permissions. Signed-off-by: Yanan Wang <wangyanan55@huawei.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210114121350.123684-3-wangyanan55@huawei.com
2021-01-25KVM: arm64: Adjust partial code of hyp stage-1 map and guest stage-2 mapYanan Wang1-27/+28
Procedures of hyp stage-1 map and guest stage-2 map are quite different, but they are tied closely by function kvm_set_valid_leaf_pte(). So adjust the relative code for ease of code maintenance in the future. Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Yanan Wang <wangyanan55@huawei.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210114121350.123684-2-wangyanan55@huawei.com
2021-01-25KVM: arm64: Simplify __kvm_hyp_init HVC detectionAndrew Scull1-11/+4
The arguments for __do_hyp_init are now passed with a pointer to a struct which means there are scratch registers available for use. Thanks to this, we no longer need to use clever, but hard to read, tricks that avoid the need for scratch registers when checking for the __kvm_hyp_init HVC. Tested-by: David Brazdil <dbrazdil@google.com> Signed-off-by: Andrew Scull <ascull@google.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210125145415.122439-2-ascull@google.com
2021-01-25KVM: arm64: Don't clobber x4 in __do_hyp_initAndrew Scull1-9/+11
arm_smccc_1_1_hvc() only adds write contraints for x0-3 in the inline assembly for the HVC instruction so make sure those are the only registers that change when __do_hyp_init is called. Tested-by: David Brazdil <dbrazdil@google.com> Signed-off-by: Andrew Scull <ascull@google.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210125145415.122439-3-ascull@google.com
2021-01-25Merge v5.11-rc5 into usb-nextGreg Kroah-Hartman13-100/+51
We need the fixes in here and this resolves a merge issue with drivers/usb/gadget/udc/bdc/Kconfig. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-01-25Merge tag 'visconti-arm-dt-for-v5.11-tag2' of ↵Arnd Bergmann2-0/+17
git://git.kernel.org/pub/scm/linux/kernel/git/iwamatsu/linux-visconti into arm/dt Visconti device tree updates for 5.11 - Add watchdog support for TMPV7708 SoC - Add entries for Toshiba Visconti5 watchdog driver * tag 'visconti-arm-dt-for-v5.11-tag2' of git://git.kernel.org/pub/scm/linux/kernel/git/iwamatsu/linux-visconti: arm64: dts: visconti: Add watchdog support for TMPV7708 SoC MAINTAINERS: Add entries for Toshiba Visconti5 watchdog driver Link: https://lore.kernel.org/r/20210125003357.yd72y4f5vcdnvhnr@toshiba.co.jp Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2021-01-25arm64: dts: renesas: falcon: Enable MMCTakeshi Saito1-0/+41
Enable MMC on the Falcon board. Signed-off-by: Takeshi Saito <takeshi.saito.xv@renesas.com> Signed-off-by: Koji Matsuoka <koji.matsuoka.xm@renesas.com> [wsa: double checked, rebased, slightly improved, moved to falcon-cpu] Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://lore.kernel.org/r/20210125075845.3864-3-wsa+renesas@sang-engineering.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-01-25arm64: dts: renesas: r8a779a0: Add MMC nodeTakeshi Saito1-0/+12
Add a device node for MMC. Signed-off-by: Takeshi Saito <takeshi.saito.xv@renesas.com> Signed-off-by: Koji Matsuoka <koji.matsuoka.xm@renesas.com> [wsa: double checked & rebased] Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://lore.kernel.org/r/20210125075845.3864-2-wsa+renesas@sang-engineering.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-01-25arm64: dts: renesas: r8a779a0: Add HSCIF supportLinh Phung1-0/+64
Define the generic parts of the HSCIF[0-3] device nodes. Signed-off-by: Linh Phung <linh.phung.jy@renesas.com> Signed-off-by: Wolfram Sang <wsa@kernel.org> Link: https://lore.kernel.org/r/20210121110008.15894-4-wsa+renesas@sang-engineering.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-01-25arm64: dts: renesas: falcon: Complete SCIF0 nodesWolfram Sang1-0/+21
SCIF0 has been enabled by the firmware, so it worked already. Still, add the proper nodes to make it work in any case. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://lore.kernel.org/r/20210121110008.15894-3-wsa+renesas@sang-engineering.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-01-25arm64: dts: renesas: r8a779a0: Add & update SCIF nodesWolfram Sang1-0/+50
This is the result of multiple patches taken from the BSP, combined, rebased, and properly sorted. SCIF0 gets DMA properties, other SCIFs are entirely new. Signed-off-by: Linh Phung <linh.phung.jy@renesas.com> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://lore.kernel.org/r/20210121110008.15894-2-wsa+renesas@sang-engineering.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-01-25arm64: dts: renesas: falcon: Add Ethernet-AVB0 supportWolfram Sang2-0/+36
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://lore.kernel.org/r/20210121100619.5653-5-wsa+renesas@sang-engineering.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-01-25arm64: dts: renesas: r8a779a0: Add Ethernet-AVB supportTho Vu1-0/+282
Define the generic parts of Ethernet-AVB device nodes. Only AVB0 was tested because it was the only port with a PHY on current hardware. Signed-off-by: Tho Vu <tho.vu.wh@renesas.com> [wsa: double checked, rebased, added "internal-delay" properties] Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://lore.kernel.org/r/20210121100619.5653-4-wsa+renesas@sang-engineering.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-01-25arm64: dts: renesas: falcon: Add I2C0,1,6 supportWolfram Sang1-0/+41
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://lore.kernel.org/r/20210121095420.5023-4-wsa+renesas@sang-engineering.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-01-25arm64: dts: renesas: r8a779a0: Add I2C nodesKoji Matsuoka1-0/+122
Add I2C devicetree description to V3U Signed-off-by: Koji Matsuoka <koji.matsuoka.xm@renesas.com> [wsa: rebased and double checked] Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://lore.kernel.org/r/20210121095420.5023-3-wsa+renesas@sang-engineering.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-01-25arm64: dts: renesas: Disable SD functions for plain eMMCWolfram Sang7-0/+14
Some SDHI instances are solely used for eMMC. Disable SD and SDIO for faster initialization. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Acked-by: Adam Ford <aford173@gmail.com> (beacon) Link: https://lore.kernel.org/r/20210119133322.87289-1-wsa+renesas@sang-engineering.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-01-25arm64: dts: visconti: Add watchdog support for TMPV7708 SoCNobuhiro Iwamatsu2-0/+17
Add watchdog node in TMPV7708's dtsi, and tmpv7708-rm-mbrc boards's dts. Signed-off-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp>
2021-01-24fs: add mount_setattr()Christian Brauner2-1/+3
This implements the missing mount_setattr() syscall. While the new mount api allows to change the properties of a superblock there is currently no way to change the properties of a mount or a mount tree using file descriptors which the new mount api is based on. In addition the old mount api has the restriction that mount options cannot be applied recursively. This hasn't changed since changing mount options on a per-mount basis was implemented in [1] and has been a frequent request not just for convenience but also for security reasons. The legacy mount syscall is unable to accommodate this behavior without introducing a whole new set of flags because MS_REC | MS_REMOUNT | MS_BIND | MS_RDONLY | MS_NOEXEC | [...] only apply the mount option to the topmost mount. Changing MS_REC to apply to the whole mount tree would mean introducing a significant uapi change and would likely cause significant regressions. The new mount_setattr() syscall allows to recursively clear and set mount options in one shot. Multiple calls to change mount options requesting the same changes are idempotent: int mount_setattr(int dfd, const char *path, unsigned flags, struct mount_attr *uattr, size_t usize); Flags to modify path resolution behavior are specified in the @flags argument. Currently, AT_EMPTY_PATH, AT_RECURSIVE, AT_SYMLINK_NOFOLLOW, and AT_NO_AUTOMOUNT are supported. If useful, additional lookup flags to restrict path resolution as introduced with openat2() might be supported in the future. The mount_setattr() syscall can be expected to grow over time and is designed with extensibility in mind. It follows the extensible syscall pattern we have used with other syscalls such as openat2(), clone3(), sched_{set,get}attr(), and others. The set of mount options is passed in the uapi struct mount_attr which currently has the following layout: struct mount_attr { __u64 attr_set; __u64 attr_clr; __u64 propagation; __u64 userns_fd; }; The @attr_set and @attr_clr members are used to clear and set mount options. This way a user can e.g. request that a set of flags is to be raised such as turning mounts readonly by raising MOUNT_ATTR_RDONLY in @attr_set while at the same time requesting that another set of flags is to be lowered such as removing noexec from a mount tree by specifying MOUNT_ATTR_NOEXEC in @attr_clr. Note, since the MOUNT_ATTR_<atime> values are an enum starting from 0, not a bitmap, users wanting to transition to a different atime setting cannot simply specify the atime setting in @attr_set, but must also specify MOUNT_ATTR__ATIME in the @attr_clr field. So we ensure that MOUNT_ATTR__ATIME can't be partially set in @attr_clr and that @attr_set can't have any atime bits set if MOUNT_ATTR__ATIME isn't set in @attr_clr. The @propagation field lets callers specify the propagation type of a mount tree. Propagation is a single property that has four different settings and as such is not really a flag argument but an enum. Specifically, it would be unclear what setting and clearing propagation settings in combination would amount to. The legacy mount() syscall thus forbids the combination of multiple propagation settings too. The goal is to keep the semantics of mount propagation somewhat simple as they are overly complex as it is. The @userns_fd field lets user specify a user namespace whose idmapping becomes the idmapping of the mount. This is implemented and explained in detail in the next patch. [1]: commit 2e4b7fcd9260 ("[PATCH] r/o bind mounts: honor mount writer counts at remount") Link: https://lore.kernel.org/r/20210121131959.646623-35-christian.brauner@ubuntu.com Cc: David Howells <dhowells@redhat.com> Cc: Aleksa Sarai <cyphar@cyphar.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: linux-fsdevel@vger.kernel.org Cc: linux-api@vger.kernel.org Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
2021-01-23KVM: arm64: Remove hyp_symbol_addrDavid Brazdil5-43/+17
Hyp code used the hyp_symbol_addr helper to force PC-relative addressing because absolute addressing results in kernel VAs due to the way hyp code is linked. This is not true anymore, so remove the helper and update all of its users. Acked-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: David Brazdil <dbrazdil@google.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210105180541.65031-9-dbrazdil@google.com
2021-01-23KVM: arm64: Remove patching of fn pointers in hypDavid Brazdil4-32/+4
Storing a function pointer in hyp now generates relocation information used at early boot to convert the address to hyp VA. The existing alternative-based conversion mechanism is therefore obsolete. Remove it and simplify its users. Acked-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: David Brazdil <dbrazdil@google.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210105180541.65031-8-dbrazdil@google.com
2021-01-23KVM: arm64: Fix constant-pool users in hypDavid Brazdil3-42/+31
Hyp code uses absolute addressing to obtain a kimg VA of a small number of kernel symbols. Since the kernel now converts constant pool addresses to hyp VAs, this trick does not work anymore. Change the helpers to convert from hyp VA back to kimg VA or PA, as needed and rework the callers accordingly. Signed-off-by: David Brazdil <dbrazdil@google.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210105180541.65031-7-dbrazdil@google.com
2021-01-23KVM: arm64: Apply hyp relocations at runtimeDavid Brazdil4-1/+33
KVM nVHE code runs under a different VA mapping than the kernel, hence so far it avoided using absolute addressing because the VA in a constant pool is relocated by the linker to a kernel VA (see hyp_symbol_addr). Now the kernel has access to a list of positions that contain a kimg VA but will be accessed only in hyp execution context. These are generated by the gen-hyprel build-time tool and stored in .hyp.reloc. Add early boot pass over the entries and convert the kimg VAs to hyp VAs. Note that this requires for .hyp* ELF sections to be mapped read-write at that point. Signed-off-by: David Brazdil <dbrazdil@google.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210105180541.65031-6-dbrazdil@google.com
2021-01-23KVM: arm64: Generate hyp relocation dataDavid Brazdil4-3/+451
Add a post-processing step to compilation of KVM nVHE hyp code which calls a custom host tool (gen-hyprel) on the partially linked object file (hyp sections' names prefixed). The tool lists all R_AARCH64_ABS64 data relocations targeting hyp sections and generates an assembly file that will form a new section .hyp.reloc in the kernel binary. The new section contains an array of 32-bit offsets to the positions targeted by these relocations. Since these addresses of those positions will not be determined until linking of `vmlinux`, each 32-bit entry carries a R_AARCH64_PREL32 relocation with addend <section_base_sym> + <r_offset>. The linker of `vmlinux` will therefore fill the slot accordingly. This relocation data will be used at runtime to convert the kernel VAs at those positions to hyp VAs. Signed-off-by: David Brazdil <dbrazdil@google.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210105180541.65031-5-dbrazdil@google.com
2021-01-23KVM: arm64: Add symbol at the beginning of each hyp sectionDavid Brazdil2-4/+29
Generating hyp relocations will require referencing positions at a given offset from the beginning of hyp sections. Since the final layout will not be determined until the linking of `vmlinux`, modify the hyp linker script to insert a symbol at the first byte of each hyp section to use as an anchor. The linker of `vmlinux` will place the symbols together with the sections. Signed-off-by: David Brazdil <dbrazdil@google.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210105180541.65031-4-dbrazdil@google.com
2021-01-23KVM: arm64: Set up .hyp.rodata ELF sectionDavid Brazdil4-9/+11
We will need to recognize pointers in .rodata specific to hyp, so establish a .hyp.rodata ELF section. Merge it with the existing .hyp.data..ro_after_init as they are treated the same at runtime. Signed-off-by: David Brazdil <dbrazdil@google.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210105180541.65031-3-dbrazdil@google.com
2021-01-23KVM: arm64: Rename .idmap.text in hyp linker scriptDavid Brazdil2-1/+2
So far hyp-init.S created a .hyp.idmap.text section directly, without relying on the hyp linker script to prefix its name. Change it to create .idmap.text and add a HYP_SECTION entry to hyp.lds.S. This way all .hyp* sections go through the linker script and can be instrumented there. Signed-off-by: David Brazdil <dbrazdil@google.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210105180541.65031-2-dbrazdil@google.com
2021-01-23Merge tag 'imx-fixes-5.11-2' of ↵Arnd Bergmann1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into arm/fixes i.MX fixes for 5.11, round 2: - Fix pcf2127 reset for imx7d-flex-concentrator board. - Fix i.MX6 suspend with Thumb-2 kernel. - Fix ethernet-phy address issue on imx6qdl-sr-som board. - Fix GPIO3 `gpio-ranges` on i.MX8MP. - Select SOC_BUS for IMX_SCU driver to fix build issue. * tag 'imx-fixes-5.11-2' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux: firmware: imx: select SOC_BUS to fix firmware build arm64: dts: imx8mp: Correct the gpio ranges of gpio3 ARM: dts: imx6qdl-sr-som: fix some cubox-i platforms ARM: imx: build suspend-imx6.S with arm instruction set ARM: dts: imx7d-flex-concentrator: fix pcf2127 reset Link: https://lore.kernel.org/r/20210119091949.GD4356@dragon Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2021-01-23arm64: dts: broadcom: Fix USB DMA address translation for StingrayBharat Gooty1-1/+6
Add a non-empty dma-ranges so that DMA address translation happens. Fixes: 2013a4b684b6 ("arm64: dts: broadcom: clear the warnings caused by empty dma-ranges") Signed-off-by: Bharat Gooty <bharat.gooty@broadcom.com> Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Ray Jui <ray.jui@broadcom.com> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2021-01-22arm64: dts: qcom: Add missing "-thermal" suffix for thermal zonesManivannan Sadhasivam6-6/+6
The thermal devicetree binding requires the "-thermal" suffix for all thermal zones. Hence, add the missing suffix for PMIC based thermal zones. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Link: https://lore.kernel.org/r/20210118051005.55958-8-manivannan.sadhasivam@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2021-01-22arm64: kprobes: Fix Uexpected kernel BRK exception at EL1Qais Yousef1-2/+2
I was hitting the below panic continuously when attaching kprobes to scheduler functions [ 159.045212] Unexpected kernel BRK exception at EL1 [ 159.053753] Internal error: BRK handler: f2000006 [#1] PREEMPT SMP [ 159.059954] Modules linked in: [ 159.063025] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 5.11.0-rc4-00008-g1e2a199f6ccd #56 [rt-app] <notice> [1] Exiting.[ 159.071166] Hardware name: ARM Juno development board (r2) (DT) [ 159.079689] pstate: 600003c5 (nZCv DAIF -PAN -UAO -TCO BTYPE=--) [ 159.085723] pc : 0xffff80001624501c [ 159.089377] lr : attach_entity_load_avg+0x2ac/0x350 [ 159.094271] sp : ffff80001622b640 [rt-app] <notice> [0] Exiting.[ 159.097591] x29: ffff80001622b640 x28: 0000000000000001 [ 159.105515] x27: 0000000000000049 x26: ffff000800b79980 [ 159.110847] x25: ffff00097ef37840 x24: 0000000000000000 [ 159.116331] x23: 00000024eacec1ec x22: ffff00097ef12b90 [ 159.121663] x21: ffff00097ef37700 x20: ffff800010119170 [rt-app] <notice> [11] Exiting.[ 159.126995] x19: ffff00097ef37840 x18: 000000000000000e [ 159.135003] x17: 0000000000000001 x16: 0000000000000019 [ 159.140335] x15: 0000000000000000 x14: 0000000000000000 [ 159.145666] x13: 0000000000000002 x12: 0000000000000002 [ 159.150996] x11: ffff80001592f9f0 x10: 0000000000000060 [ 159.156327] x9 : ffff8000100f6f9c x8 : be618290de0999a1 [ 159.161659] x7 : ffff80096a4b1000 x6 : 0000000000000000 [ 159.166990] x5 : ffff00097ef37840 x4 : 0000000000000000 [ 159.172321] x3 : ffff000800328948 x2 : 0000000000000000 [ 159.177652] x1 : 0000002507d52fec x0 : ffff00097ef12b90 [ 159.182983] Call trace: [ 159.185433] 0xffff80001624501c [ 159.188581] update_load_avg+0x2d0/0x778 [ 159.192516] enqueue_task_fair+0x134/0xe20 [ 159.196625] enqueue_task+0x4c/0x2c8 [ 159.200211] ttwu_do_activate+0x70/0x138 [ 159.204147] sched_ttwu_pending+0xbc/0x160 [ 159.208253] flush_smp_call_function_queue+0x16c/0x320 [ 159.213408] generic_smp_call_function_single_interrupt+0x1c/0x28 [ 159.219521] ipi_handler+0x1e8/0x3c8 [ 159.223106] handle_percpu_devid_irq+0xd8/0x460 [ 159.227650] generic_handle_irq+0x38/0x50 [ 159.231672] __handle_domain_irq+0x6c/0xc8 [ 159.235781] gic_handle_irq+0xcc/0xf0 [ 159.239452] el1_irq+0xb4/0x180 [ 159.242600] rcu_is_watching+0x28/0x70 [ 159.246359] rcu_read_lock_held_common+0x44/0x88 [ 159.250991] rcu_read_lock_any_held+0x30/0xc0 [ 159.255360] kretprobe_dispatcher+0xc4/0xf0 [ 159.259555] __kretprobe_trampoline_handler+0xc0/0x150 [ 159.264710] trampoline_probe_handler+0x38/0x58 [ 159.269255] kretprobe_trampoline+0x70/0xc4 [ 159.273450] run_rebalance_domains+0x54/0x80 [ 159.277734] __do_softirq+0x164/0x684 [ 159.281406] irq_exit+0x198/0x1b8 [ 159.284731] __handle_domain_irq+0x70/0xc8 [ 159.288840] gic_handle_irq+0xb0/0xf0 [ 159.292510] el1_irq+0xb4/0x180 [ 159.295658] arch_cpu_idle+0x18/0x28 [ 159.299245] default_idle_call+0x9c/0x3e8 [ 159.303265] do_idle+0x25c/0x2a8 [ 159.306502] cpu_startup_entry+0x2c/0x78 [ 159.310436] secondary_start_kernel+0x160/0x198 [ 159.314984] Code: d42000c0 aa1e03e9 d42000c0 aa1e03e9 (d42000c0) After a bit of head scratching and debugging it turned out that it is due to kprobe handler being interrupted by a tick that causes us to go into (I think another) kprobe handler. The culprit was kprobe_breakpoint_ss_handler() returning DBG_HOOK_ERROR which leads to the Unexpected kernel BRK exception. Reverting commit ba090f9cafd5 ("arm64: kprobes: Remove redundant kprobe_step_ctx") seemed to fix the problem for me. Further analysis showed that kcb->kprobe_status is set to KPROBE_REENTER when the error occurs. By teaching kprobe_breakpoint_ss_handler() to handle this status I can no longer reproduce the problem. Fixes: ba090f9cafd5 ("arm64: kprobes: Remove redundant kprobe_step_ctx") Signed-off-by: Qais Yousef <qais.yousef@arm.com> Acked-by: Will Deacon <will@kernel.org> Acked-by: Masami Hiramatsu <mhiramat@kernel.org> Link: https://lore.kernel.org/r/20210122110909.3324607-1-qais.yousef@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2021-01-22Merge tag 'socfpga_dts_update_for_v5.12' of ↵Arnd Bergmann4-2/+61
git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux into arm/dt SoCFPGA DTS updates for v5.12 - Add DTS file for eASIC N5X platform - Use generic ngpios in GPIO entries - Add PMU node for Arria10 * tag 'socfpga_dts_update_for_v5.12' of git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux: ARM: dts: arria10: add PMU node arm64: dts: n5x: Add support for Intel's eASIC N5X platform arm64: dts: socfpga: Use generic "ngpios" rather than "snps,nr-gpios" Link: https://lore.kernel.org/r/20210120012334.25730-1-dinguyen@kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2021-01-22arm64: dts: ti: k3: mmc: fix dtbs_check warningsGrygorii Strashko3-15/+15
Now the dtbs_check produces below warnings sdhci@4f80000: clock-names:0: 'clk_ahb' was expected sdhci@4f80000: clock-names:1: 'clk_xin' was expected $nodename:0: 'sdhci@4f80000' does not match '^mmc(@.*)?$' Fix above warnings by updating mmc DT definitions to follow sdhci-am654.yaml bindings: - rename sdhci dt nodes to 'mmc@' - swap clk_xin/clk_ahb clocks, the clk_ahb clock expected to be defined first Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Suman Anna <s-anna@ti.com> Reviewed-by: Aswath Govindraju <a-govindraju@ti.com> Link: https://lore.kernel.org/r/20210115193016.5581-1-grygorii.strashko@ti.com
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-29 12:27:15 +0300