aboutsummaryrefslogtreecommitdiff
path: root/arch/arm64
AgeCommit message (Collapse)AuthorFilesLines
2020-12-02arm64: uaccess cleanup macro namingMark Rutland6-26/+26
Now the uaccess primitives use LDTR/STTR unconditionally, the uao_{ldp,stp,user_alternative} asm macros are misnamed, and have a redundant argument. Let's remove the redundant argument and rename these to user_{ldp,stp,ldst} respectively to clean this up. Signed-off-by: Mark Rutland <[email protected]> Reviewed-by: Robin Murohy <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: James Morse <[email protected]> Cc: Will Deacon <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Catalin Marinas <[email protected]>
2020-12-02arm64: uaccess: split user/kernel routinesMark Rutland2-65/+47
This patch separates arm64's user and kernel memory access primitives into distinct routines, adding new __{get,put}_kernel_nofault() helpers to access kernel memory, upon which core code builds larger copy routines. The kernel access routines (using LDR/STR) are not affected by PAN (when legitimately accessing kernel memory), nor are they affected by UAO. Switching to KERNEL_DS may set UAO, but this does not adversely affect the kernel access routines. The user access routines (using LDTR/STTR) are not affected by PAN (when legitimately accessing user memory), but are affected by UAO. As these are only legitimate to use under USER_DS with UAO clear, this should not be problematic. Routines performing atomics to user memory (futex and deprecated instruction emulation) still need to transiently clear PAN, and these are left as-is. These are never used on kernel memory. Subsequent patches will refactor the uaccess helpers to remove redundant code, and will also remove the redundant PAN/UAO manipulation. Signed-off-by: Mark Rutland <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: James Morse <[email protected]> Cc: Will Deacon <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Catalin Marinas <[email protected]>
2020-12-02arm64: uaccess: refactor __{get,put}_userMark Rutland1-17/+27
As a step towards implementing __{get,put}_kernel_nofault(), this patch splits most user-memory specific logic out of __{get,put}_user(), with the memory access and fault handling in new __{raw_get,put}_mem() helpers. For now the LDR/LDTR patching is left within the *get_mem() helpers, and will be removed in a subsequent patch. There should be no functional change as a result of this patch. Signed-off-by: Mark Rutland <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: James Morse <[email protected]> Cc: Will Deacon <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Catalin Marinas <[email protected]>
2020-12-02arm64: uaccess: simplify __copy_user_flushcache()Mark Rutland1-3/+1
Currently __copy_user_flushcache() open-codes raw_copy_from_user(), and doesn't use uaccess_mask_ptr() on the user address. Let's have it call raw_copy_from_user(), which is both a simplification and ensures that user pointers are masked under speculation. There should be no functional change as a result of this patch. Signed-off-by: Mark Rutland <[email protected]> Reviewed-by: Robin Murphy <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: Will Deacon <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Catalin Marinas <[email protected]>
2020-12-02arm64: uaccess: rename privileged uaccess routinesMark Rutland3-8/+8
We currently have many uaccess_*{enable,disable}*() variants, which subsequent patches will cut down as part of removing set_fs() and friends. Once this simplification is made, most uaccess routines will only need to ensure that the user page tables are mapped in TTBR0, as is currently dealt with by uaccess_ttbr0_{enable,disable}(). The existing uaccess_{enable,disable}() routines ensure that user page tables are mapped in TTBR0, and also disable PAN protections, which is necessary to be able to use atomics on user memory, but also permit unrelated privileged accesses to access user memory. As preparatory step, let's rename uaccess_{enable,disable}() to uaccess_{enable,disable}_privileged(), highlighting this caveat and discouraging wider misuse. Subsequent patches can reuse the uaccess_{enable,disable}() naming for the common case of ensuring the user page tables are mapped in TTBR0. There should be no functional change as a result of this patch. Signed-off-by: Mark Rutland <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: James Morse <[email protected]> Cc: Will Deacon <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Catalin Marinas <[email protected]>
2020-12-02arm64: sdei: explicitly simulate PAN/UAO entryMark Rutland2-6/+39
In preparation for removing addr_limit and set_fs() we must decouple the SDEI PAN/UAO manipulation from the uaccess code, and explicitly reinitialize these as required. SDEI enters the kernel with a non-architectural exception, and prior to the most recent revision of the specification (ARM DEN 0054B), PSTATE bits (e.g. PAN, UAO) are not manipulated in the same way as for architectural exceptions. Notably, older versions of the spec can be read ambiguously as to whether PSTATE bits are inherited unchanged from the interrupted context or whether they are generated from scratch, with TF-A doing the latter. We have three cases to consider: 1) The existing TF-A implementation of SDEI will clear PAN and clear UAO (along with other bits in PSTATE) when delivering an SDEI exception. 2) In theory, implementations of SDEI prior to revision B could inherit PAN and UAO (along with other bits in PSTATE) unchanged from the interrupted context. However, in practice such implementations do not exist. 3) Going forward, new implementations of SDEI must clear UAO, and depending on SCTLR_ELx.SPAN must either inherit or set PAN. As we can ignore (2) we can assume that upon SDEI entry, UAO is always clear, though PAN may be clear, inherited, or set per SCTLR_ELx.SPAN. Therefore, we must explicitly initialize PAN, but do not need to do anything for UAO. Considering what we need to do: * When set_fs() is removed, force_uaccess_begin() will have no HW side-effects. As this only clears UAO, which we can assume has already been cleared upon entry, this is not a problem. We do not need to add code to manipulate UAO explicitly. * PAN may be cleared upon entry (in case 1 above), so where a kernel is built to use PAN and this is supported by all CPUs, the kernel must set PAN upon entry to ensure expected behaviour. * PAN may be inherited from the interrupted context (in case 3 above), and so where a kernel is not built to use PAN or where PAN support is not uniform across CPUs, the kernel must clear PAN to ensure expected behaviour. This patch reworks the SDEI code accordingly, explicitly setting PAN to the expected state in all cases. To cater for the cases where the kernel does not use PAN or this is not uniformly supported by hardware we add a new cpu_has_pan() helper which can be used regardless of whether the kernel is built to use PAN. The existing system_uses_ttbr0_pan() is redefined in terms of system_uses_hw_pan() both for clarity and as a minor optimization when HW PAN is not selected. Signed-off-by: Mark Rutland <[email protected]> Reviewed-by: James Morse <[email protected]> Cc: James Morse <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: Will Deacon <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Catalin Marinas <[email protected]>
2020-12-02arm64: sdei: move uaccess logic to arch/arm64/Mark Rutland1-6/+12
The SDEI support code is split across arch/arm64/ and drivers/firmware/, largley this is split so that the arch-specific portions are under arch/arm64, and the management logic is under drivers/firmware/. However, exception entry fixups are currently under drivers/firmware. Let's move the exception entry fixups under arch/arm64/. This de-clutters the management logic, and puts all the arch-specific portions in one place. Doing this also allows the fixups to be applied earlier, so things like PAN and UAO will be in a known good state before we run other logic. This will also make subsequent refactoring easier. Signed-off-by: Mark Rutland <[email protected]> Reviewed-by: James Morse <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: Will Deacon <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Catalin Marinas <[email protected]>
2020-12-02arm64: head.S: always initialize PSTATEMark Rutland2-11/+26
As with SCTLR_ELx and other control registers, some PSTATE bits are UNKNOWN out-of-reset, and we may not be able to rely on hardware or firmware to initialize them to our liking prior to entry to the kernel, e.g. in the primary/secondary boot paths and return from idle/suspend. It would be more robust (and easier to reason about) if we consistently initialized PSTATE to a default value, as we do with control registers. This will ensure that the kernel is not adversely affected by bits it is not aware of, e.g. when support for a feature such as PAN/UAO is disabled. This patch ensures that PSTATE is consistently initialized at boot time via an ERET. This is not intended to relax the existing requirements (e.g. DAIF bits must still be set prior to entering the kernel). For features detected dynamically (which may require system-wide support), it is still necessary to subsequently modify PSTATE. As ERET is not always a Context Synchronization Event, an ISB is placed before each exception return to ensure updates to control registers have taken effect. This handles the kernel being entered with SCTLR_ELx.EOS clear (or any future control bits being in an UNKNOWN state). Signed-off-by: Mark Rutland <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: James Morse <[email protected]> Cc: Will Deacon <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Catalin Marinas <[email protected]>
2020-12-02arm64: head.S: cleanup SCTLR_ELx initializationMark Rutland3-10/+16
Let's make SCTLR_ELx initialization a bit clearer by using meaningful names for the initialization values, following the same scheme for SCTLR_EL1 and SCTLR_EL2. These definitions will be used more widely in subsequent patches. There should be no functional change as a result of this patch. Signed-off-by: Mark Rutland <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: James Morse <[email protected]> Cc: Will Deacon <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Catalin Marinas <[email protected]>
2020-12-02arm64: head.S: rename el2_setup -> init_kernel_elMark Rutland2-8/+9
For a while now el2_setup has performed some basic initialization of EL1 even when the kernel is booted at EL1, so the name is a little misleading. Further, some comments are stale as with VHE it doesn't drop the CPU to EL1. To clarify things, rename el2_setup to init_kernel_el, and update comments to be clearer as to the function's purpose. There should be no functional change as a result of this patch. Signed-off-by: Mark Rutland <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: James Morse <[email protected]> Cc: Will Deacon <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Catalin Marinas <[email protected]>
2020-12-02arm64: add C wrappers for SET_PSTATE_*()Mark Rutland3-3/+7
To make callsites easier to read, add trivial C wrappers for the SET_PSTATE_*() helpers, and convert trivial uses over to these. The new wrappers will be used further in subsequent patches. There should be no functional change as a result of this patch. Signed-off-by: Mark Rutland <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: James Morse <[email protected]> Cc: Will Deacon <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Catalin Marinas <[email protected]>
2020-12-02arm64: ensure ERET from kthread is illegalMark Rutland1-9/+8
For consistency, all tasks have a pt_regs reserved at the highest portion of their task stack. Among other things, this ensures that a task's SP is always pointing within its stack rather than pointing immediately past the end. While it is never legitimate to ERET from a kthread, we take pains to initialize pt_regs for kthreads as if this were legitimate. As this is never legitimate, the effects of an erroneous return are rarely tested. Let's simplify things by initializing a kthread's pt_regs such that an ERET is caught as an illegal exception return, and removing the explicit initialization of other exception context. Note that as spectre_v4_enable_task_mitigation() only manipulates the PSTATE within the unused regs this is safe to remove. As user tasks will have their exception context initialized via start_thread() or start_compat_thread(), this should only impact cases where something has gone very wrong and we'd like that to be clearly indicated. Signed-off-by: Mark Rutland <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: James Morse <[email protected]> Cc: Will Deacon <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Catalin Marinas <[email protected]>
2020-12-02KVM: arm64: Add usage of stage 2 fault lookup level in user_mem_abort()Yanan Wang3-2/+15
If we get a FSC_PERM fault, just using (logging_active && writable) to determine calling kvm_pgtable_stage2_map(). There will be two more cases we should consider. (1) After logging_active is configged back to false from true. When we get a FSC_PERM fault with write_fault and adjustment of hugepage is needed, we should merge tables back to a block entry. This case is ignored by still calling kvm_pgtable_stage2_relax_perms(), which will lead to an endless loop and guest panic due to soft lockup. (2) We use (FSC_PERM && logging_active && writable) to determine collapsing a block entry into a table by calling kvm_pgtable_stage2_map(). But sometimes we may only need to relax permissions when trying to write to a page other than a block. In this condition,using kvm_pgtable_stage2_relax_perms() will be fine. The ISS filed bit[1:0] in ESR_EL2 regesiter indicates the stage2 lookup level at which a D-abort or I-abort occurred. By comparing granule of the fault lookup level with vma_pagesize, we can strictly distinguish conditions of calling kvm_pgtable_stage2_relax_perms() or kvm_pgtable_stage2_map(), and the above two cases will be well considered. Suggested-by: Keqian Zhu <[email protected]> Signed-off-by: Yanan Wang <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Acked-by: Will Deacon <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-12-02KVM: arm64: Fix handling of merging tables into a block entryYanan Wang1-1/+7
When dirty logging is enabled, we collapse block entries into tables as necessary. If dirty logging gets canceled, we can end-up merging tables back into block entries. When this happens, we must not only free the non-huge page-table pages but also invalidate all the TLB entries that can potentially cover the block. Otherwise, we end-up with multiple possible translations for the same physical page, which can legitimately result in a TLB conflict. To address this, replease the bogus invalidation by IPA with a full VM invalidation. Although this is pretty heavy handed, it happens very infrequently and saves a bunch of invalidations by IPA. Signed-off-by: Yanan Wang <[email protected]> [maz: fixup commit message] Signed-off-by: Marc Zyngier <[email protected]> Acked-by: Will Deacon <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-12-02KVM: arm64: Fix memory leak on stage2 update of a valid PTEYanan Wang1-0/+9
When installing a new leaf PTE onto an invalid ptep, we need to get_page(ptep) to account for the new mapping. However, simply updating a valid PTE shouldn't result in any additional refcounting, as there is new mapping. This otherwise results in a page being forever wasted. Address this by fixing-up the refcount in stage2_map_walker_try_leaf() if the PTE was already valid, balancing out the later get_page() in stage2_map_walk_leaf(). Signed-off-by: Yanan Wang <[email protected]> [maz: update commit message, add comment in the code] Signed-off-by: Marc Zyngier <[email protected]> Acked-by: Will Deacon <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-12-01kbuild: Hoist '--orphan-handling' into KconfigNathan Chancellor2-4/+1
Currently, '--orphan-handling=warn' is spread out across four different architectures in their respective Makefiles, which makes it a little unruly to deal with in case it needs to be disabled for a specific linker version (in this case, ld.lld 10.0.1). To make it easier to control this, hoist this warning into Kconfig and the main Makefile so that disabling it is simpler, as the warning will only be enabled in a couple places (main Makefile and a couple of compressed boot folders that blow away LDFLAGS_vmlinx) and making it conditional is easier due to Kconfig syntax. One small additional benefit of this is saving a call to ld-option on incremental builds because we will have already evaluated it for CONFIG_LD_ORPHAN_WARN. To keep the list of supported architectures the same, introduce CONFIG_ARCH_WANT_LD_ORPHAN_WARN, which an architecture can select to gain this automatically after all of the sections are specified and size asserted. A special thanks to Kees Cook for the help text on this config. Link: https://github.com/ClangBuiltLinux/linux/issues/1187 Acked-by: Kees Cook <[email protected]> Acked-by: Michael Ellerman <[email protected]> (powerpc) Reviewed-by: Nick Desaulniers <[email protected]> Tested-by: Nick Desaulniers <[email protected]> Signed-off-by: Nathan Chancellor <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>
2020-12-01arm64: sdei: Push IS_ENABLED() checks down to callee functionsWill Deacon1-12/+18
Handling all combinations of the VMAP_STACK and SHADOW_CALL_STACK options in sdei_arch_get_entry_point() makes the code difficult to read, particularly when considering the error and cleanup paths. Move the checking of these options into the callee functions, so that they return early if the relevant option is not enabled. Signed-off-by: Will Deacon <[email protected]>
2020-12-01arm64: scs: use vmapped IRQ and SDEI shadow stacksSami Tolvanen5-20/+94
Use scs_alloc() to allocate also IRQ and SDEI shadow stacks instead of using statically allocated stacks. Signed-off-by: Sami Tolvanen <[email protected]> Acked-by: Will Deacon <[email protected]> Link: https://lore.kernel.org/r/[email protected] [will: Move CONFIG_SHADOW_CALL_STACK check into init_irq_scs()] Signed-off-by: Will Deacon <[email protected]>
2020-12-01arm64: dts: allwinner: H5: NanoPi Neo Plus2: phy-mode rgmii-idHeinrich Schuchardt1-1/+1
Since commit bbc4d71d6354 ("net: phy: realtek: fix rtl8211e rx/tx delay config") network is broken on the NanoPi Neo Plus2. This patch changes the phy-mode to use internal delays both for RX and TX as has been done for other boards affected by the same commit. Fixes: bbc4d71d6354 ("net: phy: realtek: fix rtl8211e rx/tx delay config") Signed-off-by: Heinrich Schuchardt <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-12-01arm64: dts: allwinner: A64 Sopine: phy-mode rgmii-idHeinrich Schuchardt1-1/+1
Since commit bbc4d71d6354 ("net: phy: realtek: fix rtl8211e rx/tx delay config") iSCSI booting fails on the Pine A64 LTS. This patch changes the phy-mode to use internal delays both for RX and TX as has been done for other boards affected by the same commit. Fixes: bbc4d71d6354 ("net: phy: realtek: fix rtl8211e rx/tx delay config") Signed-off-by: Heinrich Schuchardt <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-12-01arm64: dts: imx8mm-beacon-som: Assign PMIC clockAdam Ford1-0/+4
The PMIC throws an errors because the clock isn't assigned to it. Fix this by assigning the clocks info. Signed-off-by: Adam Ford <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2020-12-01arm64: dts: imx8mm-beacon-som: Configure RTC aliasesAdam Ford1-1/+6
On the i.MX8MM Beacon SOM, there is an RTC chip which is fed power from the baseboard during power off. The SNVS RTC integrated into the SoC is not fed power. Depending on the order the modules are loaded, this can be a problem if the external RTC isn't rtc0. Make the alias for rtc0 point to the external RTC all the time and rtc1 point to the SVNS in order to correctly hold date/time over a power-cycle. Signed-off-by: Adam Ford <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2020-12-01arm64: dts: imx8mn: Add node for SPDIFAdam Ford1-0/+24
The i.MX8M Nano can support SPDIF which is compatible to the IP used on the i.MX35. Add the node. Signed-off-by: Adam Ford <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2020-12-01arm64: dts: imx8mn: Add support for micfilAdam Ford1-0/+19
The i.MX8M Nano has supports the MICFIL digital interface. It's a 16-bit audio signal from a PDM microphone bitstream. The driver is already in the kernel, but the node is missing. Add the micfil node. Signed-off-by: Adam Ford <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2020-12-01arm64: dts: imx8mn: Add SAI nodesAdam Ford1-0/+72
The i.MX8M Nano has several SAI nodes available to it. Enable them. Signed-off-by: Adam Ford <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2020-12-01arm64: dts: imx8mn: Enable Asynchronous Sample Rate ConverterAdam Ford1-0/+28
The driver exists for the Enhanced Asynchronous Sample Rate Converter (EASRC) Controller, but there isn't a device tree entry for it. On the vendor kernel, they put this on a spba-bus for SDMA support. Add the node for the spba-bus with the easrc node inside. Signed-off-by: Adam Ford <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2020-12-01arm64: dts: ls1028a: make the eMMC and SD card controllers use fixed indicesVladimir Oltean3-0/+6
As the boot order in the kernel continues to change, sometimes it may happen that the eSDHC controller mmc@2150000 (the one for eMMC) gets probed before the one at mmc@2140000 (for external SD cards). The effect is that the eMMC controller gets the /dev/mmcblk0 name, and the SD card gets /dev/mmcblk1. Since the introduction of this SoC, that has never happened in practice, even though it was never guaranteed in theory. Setting "root=/dev/mmcblk0p2" in /proc/cmdline has always caused the kernel to use the second partition from the SD card as the rootfs. The NXP development boards are typically shipped with either - LSDK, which uses "root=UUID=", or - OpenIL, which uses "root=/dev/mmcblkNp2" So for OpenIL, let's preserve that old behavior by adding some aliases which create naming consistency (for LSDK it doesn't matter): - the SD card controller uses /dev/mmcblk0 - the eMMC controller uses /dev/mmcblk1 For the Kontron SL28 boards, Michael Walle says that they are shipped with "root=UUID=" already, so the probing order doesn't matter, but it is more natural to him for /dev/mmcblk0 to be the eMMC, so let's do it the other way around there. The aliases are parsed by mmc_alloc_host() in drivers/mmc/core/host.c. Cc: Ashish Kumar <[email protected]> Cc: Yangbo Lu <[email protected]> Cc: Michael Walle <[email protected]> Signed-off-by: Vladimir Oltean <[email protected]> Acked-by: Michael Walle <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2020-12-01arm64: defconfig: Enable more Librem 5 hardwareGuido Günther1-0/+12
This enables - CONFIG_BATTERY_MAX17042: battery chip - CONFIG_CHARGER_BQ25980: charge controller - CONFIG_DRM_PANEL_MANTIX_MLAF057WE5: LCD panel - CONFIG_GNSS/CONFIG_GNSS_MTK_SERIAL: GNSS receiver - CONFIG_IIO_ST_LSM6DSX: IMU - CONFIG_IMX_DCSS: 2nd display controller - CONFIG_LEDS_LM3692X: LCD backlight - CONFIG_REGULATOR_TPS65132: regulator for the LCD panel - CONFIG_TOUCHSCREEN_EDT_FT5X06: touch controller - CONFIG_TYPEC_TPS6598X: USB PD controller - CONFIG_VCNL4000: ambient light and proximity sensor as modules. Signed-off-by: Guido Günther <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2020-11-30arm64: dts: meson-sm1: fix typo in opp tableDongjin Kim1-1/+1
The freqency 1512000000 should be 1500000000. Signed-off-by: Dongjin Kim <[email protected]> Fixes: 3d9e76483049 ("arm64: dts: meson-sm1-sei610: enable DVFS") Reviewed-by: Neil Armstrong <[email protected]> Signed-off-by: Kevin Hilman <[email protected]> Link: https://lore.kernel.org/r/20201130060320.GA30098@anyang-linuxfactory-or-kr
2020-11-30arm64: dts: meson: add KHAMSIN IR remote node to SML5442TWChristian Hewitt1-0/+4
Set the IR keymap to the KHAMSIN remote shipped with the SML5442TW. Signed-off-by: Christian Hewitt <[email protected]> Signed-off-by: Kevin Hilman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-11-30arm64: dts: meson: update the Khadas VIM3/3L LED bindingsChristian Hewitt1-4/+7
Update the VIM3/3L common dtsi to use the new function/color bindings. Suggested-by: Artem Lapkin <[email protected]> Signed-off-by: Christian Hewitt <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Signed-off-by: Kevin Hilman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-11-30arm64: dts: meson: fix spi-max-frequency on Khadas VIM2Artem Lapkin1-1/+1
The max frequency for the w25q32 (VIM v1.2) and w25q128 (VIM v1.4) spifc chip should be 104Mhz not 30MHz. Fixes: b8b74dda3908 ("ARM64: dts: meson-gxm: Add support for Khadas VIM2") Signed-off-by: Artem Lapkin <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Signed-off-by: Kevin Hilman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-11-30arm64: dts: meson: add rtc aliases to meson-khadas-vim3.dtsiChristian Hewitt1-1/+3
Tweak the node name to make it aliasable, then add aliases for the on-board RTC chip and meson-vrtc timer so they probe as rtc0 and rtc1 respectively. before: VIM3:~ # dmesg | grep rtc [ 3.622530] meson-vrtc ff8000a8.rtc: registered as rtc0 [ 3.622574] meson-vrtc ff8000a8.rtc: setting system clock to 1970-01-01T00:00:03 UTC (3) [ 3.646936] rtc-hym8563 0-0051: no valid clock/calendar values available [ 3.647125] rtc-hym8563 0-0051: registered as rtc1 [ 3.852382] rtc-hym8563 0-0051: no valid clock/calendar values available after: VIM3:~ # dmesg | grep rtc [ 3.583735] meson-vrtc ff8000a8.rtc: registered as rtc1 [ 3.633888] rtc-hym8563 0-0051: no valid clock/calendar values available [ 3.634120] rtc-hym8563 0-0051: registered as rtc0 [ 3.635250] rtc-hym8563 0-0051: no valid clock/calendar values available [ 3.635267] rtc-hym8563 0-0051: hctosys: unable to read the hardware clock [ 3.852632] rtc-hym8563 0-0051: no valid clock/calendar values available Signed-off-by: Christian Hewitt <[email protected]> Signed-off-by: Kevin Hilman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-11-30arm64: dts: meson: Add capacity-dmips-mhz attributes to GXMChristian Hewitt1-0/+20
GXM (S912) is a big-little design with CPUs 0-3 clocked at 1.5GHz and CPUs 4-7 at 1.0GHz. Adding capacity-dmips-mhz attributes allows the scheduler to factor the different clock speeds into capacity calculations and prefer the higher-clocked cluster to improve overall performance. This was inspired by the similar change for G12B [0] boards. The diference here is that all cores are A53's so the same dmips-mhz value is used. VIM2:~ # cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq 1512000 1512000 1512000 1512000 1000000 1000000 1000000 1000000 before: VIM2:~ # cat /sys/devices/system/cpu/cpu*/cpu_capacity 1024 1024 1024 1024 1024 1024 1024 1024 after: VIM2:~ # cat /sys/devices/system/cpu/cpu*/cpu_capacity 1024 1024 1024 1024 677 677 677 677 The after value matches my table-napkin calculation: (1000000 / 1512000 = 0.661) * 1024 = 677 [0] https://github.com/torvalds/linux/commit/6eeaf4d2452ec8b1ece58776812140734fc2e088 Signed-off-by: Christian Hewitt <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Signed-off-by: Kevin Hilman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-11-30arm64: dts: meson-axg-s400: enable PCIe M.2 Key E slotsNeil Armstrong1-0/+10
Signed-off-by: Neil Armstrong <[email protected]> Signed-off-by: Kevin Hilman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-11-30arm64: dts: meson-axg: add PCIe nodesNeil Armstrong1-0/+61
This adds the nodes for the : - AXG PCIe PHY, using the shared analog PCIe/MIPI DSI PHY - 2x AXG PCIe controllers Signed-off-by: Neil Armstrong <[email protected]> Signed-off-by: Kevin Hilman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-11-30arm64: dts: meson-axg: add MIPI DSI PHY nodesNeil Armstrong1-0/+19
This adds the nodes for : - MIPI DSI+PCIe analog phy - MIPI D-PHY Signed-off-by: Neil Armstrong <[email protected]> Signed-off-by: Kevin Hilman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-11-30arm64: dts: meson-axg: add PWRC nodeNeil Armstrong1-0/+42
This adds the power controller PWRC node and the corresponding ethernet power domain. Signed-off-by: Neil Armstrong <[email protected]> Signed-off-by: Kevin Hilman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-11-30arm64: dts: meson: enable rtc node on Khadas VIM1/VIM2 boardsChristian Hewitt2-4/+2
Enable the rtc node on VIM1/VIM2 boards so users can simply attach a power cell and use the on-board RTC without modifying the device-tree. Cold boot with no cell attached is gracefully handled: VIM2:~ # dmesg | grep rtc [ 7.716150] rtc-hym8563 1-0051: no valid clock/calendar values available [ 7.716957] rtc-hym8563 1-0051: registered as rtc0 [ 7.729850] rtc-hym8563 1-0051: no valid clock/calendar values available [ 7.729877] rtc-hym8563 1-0051: hctosys: unable to read the hardware clock [ 8.126768] rtc-hym8563 1-0051: no valid clock/calendar values available Warm boot (and any boot with cell attached) recalls stored values resulting in consistently faster (re)boot times: VIM2:~ # dmesg | grep rtc [ 7.441671] rtc-hym8563 1-0051: registered as rtc0 [ 7.442663] rtc-hym8563 1-0051: setting system clock to 2020-11-16T05:49:59 UTC (1605505799) Suggested-by: Artem Lapkin <[email protected]> Signed-off-by: Christian Hewitt <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Signed-off-by: Kevin Hilman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-11-30arm64: defconfig: Enable RTC_DRV_HYM8563Jagan Teki1-0/+1
RTC HYM8563 used in the ARM64 Rockchip SoC's SDIO power sequence enablement. Enable it as module. Signed-off-by: Jagan Teki <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Heiko Stuebner <[email protected]>
2020-11-30arm64: mte: Fix typo in macro definitionVincenzo Frascino1-1/+1
UL in the definition of SYS_TFSR_EL1_TF1 was misspelled causing compilation issues when trying to implement in kernel MTE async mode. Fix the macro correcting the typo. Note: MTE async mode will be introduced with a future series. Fixes: c058b1c4a5ea ("arm64: mte: system register definitions") Cc: Catalin Marinas <[email protected]> Cc: Will Deacon <[email protected]> Signed-off-by: Vincenzo Frascino <[email protected]> Acked-by: Catalin Marinas <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
2020-11-30arm64: dts: qcom: c630: Define eDP bridge and panelBjorn Andersson1-0/+100
The Lenovo Yoga C630 drives the Boe NV133FHM-N61 eDP display from DSI using a TI SN65DSI86 bridge chip on I2C 10. Define the bridge and eDP panel and enable the display blocks. Tested-by: Steev Klimaszewski <[email protected]> Acked-by: Shawn Guo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]>
2020-11-30arm64: dts: qcom: c630: Fix pinctrl pins propertiesBjorn Andersson1-4/+4
The "pins" property takes an array of pin _names_, not pin numbers. Fix this. Tested-by: Steev Klimaszewski <[email protected]> Fixes: 44acee207844 ("arm64: dts: qcom: Add Lenovo Yoga C630") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]>
2020-11-30arm64: dts: qcom: c630: Polish i2c-hid devicesBjorn Andersson1-13/+18
The numbering of the i2c busses differs from ACPI and a number of typos was made in the original patch. Further more the irq flags for the various resources was not correct and i2c3 only has one of the two client devices active in any one device. Also label the various devices, for easier comparison with the ACPI tables. Tested-by: Steev Klimaszewski <[email protected]> Fixes: 44acee207844 ("arm64: dts: qcom: Add Lenovo Yoga C630") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]>
2020-11-30arm64: dts: qcom: sc7180: Add lpass cpu node for I2S driverAjit Pandey1-0/+69
Add the I2S controller node to sc7180 dtsi. Add pinmux for primary and secondary I2S. Reviewed-by: Srinivas Kandagatla <[email protected]> Signed-off-by: Ajit Pandey <[email protected]> Signed-off-by: Cheng-Yi Chiang <[email protected]> Signed-off-by: V Sujith Kumar Reddy <[email protected]> Signed-off-by: Srinivasa Rao Mandadapu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]>
2020-11-30arm64: dts: ipq6018: Add the QPIC peripheral nodesKathiravan T2-0/+57
Add the QPIC BAM and QPIC NAND controller support and enable the same in board DTS file. Co-developed-by: Anusha Canchi Ramachandra Rao <[email protected]> Signed-off-by: Anusha Canchi Ramachandra Rao <[email protected]> Signed-off-by: Kathiravan T <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]>
2020-11-30arm64: dts: sdm845: Add interconnect properties for QUPGeorgi Djakov1-0/+160
Add the interconnects DT property to describe the ports for GENI QUPs on the sdm845 platform. Signed-off-by: Georgi Djakov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]>
2020-11-30arm64: dts: qcom: c630: Expose LID eventsBjorn Andersson1-0/+39
The LID state can be read from GPIO 124 and the "tablet mode" from GPIO 95, expose these to the system using gpio-keys and mark the falling edge of the LID state as a wakeup-source - to wake the system from suspend. Tested-by: Steev Klimaszewski <[email protected]> Acked-by: Shawn Guo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]>
2020-11-30arm64: dts: qcom: c630: Re-enable apps_smmuBjorn Andersson1-5/+0
Re-enable the apps_smmu now that the arm-smmu driver supports stream mapping handoff from firmware. Tested-by: Steev Klimaszewski <[email protected]> Acked-by: Shawn Guo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]>
2020-11-30dts: qcom: sdm845: Add dt entries to support crypto engine.Thara Gopinath1-0/+30
Add crypto engine (CE) and CE BAM related nodes and definitions to "sdm845.dtsi". Signed-off-by: Thara Gopinath <[email protected]> Link: https://lore.kernel.org/r/[email protected] [bjorn: Replaced RPMH_CE_CLK constant, for now] Signed-off-by: Bjorn Andersson <[email protected]>