aboutsummaryrefslogtreecommitdiffstats
path: root/arch/arm64
AgeCommit message (Collapse)AuthorFilesLines
2021-05-25arm64: dts: renesas: beacon: Fix USB ref clock referencesAdam Ford1-2/+2
The RZ/G2 boards expect there to be an external clock reference for USB2 EHCI controllers. For the Beacon boards, this reference clock is controlled by a programmable versaclock. Because the RZ/G2 family has a special clock driver when using an external clock, the third clock reference in the EHCI node needs to point to this special clock, called usb2_clksel. Since the usb2_clksel does not keep the usb_extal clock enabled, the 4th clock entry for the EHCI nodes needs to reference it to keep the clock running and make USB functional. Signed-off-by: Adam Ford <aford173@gmail.com> Link: https://lore.kernel.org/r/20210513114617.30191-2-aford173@gmail.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-05-25arm64: dts: renesas: beacon: Fix USB extal referenceAdam Ford1-2/+4
The USB extal clock reference isn't associated to a crystal, it's associated to a programmable clock, so remove the extal reference, add the usb2_clksel. Since usb_extal is referenced by the versaclock, reference it here so the usb2_clksel can get the proper clock speed of 50MHz. Signed-off-by: Adam Ford <aford173@gmail.com> Link: https://lore.kernel.org/r/20210513114617.30191-1-aford173@gmail.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-05-25arm64: dts: renesas: eagle: Add x1 clockValentine Barshak1-0/+8
This adds X1 clock which supplies a frequency of 148.5 MHz. This clock is connected to the external dot clock input signal. Signed-off-by: Valentine Barshak <valentine.barshak@cogentembedded.com> [geert: Verified schematics] Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Link: https://lore.kernel.org/r/75a66bae21937da1c69e8024ce61b35aad4ac9b8.1620119570.git.geert+renesas@glider.be
2021-05-25arm64: dts: renesas: v3msk: Fix memory sizeValentine Barshak1-1/+1
The V3MSK board has 2 GiB RAM according to the datasheet and schematics. Signed-off-by: Valentine Barshak <valentine.barshak@cogentembedded.com> [geert: Verified schematics] Fixes: cc3e267e9bb0ce7f ("arm64: dts: renesas: initial V3MSK board device tree") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20210326121050.1578460-1-geert+renesas@glider.be
2021-05-25arm64: dts: renesas: condor: Switch eMMC bus to 1V8Wolfram Sang1-7/+1
The eMMC card has two supplies, VCC and VCCQ. The VCC supplies the NAND array and the VCCQ supplies the bus. On Condor, the VCC is connected to 3.3V rail, while the VCCQ is connected to 1.8V rail. Adjust the pinmux to match the bus, which is always operating in 1.8V mode. While at it, deduplicate the pinmux entries, which are now the same for both default and UHS modes. We still need the two pinctrl entries to match the bindings though. Thanks to Marek Vasut for this description from commit 5f65328df3f5cd25 ("arm64: dts: renesas: Switch eMMC bus to 1V8 on Salvator-X and ULCB"). Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://lore.kernel.org/r/20210419143858.39401-1-wsa+renesas@sang-engineering.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-05-25arm64: dts: renesas: falcon-csi-dsi: Add GPIO extendersNiklas Söderlund1-0/+21
We need to configure their GPIOs to power on the MAX96712s. Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Link: https://lore.kernel.org/r/20210413181447.2588084-1-niklas.soderlund+renesas@ragnatech.se Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-05-25arm64: dts: renesas: beacon kit: Setup AVB refclkAdam Ford1-0/+2
The AVB reference clock assumes an external clock that runs automatically. Because the Versaclock is wired to provide the AVB refclock, the device tree needs to reference it in order for the driver to start the clock. Signed-off-by: Adam Ford <aford173@gmail.com> Link: https://lore.kernel.org/r/20210224115146.9131-5-aford173@gmail.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-05-25arm64: dts: renesas: Add fck to etheravb-rcar-gen3 clock-names listAdam Ford13-0/+18
The bindings have been updated to support two clocks. Add a clock-names list in the device tree with fck in it. Signed-off-by: Adam Ford <aford173@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20210224115146.9131-3-aford173@gmail.com [geert: Update new r8a779a0.dtsi] Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-05-24arm64: dts: allwinner: pinephone: Set audio card nameArnaud Ferraris1-0/+1
Add the "PinePhone" name to the sound card: this will make upstreaming an ALSA UCM config easier as we can use a unique name. It also avoids an issue where the default card name is truncated. Signed-off-by: Arnaud Ferraris <arnaud.ferraris@collabora.com> [Samuel: Split out change, updated commit message] Signed-off-by: Samuel Holland <samuel@sholland.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20210430035859.3487-8-samuel@sholland.org
2021-05-23arm64: dts: freescale: sl28: var1: fix RGMII clock and voltageMichael Walle1-1/+2
During hardware validation it was noticed that the clock isn't continuously enabled when there is no link. This is because the 125MHz clock is derived from the internal PLL which seems to go into some kind of power-down mode every once in a while. The LS1028A expects a contiuous clock. Thus enable the PLL all the time. Also, the RGMII pad voltage is wrong, it was configured to 2.5V (that is the VDDH regulator). The correct voltage is 1.8V, i.e. the VDDIO regulator. This fix is for the freescale/fsl-ls1028a-kontron-sl28-var1.dts. Fixes: 642856097c18 ("arm64: dts: freescale: sl28: add variant 1") Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2021-05-23arm64: dts: freescale: sl28: var4: fix RGMII clock and voltageMichael Walle1-3/+2
During hardware validation it was noticed that the clock isn't continuously enabled when there is no link. This is because the 125MHz clock is derived from the internal PLL which seems to go into some kind of power-down mode every once in a while. The LS1028A expects a contiuous clock. Thus enable the PLL all the time. Also, the RGMII pad voltage is wrong. It was configured to 2.5V (that is the VDDH regulator). The correct voltage is 1.8V, i.e. the VDDIO regulator. This fix is for the freescale/fsl-ls1028a-kontron-sl28-var4.dts. Fixes: 815364d0424e ("arm64: dts: freescale: add Kontron sl28 support") Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2021-05-23arm64: dts: zii-ultra: fix 12V_MAIN voltageLucas Stach1-2/+2
As this is a fixed regulator on the board there was no harm in the wrong voltage being specified, apart from a confusing reporting to userspace. Fixes: 4a13b3bec3b4 ("arm64: dts: imx: add Zii Ultra board support") Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2021-05-23arm64: dts: zii-ultra: remove second GEN_3V3 regulator instanceLucas Stach2-19/+10
When adding the sound support a second instance of the GEN_3V3 regulator was added by accident. Remove it and point the consumers to the first instance. Fixes: 663a5b5efa51 ("arm64: dts: zii-ultra: add sound support") Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2021-05-22arm64: defconfig: enable Layerscape EDAC driverMichael Walle1-0/+1
Most Layerscape SoCs support ECC error reporting for the memory controller. Enable the corresponding module. In particular, this will enable EDAC support on the Kontron sl28 board which comes with ECC memory. Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2021-05-22arm64: dts: ls1028a: fix memory nodeMichael Walle1-2/+2
While enabling EDAC support for the LS1028A it was discovered that the memory node has a wrong endianness setting as well as a wrong interrupt assignment. Fix both. This was tested on a sl28 board. To force ECC errors, you can use the error injection supported by the controller in hardware (with CONFIG_EDAC_DEBUG enabled): # enable error injection $ echo 0x100 > /sys/devices/system/edac/mc/mc0/inject_ctrl # flip lowest bit of the data $ echo 0x1 > /sys/devices/system/edac/mc/mc0/inject_data_lo Fixes: 8897f3255c9c ("arm64: dts: Add support for NXP LS1028A SoC") Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2021-05-21arm64: dts: ti: k3-am65-iot2050-common: Disable mailbox nodesSuman Anna1-0/+48
There are no sub-mailbox devices defined currently for both the IOT2050 boards. These are usually dictated by the firmwares running on the R5F remote processors and the applications they provide. Defining the actual sub-mailboxes will also dictate the interrupts the clusters will use for interrupts on the Cortex-A53 cores. Disable all of the Mailbox clusters until the sub-mailboxes are defined and used. This fixes the warnings around the missing interrupts with the upcoming conversion of the OMAP Mailbox binding to YAML format. Signed-off-by: Suman Anna <s-anna@ti.com> Acked-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20210514212016.3153-1-s-anna@ti.com
2021-05-20Merge tag 'arm-soc-fixes-5.13-1' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/socLinus Torvalds16-8/+85
Pull ARM SoC fixes from Arnd Bergmann: "Only a small number of fixes so far, including some that I had applied during the merge window, so this is based on the original merge of the other branches. - The largest change is a fix for a reference counting bug in the AMD TEE driver. - Neil Armstrong now co-maintains Amlogic SoC support - Two build warning fixes for renesas device tree files - A sign expansion bug for optee - A DT binding fix for a mismerge" * tag 'arm-soc-fixes-5.13-1' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: ARM: npcm: wpcm450: select interrupt controller driver MAINTAINERS: ARM/Amlogic SoCs: add Neil as primary maintainer tee: amdtee: unload TA only when its refcount becomes 0 dt-bindings: nvmem: mediatek: remove duplicate mt8192 line firmware: arm_scmi: Remove duplicate declaration of struct scmi_protocol_handle firmware: arm_scpi: Prevent the ternary sign expansion bug arm64: dts: renesas: Add port@0 node for all CSI-2 nodes to dtsi arm64: dts: renesas: aistarvision-mipi-adapter-2.1: Fix CSI40 ports
2021-05-20bpf: Fix BPF_JIT kconfig symbol dependencyDaniel Borkmann1-2/+1
Randy reported a randconfig build error recently on i386: ld: arch/x86/net/bpf_jit_comp32.o: in function `do_jit': bpf_jit_comp32.c:(.text+0x28c9): undefined reference to `__bpf_call_base' ld: arch/x86/net/bpf_jit_comp32.o: in function `bpf_int_jit_compile': bpf_jit_comp32.c:(.text+0x3694): undefined reference to `bpf_jit_blind_constants' ld: bpf_jit_comp32.c:(.text+0x3719): undefined reference to `bpf_jit_binary_free' ld: bpf_jit_comp32.c:(.text+0x3745): undefined reference to `bpf_jit_binary_alloc' ld: bpf_jit_comp32.c:(.text+0x37d3): undefined reference to `bpf_jit_prog_release_other' [...] The cause was that b24abcff918a ("bpf, kconfig: Add consolidated menu entry for bpf with core options") moved BPF_JIT from net/Kconfig into kernel/bpf/Kconfig and previously BPF_JIT was guarded by a 'if NET'. However, there is no actual dependency on NET, it's just that menuconfig NET selects BPF. And the latter in turn causes kernel/bpf/core.o to be built which contains above symbols. Randy's randconfig didn't have NET set, and BPF wasn't either, but BPF_JIT otoh was. Detangle this by making BPF_JIT depend on BPF instead. arm64 was the only arch that pulled in its JIT in net/ via obj-$(CONFIG_NET), all others unconditionally pull this dir in via obj-y. Do the same since CONFIG_NET guard there is really useless as we compiled the JIT via obj-$(CONFIG_BPF_JIT) += bpf_jit_comp.o anyway. Fixes: b24abcff918a ("bpf, kconfig: Add consolidated menu entry for bpf with core options") Reported-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Randy Dunlap <rdunlap@infradead.org> Tested-by: Randy Dunlap <rdunlap@infradead.org>
2021-05-20arm64: dts: broadcom: normalize the node name of the UART devicesZhen Lei1-4/+4
Change the node name of the UART devices to match "^serial(@[0-9a-f,]+)*$". Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
2021-05-20Merge tag 'quota_for_v5.13-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fsLinus Torvalds1-2/+1
Pull quota fixes from Jan Kara: "The most important part in the pull is disablement of the new syscall quotactl_path() which was added in rc1. The reason is some people at LWN discussion pointed out dirfd would be useful for this path based syscall and Christian Brauner agreed. Without dirfd it may be indeed problematic for containers. So let's just disable the syscall for now when it doesn't have users yet so that we have more time to mull over how to best specify the filesystem we want to work on" * tag 'quota_for_v5.13-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs: quota: Disable quotactl_path syscall quota: Use 'hlist_for_each_entry' to simplify code
2021-05-19Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-nextDavid S. Miller1-13/+6
Alexei Starovoitov says: ==================== pull-request: bpf-next 2021-05-19 The following pull-request contains BPF updates for your *net-next* tree. We've added 43 non-merge commits during the last 11 day(s) which contain a total of 74 files changed, 3717 insertions(+), 578 deletions(-). The main changes are: 1) syscall program type, fd array, and light skeleton, from Alexei. 2) Stop emitting static variables in skeleton, from Andrii. 3) Low level tc-bpf api, from Kumar. 4) Reduce verifier kmalloc/kfree churn, from Lorenz. ====================
2021-05-18arm64: dts: allwinner: h5: Add NanoPi R1S H5 supportChukun Pan2-0/+196
The NanoPi R1S H5 is a open source board made by FriendlyElec. It has the following features: - Allwinner H5, Quad-core Cortex-A53 - 512MB DDR3 RAM - 10/100/1000M Ethernet x 2 - RTL8189ETV WiFi 802.11b/g/n - USB 2.0 host port (A) - MicroSD Slot - Serial Debug Port - 5V 2A DC power-supply Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20210516163523.9484-2-amadeus@jmu.edu.cn
2021-05-18bpf, arm64: Remove redundant switch case about BPF_DIV and BPF_MODTiezhu Yang1-9/+4
After commit 96a71005bdcb ("bpf, arm64: remove obsolete exception handling from div/mod"), there is no need to check twice about BPF_DIV and BPF_MOD, remove the redundant switch case. Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/1621328170-17583-1-git-send-email-yangtiezhu@loongson.cn
2021-05-18arm64: Fix stale link in the arch_counter_enforce_ordering() commentCatalin Marinas1-1/+1
With infradead.org archives gone, update the link to lore.kernel.org as these links are deemed stable. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2021-05-17quota: Disable quotactl_path syscallJan Kara1-2/+1
In commit fa8b90070a80 ("quota: wire up quotactl_path") we have wired up new quotactl_path syscall. However some people in LWN discussion have objected that the path based syscall is missing dirfd and flags argument which is mostly standard for contemporary path based syscalls. Indeed they have a point and after a discussion with Christian Brauner and Sascha Hauer I've decided to disable the syscall for now and update its API. Since there is no userspace currently using that syscall and it hasn't been released in any major release, we should be fine. CC: Christian Brauner <christian.brauner@ubuntu.com> CC: Sascha Hauer <s.hauer@pengutronix.de> Link: https://lore.kernel.org/lkml/20210512153621.n5u43jsytbik4yze@wittgenstein Signed-off-by: Jan Kara <jack@suse.cz>
2021-05-16Merge tag 'for-linus-5.13b-rc2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tipLinus Torvalds1-1/+2
Pull xen fixes from Juergen Gross: - two patches for error path fixes - a small series for fixing a regression with swiotlb with Xen on Arm * tag 'for-linus-5.13b-rc2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip: xen/swiotlb: check if the swiotlb has already been initialized arm64: do not set SWIOTLB_NO_FORCE when swiotlb is required xen/arm: move xen_swiotlb_detect to arm/swiotlb-xen.h xen/unpopulated-alloc: fix error return code in fill_list() xen/gntdev: fix gntdev_mmap() error exit path
2021-05-15KVM: arm64: Fix debug register indexingMarc Zyngier1-21/+21
Commit 03fdfb2690099 ("KVM: arm64: Don't write junk to sysregs on reset") flipped the register number to 0 for all the debug registers in the sysreg table, hereby indicating that these registers live in a separate shadow structure. However, the author of this patch failed to realise that all the accessors are using that particular index instead of the register encoding, resulting in all the registers hitting index 0. Not quite a valid implementation of the architecture... Address the issue by fixing all the accessors to use the CRm field of the encoding, which contains the debug register index. Fixes: 03fdfb2690099 ("KVM: arm64: Don't write junk to sysregs on reset") Reported-by: Ricardo Koller <ricarkol@google.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Cc: stable@vger.kernel.org
2021-05-15KVM: arm64: Commit pending PC adjustemnts before returning to userspaceMarc Zyngier4-2/+22
KVM currently updates PC (and the corresponding exception state) using a two phase approach: first by setting a set of flags, then by converting these flags into a state update when the vcpu is about to enter the guest. However, this creates a disconnect with userspace if the vcpu thread returns there with any exception/PC flag set. In this case, the exposed context is wrong, as userspace doesn't have access to these flags (they aren't architectural). It also means that these flags are preserved across a reset, which isn't expected. To solve this problem, force an explicit synchronisation of the exception state on vcpu exit to userspace. As an optimisation for nVHE systems, only perform this when there is something pending. Reported-by: Zenghui Yu <yuzenghui@huawei.com> Reviewed-by: Alexandru Elisei <alexandru.elisei@arm.com> Reviewed-by: Zenghui Yu <yuzenghui@huawei.com> Tested-by: Zenghui Yu <yuzenghui@huawei.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Cc: stable@vger.kernel.org # 5.11
2021-05-15KVM: arm64: Move __adjust_pc out of lineMarc Zyngier5-23/+21
In order to make it easy to call __adjust_pc() from the EL1 code (in the case of nVHE), rename it to __kvm_adjust_pc() and move it out of line. No expected functional change. Reviewed-by: Alexandru Elisei <alexandru.elisei@arm.com> Reviewed-by: Zenghui Yu <yuzenghui@huawei.com> Tested-by: Zenghui Yu <yuzenghui@huawei.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Cc: stable@vger.kernel.org # 5.11
2021-05-15KVM: arm64: Mark the host stage-2 memory pools staticQuentin Perret1-2/+2
The host stage-2 memory pools are not used outside of mem_protect.c, mark them static. Fixes: 1025c8c0c6ac ("KVM: arm64: Wrap the host with a stage 2") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Quentin Perret <qperret@google.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210514085640.3917886-3-qperret@google.com
2021-05-15KVM: arm64: Mark pkvm_pgtable_mm_ops staticQuentin Perret1-1/+1
It is not used outside of setup.c, mark it static. Fixes:f320bc742bc2 ("KVM: arm64: Prepare the creation of s1 mappings at EL2") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Quentin Perret <qperret@google.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210514085640.3917886-2-qperret@google.com
2021-05-15KVM: arm64: Fix boolreturn.cocci warningskernel test robot1-6/+6
arch/arm64/kvm/mmu.c:1114:9-10: WARNING: return of 0/1 in function 'kvm_age_gfn' with return type bool arch/arm64/kvm/mmu.c:1084:9-10: WARNING: return of 0/1 in function 'kvm_set_spte_gfn' with return type bool arch/arm64/kvm/mmu.c:1127:9-10: WARNING: return of 0/1 in function 'kvm_test_age_gfn' with return type bool arch/arm64/kvm/mmu.c:1070:9-10: WARNING: return of 0/1 in function 'kvm_unmap_gfn_range' with return type bool Return statements in functions returning bool should use true/false instead of 1/0. Generated by: scripts/coccinelle/misc/boolreturn.cocci Fixes: cd4c71835228 ("KVM: arm64: Convert to the gfn-based MMU notifier callbacks") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: kernel test robot <lkp@intel.com> Reviewed-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210426223357.GA45871@cd4295a34ed8
2021-05-14arm64: dts: rockchip: add gmac to rk3308 dtsTobias Schramm1-0/+22
The RK3308 SoC has a gmac with only the RMII interface exposed. This commit adds it to the RK3308 dtsi. Signed-off-by: Tobias Schramm <t.schramm@manjaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-14arm64: dts: ti: k3*: Introduce reg definition for interrupt routersNishanth Menon8-11/+22
Interrupt routers are memory mapped peripherals, that are organized in our dts bus hierarchy to closely represents the actual hardware behavior. However, without explicitly calling out the reg property, using 2021.03+ dt-schema package, this exposes the following problem with dtbs_check: /arch/arm64/boot/dts/ti/k3-am654-base-board.dt.yaml: bus@100000: interrupt-controller0: {'type': 'object'} is not allowed for {'compatible': ['ti,sci-intr'], ..... Even though we don't use interrupt router directly via memory mapped registers and have to use it via the system controller, the hardware block is memory mapped, so describe the base address in device tree. This is a valid, comprehensive description of hardware and permitted by the existing ti,sci-intr schema. Reviewed-by: Tero Kristo <kristo@kernel.org> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20210511194821.13919-1-nm@ti.com
2021-05-14arm64: dts: ti: k3-am65|j721e|am64: Map the dma / navigator subsystem via explicit rangesNishanth Menon5-10/+10
Instead of using empty ranges property, lets map explicitly the address range that is mapped onto the dma / navigator subsystems (navss/dmss). This is also exposed via the dtbs_check with dt-schema newer than 2021.03 version by throwing out following: arch/arm64/boot/dts/ti/k3-am654-base-board.dt.yaml: bus@100000: main-navss: {'type': 'object'} is not allowed for {'compatible': ['simple-mfd'], '#address-cells': [[2]], ..... This has already been correctly done for J7200, however was missed for other k3 SoCs. Fix that oversight. Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tero Kristo <kristo@kernel.org> Acked-by: Vignesh Raghavendra <vigneshr@ti.com> Link: https://lore.kernel.org/r/20210510145429.8752-1-nm@ti.com
2021-05-14arm64: dts: ti: k3-*: Rename the TI-SCI nodeNishanth Menon4-4/+4
Lets rename the node name of TI-SCI node to be system-controller as it is a better standardized name for the function that TI-SCI plays in the SoC. Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tero Kristo <kristo@kernel.org> Link: https://lore.kernel.org/r/20210510145033.7426-5-nm@ti.com
2021-05-14arm64: dts: ti: k3-am65-wakeup: Drop un-necessary properties from dmsc nodeNishanth Menon1-3/+0
The DMSC node does'nt require any of "#address-cells", "#size-cells" or "ranges" property as the child nodes are representations of SoC's system controller itself, so align it with the bindings. Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tero Kristo <kristo@kernel.org> Link: https://lore.kernel.org/r/20210510145033.7426-4-nm@ti.com
2021-05-14arm64: dts: ti: k3-am65-wakeup: Add debug region to TI-SCI nodeNishanth Menon1-1/+4
Lets add the TISCI debug region to TI-SCI region in line with TI-SCI documentation[1]. While at it, lets rename the node to indicate the address usage. [1] http://downloads.ti.com/tisci/esd/latest/4_trace/trace.html Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tero Kristo <kristo@kernel.org> Link: https://lore.kernel.org/r/20210510145033.7426-3-nm@ti.com
2021-05-14arm64: dts: ti: k3-*: Rename the TI-SCI clocks node nameNishanth Menon4-4/+4
We currently use clocks as the node name for the node representing TI-SCI clock nodes. This is better renamed to being clock-controller as that is a better representative of the system controller function as a clock controller for the SoC. Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tero Kristo <kristo@kernel.org> Link: https://lore.kernel.org/r/20210510145033.7426-2-nm@ti.com
2021-05-14arm64: dts: ti: j7200-main: Mark Main NAVSS as dma-coherentVignesh Raghavendra1-0/+2
Traffic through main NAVSS interconnect is coherent wrt ARM caches on J7200 SoC. Add missing dma-coherent property to main_navss node. Also add dma-ranges to be consistent with mcu_navss node and with AM65/J721e main_navss and mcu_navss nodes. Fixes: d361ed88455fe ("arm64: dts: ti: Add support for J7200 SoC") Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Peter Ujfalusi <peter.ujfalusi@gmail.com> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20210510180601.19458-1-vigneshr@ti.com
2021-05-14arm64: dts: ti: k3-am654-base-board: remove ov5640Tomi Valkeinen1-31/+0
AM654 EVM boards are not shipped with OV5640 sensor module, it is a separate purchase. OV5640 module is also just one of the possible sensors or capture boards you can connect. However, for some reason, OV5640 has been added to the board dts file, making it cumbersome to use other sensors. Remove the OV5640 from the dts file so that it is easy to use other sensors via DT overlays. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Acked-by: Pratyush Yadav <p.yadav@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20210423083120.73476-1-tomi.valkeinen@ideasonboard.com
2021-05-14arm64: Fix race condition on PG_dcache_clean in __sync_icache_dcache()Catalin Marinas1-1/+3
To ensure that instructions are observable in a new mapping, the arm64 set_pte_at() implementation cleans the D-cache and invalidates the I-cache to the PoU. As an optimisation, this is only done on executable mappings and the PG_dcache_clean page flag is set to avoid future cache maintenance on the same page. When two different processes map the same page (e.g. private executable file or shared mapping) there's a potential race on checking and setting PG_dcache_clean via set_pte_at() -> __sync_icache_dcache(). While on the fault paths the page is locked (PG_locked), mprotect() does not take the page lock. The result is that one process may see the PG_dcache_clean flag set but the I/D cache maintenance not yet performed. Avoid test_and_set_bit(PG_dcache_clean) in favour of separate test_bit() and set_bit(). In the rare event of a race, the cache maintenance is done twice. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Cc: <stable@vger.kernel.org> Cc: Will Deacon <will@kernel.org> Cc: Steven Price <steven.price@arm.com> Reviewed-by: Steven Price <steven.price@arm.com> Acked-by: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/20210514095001.13236-1-catalin.marinas@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2021-05-14arm64: dts: rename grf-gpio nodename in rk3328.dtsiJohan Jonker1-1/+1
A test with the command below gives this error: /arch/arm64/boot/dts/rockchip/rk3328-a1.dt.yaml: syscon@ff100000: grf-gpio: {'compatible': ['rockchip,rk3328-grf-gpio'], 'gpio-controller': True, '#gpio-cells': [[2]], 'phandle': [[68]]} is not of type 'array' Due to the regex "(?<!,nr)-gpios?$" anything that ends on '-gpio', '-gpios' gives a match. Rename 'grf-gpio' nodename to generic 'gpio' make ARCH=arm64 dtbs_check DT_SCHEMA_FILES=~/.local/lib/python3.5/site-packages/dtschema/ schemas/gpio/gpio-consumer.yaml Signed-off-by: Johan Jonker <jbx6244@gmail.com> Link: https://lore.kernel.org/r/20210512122346.9463-5-jbx6244@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2021-05-14arm64: do not set SWIOTLB_NO_FORCE when swiotlb is requiredChristoph Hellwig1-1/+2
Although SWIOTLB_NO_FORCE is meant to allow later calls to swiotlb_init, today dma_direct_map_page returns error if SWIOTLB_NO_FORCE. For now, without a larger overhaul of SWIOTLB_NO_FORCE, the best we can do is to avoid setting SWIOTLB_NO_FORCE in mem_init when we know that it is going to be required later (e.g. Xen requires it). CC: boris.ostrovsky@oracle.com CC: jgross@suse.com CC: catalin.marinas@arm.com CC: will@kernel.org CC: linux-arm-kernel@lists.infradead.org Fixes: 2726bf3ff252 ("swiotlb: Make SWIOTLB_NO_FORCE perform no allocation") Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com> Reviewed-by: Juergen Gross <jgross@suse.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Link: https://lore.kernel.org/r/20210512201823.1963-2-sstabellini@kernel.org Signed-off-by: Juergen Gross <jgross@suse.com>
2021-05-14arm64: dts: rockchip: Add support for PCIe on helios64Uwe Kleine-König1-0/+53
This is enough to make the SATA controller visible: # lspci 00:00.0 PCI bridge: Fuzhou Rockchip Electronics Co., Ltd RK3399 PCI Express Root Port 01:00.0 SATA controller: JMicron Technology Corp. JMB58x AHCI SATA controller Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org> Link: https://lore.kernel.org/r/20210510090932.970447-1-uwe@kleine-koenig.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2021-05-14arm64: dts: rockchip: Add support for two PWM fans on helios64Uwe Kleine-König1-0/+24
On the helios64 board the two connectors P6 and P7 are supposed to power two fans. Add the corresponding pwm-fan devices. Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org> Link: https://lore.kernel.org/r/20210510090607.970145-1-uwe@kleine-koenig.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2021-05-14arm64: dts: rockchip: fix regulator-gpio states arrayJohan Jonker5-9/+9
A test with the command below gives this error: /arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dt.yaml: sdmmcio-regulator: states:0: [1800000, 1, 3300000, 0] is too long dtbs_check expects regulator-gpio states in a format of 2 per item, so fix them all. make ARCH=arm64 dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/ regulator/gpio-regulator.yaml Signed-off-by: Johan Jonker <jbx6244@gmail.com> Link: https://lore.kernel.org/r/20210510215840.16270-1-jbx6244@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2021-05-14crypto: arm64 - use a pattern rule for generating *.S filesMasahiro Yamada1-4/+1
Unify similar build rules. sha256-core.S opts out it because it is generated from sha512-armv8.pl. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2021-05-14crypto: arm64 - generate *.S by Perl at build time instead of shipping themMasahiro Yamada4-4003/+3
Generate *.S by Perl like arch/{mips,x86}/crypto/Makefile. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2021-05-14arm64: defconfig: Allow Mediatek boards to boot from the mmcEnric Balletbo i Serra1-0/+1
Enable the MMC_MTK option necessary to boot Mediatek boards from the mmc. Booting from the mmc is the common method used for a bunch of boards, specially Chromebooks, to boot from. Hence this driver is built-in. Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Link: https://lore.kernel.org/r/20210423075250.2616275-1-enric.balletbo@collabora.com Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>