aboutsummaryrefslogtreecommitdiff
path: root/arch/arm64
AgeCommit message (Collapse)AuthorFilesLines
2020-10-30arm64: dts imx8mn: Remove non-existent USB OTG2Adam Ford1-30/+0
According to the i.MX8MN TRM, there is only one OTG port. The address for OTG2 is reserved on Nano. This patch removes the non-existent OTG2, usbphynop2, and the usbmisc2 nodes. Fixes: 6c3debcbae47 ("arm64: dts: freescale: Add i.MX8MN dtsi support") Signed-off-by: Adam Ford <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2020-10-30arm64: Change .weak to SYM_FUNC_START_WEAK_PI for arch/arm64/lib/mem*.SFangrui Song3-6/+3
Commit 39d114ddc682 ("arm64: add KASAN support") added .weak directives to arch/arm64/lib/mem*.S instead of changing the existing SYM_FUNC_START_PI macros. This can lead to the assembly snippet `.weak memcpy ... .globl memcpy` which will produce a STB_WEAK memcpy with GNU as but STB_GLOBAL memcpy with LLVM's integrated assembler before LLVM 12. LLVM 12 (since https://reviews.llvm.org/D90108) will error on such an overridden symbol binding. Use the appropriate SYM_FUNC_START_WEAK_PI instead. Fixes: 39d114ddc682 ("arm64: add KASAN support") Reported-by: Sami Tolvanen <[email protected]> Signed-off-by: Fangrui Song <[email protected]> Tested-by: Sami Tolvanen <[email protected]> Tested-by: Nick Desaulniers <[email protected]> Reviewed-by: Nick Desaulniers <[email protected]> Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
2020-10-30arm64/smp: Move rcu_cpu_starting() earlierQian Cai1-0/+1
The call to rcu_cpu_starting() in secondary_start_kernel() is not early enough in the CPU-hotplug onlining process, which results in lockdep splats as follows: WARNING: suspicious RCU usage ----------------------------- kernel/locking/lockdep.c:3497 RCU-list traversed in non-reader section!! other info that might help us debug this: RCU used illegally from offline CPU! rcu_scheduler_active = 1, debug_locks = 1 no locks held by swapper/1/0. Call trace: dump_backtrace+0x0/0x3c8 show_stack+0x14/0x60 dump_stack+0x14c/0x1c4 lockdep_rcu_suspicious+0x134/0x14c __lock_acquire+0x1c30/0x2600 lock_acquire+0x274/0xc48 _raw_spin_lock+0xc8/0x140 vprintk_emit+0x90/0x3d0 vprintk_default+0x34/0x40 vprintk_func+0x378/0x590 printk+0xa8/0xd4 __cpuinfo_store_cpu+0x71c/0x868 cpuinfo_store_cpu+0x2c/0xc8 secondary_start_kernel+0x244/0x318 This is avoided by moving the call to rcu_cpu_starting up near the beginning of the secondary_start_kernel() function. Signed-off-by: Qian Cai <[email protected]> Acked-by: Paul E. McKenney <[email protected]> Link: https://lore.kernel.org/lkml/160223032121.7002.1269740091547117869.tip-bot2@tip-bot2/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
2020-10-30arm64: dts: imx8mm-beacon-som: Add QSPI NOR flash supportAdam Ford1-0/+27
imx8mm-beacon-som has a Quad-SPI NOR flash connected to the FlexSPI bus. This patch enables the FlexSPI bus and configures it to work with the flash part. Signed-off-by: Adam Ford <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2020-10-30arm64: dts: imx8mm-beacon-som: Configure supplies on secondary cpusAdam Ford1-0/+12
Each cpu core should have a corresponding supply, but only cpu0 does. This patch adds a supply for each of the secondary cpus. Signed-off-by: Adam Ford <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2020-10-30arm64: dts: imx8mm-beacon-som: Fix Choppy BT audioAdam Ford1-0/+1
When streaming bluetooth audio, the sound is choppy due to the fact that the default baud rate of the HCI interface is too slow to handle 16-bit stereo at 48KHz. The Bluetooth chip is capable of up to 4M baud on the serial port, so this patch sets the max-speed to 4000000 in order to properly stream audio over the Bluetooth. Fixes: 593816fa2f35 ("arm64: dts: imx: Add Beacon i.MX8m-Mini development kit") Signed-off-by: Adam Ford <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2020-10-30arm64: dts: fsl: DPAA FMan DMA operations are coherentMadalin Bucur1-0/+1
Although the DPAA 1 FMan operations are coherent, the device tree node for the FMan does not indicate that, resulting in a needless loss of performance. Adding the missing dma-coherent property. Fixes: 1ffbecdd8321 ("arm64: dts: add DPAA FMan nodes") Signed-off-by: Madalin Bucur <[email protected]> Tested-by: Camelia Groza <[email protected]> Acked-by: Li Yang <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2020-10-30arm64: dts: Add the Kontron i.MX8M Mini SoMs and baseboardsFrieder Schrempf3-0/+617
Kontron Electronics GmbH offers small and powerful SoMs based on the i.MX8M Mini SoC including PMIC, LPDDR4-RAM, eMMC and SPI NOR. The matching baseboards have the same form factor and similar interfaces as the other boards from the Kontron "Board-Line" family, including SD card, 1G Ethernet, 100M Ethernet, USB Host/OTG, digital IOs, RS232, RS485, CAN, LVDS or HDMI, RTC and much more. Signed-off-by: Frieder Schrempf <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2020-10-30crypto: hash - Use memzero_explicit() for clearing stateArvind Sankar3-3/+3
Without the barrier_data() inside memzero_explicit(), the compiler may optimize away the state-clearing if it can tell that the state is not used afterwards. Signed-off-by: Arvind Sankar <[email protected]> Acked-by: Ard Biesheuvel <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2020-10-30arm64: dts: freescale: Add pmu support on imx8mnJacky Bai1-0/+7
Add PMU node to enable pmu support on imx8mn. Signed-off-by: Jacky Bai <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2020-10-30arm64: dts: freescale: Add pmu support on imx8mpJacky Bai1-0/+7
Add PMU node to enable pmu support on imx8mp. Signed-off-by: Jacky Bai <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2020-10-30arm64: dts: imx8mp: adjust GIC CPU mask to match number of CPUsKrzysztof Kozlowski1-4/+4
i.MX 8M Plus has four Cortex-A CPUs, not six. Using higher value is harmless but adjust it to match real HW. Signed-off-by: Krzysztof Kozlowski <[email protected]> Reviewed-by: Jacky Bai <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2020-10-30arm64: dts: imx8mn: adjust GIC CPU mask to match number of CPUsKrzysztof Kozlowski1-4/+4
i.MX 8M Nano has four Cortex-A CPUs, not six. Using higher value is harmless but adjust it to match real HW. Signed-off-by: Krzysztof Kozlowski <[email protected]> Reviewed-by: Jacky Bai <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2020-10-30arm64: dts: imx8mm: adjust GIC CPU mask to match number of CPUsKrzysztof Kozlowski1-5/+5
i.MX 8M Mini has four Cortex-A CPUs, not six. Using higher value is harmless but adjust it to match real HW. Signed-off-by: Krzysztof Kozlowski <[email protected]> Reviewed-by: Jacky Bai <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2020-10-30arm64: dts: freescale: align watchdog node name with dtschemaKrzysztof Kozlowski2-2/+2
The dtschema expects watchdog device node name to be "watchdog": arch/arm64/boot/dts/freescale/fsl-ls1012a-frdm.dt.yaml: wdog@2ad0000: $nodename:0: 'wdog@2ad0000' does not match '^watchdog(@.*|-[0-9a-f])?$' Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2020-10-30arm64: dts: fsl: fix endianness issue of rcpmBiwen Li3-0/+3
Add little-endian property to RCPM node (for ls1028a,ls1088a,ls208xa), otherwise RCPM driver will program hardware with incorrect setting, causing system (such as LS1028ARDB) failed to be waked by wakeup source. Fixes: 791c88ca5713 (“arm64: dts: ls1028a: Add ftm_alarm0 DT node”) Fixes: f4fe3a8665495 (“arm64: dts: layerscape: add ftm_alarm0 node”) Signed-off-by: Biwen Li <[email protected]> Signed-off-by: Ran Wang <[email protected]> Acked-by: Li Yang <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2020-10-30arm64: dts: imx8mn-evk: Add cpu-supply to enable cpufreqAnson Huang1-16/+16
PMIC driver is ready on i.MX8MN EVK board, assign cpu-supply for each A53 and restore the operating points table to enable cpufreq. Signed-off-by: Anson Huang <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2020-10-30arm64: dts: imx8mn-evk: fix missing PMIC's interrupt line pull-upKrzysztof Kozlowski1-0/+1
The PMIC's interrupt is level low and should be pulled up. The PMIC's device node had pinctrl-0 property but it lacked pinctrl-names which is required to apply the pin configuration. Fixes: 4153f7811a9b ("arm64: dts: imx8mn: correct interrupt flags") Fixes: 6386156eb279 ("arm64: dts: imx8mn-evk: add pca9450 for i.mx8mn-evk board") Signed-off-by: Krzysztof Kozlowski <[email protected]> Reviewed-by: Robin Gong <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2020-10-30arm64: dts: imx8mn-ddr4-evk: fix missing PMIC's interrupt line pull-upKrzysztof Kozlowski1-0/+1
The PMIC's interrupt is level low and should be pulled up. The PMIC's device node had pinctrl-0 property but it lacked pinctrl-names which is required to apply the pin configuration. Fixes: 4153f7811a9b ("arm64: dts: imx8mn: correct interrupt flags") Fixes: 3e44dd09736d ("arm64: dts: imx8mn-ddr4-evk: Add rohm,bd71847 PMIC support") Signed-off-by: Krzysztof Kozlowski <[email protected]> Reviewed-by: Robin Gong <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2020-10-30arm64: dts: imx8mn-var-som: fix missing PMIC's interrupt line pull-upKrzysztof Kozlowski1-6/+3
The PMIC's interrupt is level low and should be pulled up. The PMIC's device node had pinctrl-0 property but it lacked pinctrl-names which is required to apply the pin configuration. The actual problem in DTS was pointed out by Felix Radensky from Variscite. Reported-by: Felix Radensky <[email protected]> Fixes: ade0176dd8a0 ("arm64: dts: imx8mn-var-som: Add Variscite VAR-SOM-MX8MN System on Module") Signed-off-by: Krzysztof Kozlowski <[email protected]> Reviewed-by: Robin Gong <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2020-10-30arm64: dts: imx8mm-evk: fix missing PMIC's interrupt line pull-upKrzysztof Kozlowski1-0/+1
The PMIC's interrupt is level low and should be pulled up. The PMIC's device node had pinctrl-0 property but it lacked pinctrl-names which is required to apply the pin configuration. Fixes: 5f67317bd967 ("arm64: dts: imx8mm: correct interrupt flags") Fixes: aa71d0648318 ("arm64: dts: imx8mm: Split the imx8mm evk board dts to a common dtsi") Signed-off-by: Krzysztof Kozlowski <[email protected]> Reviewed-by: Robin Gong <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2020-10-30arm64: dts: imx8mm-beacon-som: fix missing PMIC's interrupt line pull-upKrzysztof Kozlowski1-0/+1
The PMIC's interrupt is level low and should be pulled up. The PMIC's device node had pinctrl-0 property but it lacked pinctrl-names which is required to apply the pin configuration. Fixes: 5f67317bd967 ("arm64: dts: imx8mm: correct interrupt flags") Fixes: 593816fa2f35 ("arm64: dts: imx: Add Beacon i.MX8m-Mini development kit") Signed-off-by: Krzysztof Kozlowski <[email protected]> Tested-by: Adam Ford <[email protected]> Reviewed-by: Robin Gong <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2020-10-30arm64: dts: imx8mm-var-som: fix missing PMIC's interrupt line pull-upKrzysztof Kozlowski1-6/+3
The PMIC's interrupt is level low and should be pulled up. The PMIC's device node had pinctrl-0 property but it lacked pinctrl-names which is required to apply the pin configuration. The actual problem in DTS was pointed out by Felix Radensky from Variscite. Reported-by: Felix Radensky <[email protected]> Fixes: 5f67317bd967 ("arm64: dts: imx8mm: correct interrupt flags") Signed-off-by: Krzysztof Kozlowski <[email protected]> Reviewed-by: Robin Gong <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2020-10-29KVM: arm64: Force PTE mapping on fault resulting in a device mappingSantosh Shukla1-0/+1
VFIO allows a device driver to resolve a fault by mapping a MMIO range. This can be subsequently result in user_mem_abort() to try and compute a huge mapping based on the MMIO pfn, which is a sure recipe for things to go wrong. Instead, force a PTE mapping when the pfn faulted in has a device mapping. Fixes: 6d674e28f642 ("KVM: arm/arm64: Properly handle faulting of device mappings") Suggested-by: Marc Zyngier <[email protected]> Signed-off-by: Santosh Shukla <[email protected]> [maz: rewritten commit message] Signed-off-by: Marc Zyngier <[email protected]> Reviewed-by: Gavin Shan <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected]
2020-10-29KVM: arm64: Use fallback mapping sizes for contiguous huge page sizesGavin Shan1-7/+19
Although huge pages can be created out of multiple contiguous PMDs or PTEs, the corresponding sizes are not supported at Stage-2 yet. Instead of failing the mapping, fall back to the nearer supported mapping size (CONT_PMD to PMD and CONT_PTE to PTE respectively). Suggested-by: Marc Zyngier <[email protected]> Signed-off-by: Gavin Shan <[email protected]> [maz: rewritten commit message] Signed-off-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-10-29KVM: arm64: Fix masks in stage2_pte_cacheable()Will Deacon1-1/+1
stage2_pte_cacheable() tries to figure out whether the mapping installed in its 'pte' parameter is cacheable or not. Unfortunately, it fails miserably because it extracts the memory attributes from the entry using FIELD_GET(), which returns the attributes shifted down to bit 0, but then compares this with the unshifted value generated by the PAGE_S2_MEMATTR() macro. A direct consequence of this bug is that cache maintenance is silently skipped, which in turn causes 32-bit guests to crash early on when their set/way maintenance is trapped but not emulated correctly. Fix the broken masks by avoiding the use of FIELD_GET() altogether. Fixes: 6d9d2115c480 ("KVM: arm64: Add support for stage-2 map()/unmap() in generic page-table") Reported-by: Marc Zyngier <[email protected]> Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Cc: Quentin Perret <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-10-29KVM: arm64: Fix AArch32 handling of DBGD{CCINT,SCRext} and DBGVCRMarc Zyngier2-3/+4
The DBGD{CCINT,SCRext} and DBGVCR register entries in the cp14 array are missing their target register, resulting in all accesses being targetted at the guard sysreg (indexed by __INVALID_SYSREG__). Point the emulation code at the actual register entries. Fixes: bdfb4b389c8d ("arm64: KVM: add trap handlers for AArch32 debug registers") Signed-off-by: Marc Zyngier <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected]
2020-10-29KVM: arm64: Allocate stage-2 pgd pages with GFP_KERNEL_ACCOUNTWill Deacon1-1/+1
For consistency with the rest of the stage-2 page-table page allocations (performing using a kvm_mmu_memory_cache), ensure that __GFP_ACCOUNT is included in the GFP flags for the PGD pages. Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Reviewed-by: Gavin Shan <[email protected]> Cc: Marc Zyngier <[email protected]> Cc: Quentin Perret <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-10-29KVM: arm64: Drop useless PAN setting on host EL1 to EL2 transitionMarc Zyngier1-2/+0
Setting PSTATE.PAN when entering EL2 on nVHE doesn't make much sense as this bit only means something for translation regimes that include EL0. This obviously isn't the case in the nVHE case, so let's drop this setting. Signed-off-by: Marc Zyngier <[email protected]> Reviewed-by: Vladimir Murzin <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-10-29KVM: arm64: Remove leftover kern_hyp_va() in nVHE TLB invalidationMarc Zyngier1-1/+0
The new calling convention says that pointers coming from the SMCCC interface are turned into their HYP version in the host HVC handler. However, there is still a stray kern_hyp_va() in the TLB invalidation code, which could result in a corrupted pointer. Drop the spurious conversion. Fixes: a071261d9318 ("KVM: arm64: nVHE: Fix pointers during SMCCC convertion") Signed-off-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-10-29KVM: arm64: Don't corrupt tpidr_el2 on failed HVC callMarc Zyngier1-7/+16
The hyp-init code starts by stashing a register in TPIDR_EL2 in in order to free a register. This happens no matter if the HVC call is legal or not. Although nothing wrong seems to come out of it, it feels odd to alter the EL2 state for something that eventually returns an error. Instead, use the fact that we know exactly which bits of the __kvm_hyp_init call are non-zero to perform the check with a series of EOR/ROR instructions, combined with a build-time check that the value is the one we expect. Signed-off-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-10-29arm64: Add workaround for Arm Cortex-A77 erratum 1508412Rob Herring12-15/+64
On Cortex-A77 r0p0 and r1p0, a sequence of a non-cacheable or device load and a store exclusive or PAR_EL1 read can cause a deadlock. The workaround requires a DMB SY before and after a PAR_EL1 register read. In addition, it's possible an interrupt (doing a device read) or KVM guest exit could be taken between the DMB and PAR read, so we also need a DMB before returning from interrupt and before returning to a guest. A deadlock is still possible with the workaround as KVM guests must also have the workaround. IOW, a malicious guest can deadlock an affected systems. This workaround also depends on a firmware counterpart to enable the h/w to insert DMB SY after load and store exclusive instructions. See the errata document SDEN-1152370 v10 [1] for more information. [1] https://static.docs.arm.com/101992/0010/Arm_Cortex_A77_MP074_Software_Developer_Errata_Notice_v10.pdf Signed-off-by: Rob Herring <[email protected]> Reviewed-by: Catalin Marinas <[email protected]> Acked-by: Marc Zyngier <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: James Morse <[email protected]> Cc: Suzuki K Poulose <[email protected]> Cc: Will Deacon <[email protected]> Cc: Julien Thierry <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
2020-10-29arm64: Add part number for Arm Cortex-A77Rob Herring1-0/+2
Add the MIDR part number info for the Arm Cortex-A77. Signed-off-by: Rob Herring <[email protected]> Acked-by: Catalin Marinas <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Will Deacon <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
2020-10-29arm64: dts: allwinner: h5: OrangePi Prime: Fix ethernet nodeNenad Peric1-1/+1
RX and TX delay are provided by ethernet PHY. Reflect that in ethernet node. Fixes: 44a94c7ef989 ("arm64: dts: allwinner: H5: Restore EMAC changes") Signed-off-by: Nenad Peric <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Acked-by: Jernej Skrabec <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-10-28arm64: dts: exynos: remove redundant status=okay in Exynos5433 TM2Krzysztof Kozlowski1-1/+0
New nodes are enabled by default, so status=okay is not needed for them. Signed-off-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-10-28arm64: dts: exynos: adjust node names to DT spec in Exynos7 EspressoKrzysztof Kozlowski1-1/+1
The Devicetree specification expects device node names to have a generic name, representing the class of a device. Also the convention for node names is to use hyphens, not underscores. No functional changes. Signed-off-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-10-28arm64: dts: exynos: adjust node names to DT spec in Exynos5433 TM2Krzysztof Kozlowski1-5/+5
The Devicetree specification expects device node names to have a generic name, representing the class of a device. Also the convention for node names is to use hyphens, not underscores. No functional changes. Signed-off-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-10-28arm64: efi: increase EFI PE/COFF header padding to 64 KBArd Biesheuvel1-1/+1
Commit 76085aff29f5 ("efi/libstub/arm64: align PE/COFF sections to segment alignment") increased the PE/COFF section alignment to match the minimum segment alignment of the kernel image, which ensures that the kernel does not need to be moved around in memory by the EFI stub if it was built as relocatable. However, the first PE/COFF section starts at _stext, which is only 4 KB aligned, and so the section layout is inconsistent. Existing EFI loaders seem to care little about this, but it is better to clean this up. So let's pad the header to 64 KB to match the PE/COFF section alignment. Fixes: 76085aff29f5 ("efi/libstub/arm64: align PE/COFF sections to segment alignment") Signed-off-by: Ard Biesheuvel <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
2020-10-28arm64: vmlinux.lds: account for spurious empty .igot.plt sectionsArd Biesheuvel1-1/+1
Now that we started making the linker warn about orphan sections (input sections that are not explicitly consumed by an output section), some configurations produce the following warning: aarch64-linux-gnu-ld: warning: orphan section `.igot.plt' from `arch/arm64/kernel/head.o' being placed in section `.igot.plt' It could be any file that triggers this - head.o is simply the first input file in the link - and the resulting .igot.plt section never actually appears in vmlinux as it turns out to be empty. So let's add .igot.plt to our collection of input sections to disregard unless they are empty. Signed-off-by: Ard Biesheuvel <[email protected]> Cc: Jessica Yu <[email protected]> Cc: Kees Cook <[email protected]> Cc: Geert Uytterhoeven <[email protected]> Cc: Nick Desaulniers <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
2020-10-28arm64: avoid -Woverride-init warningArnd Bergmann2-3/+5
The icache_policy_str[] definition causes a warning when extra warning flags are enabled: arch/arm64/kernel/cpuinfo.c:38:26: warning: initialized field overwritten [-Woverride-init] 38 | [ICACHE_POLICY_VIPT] = "VIPT", | ^~~~~~ arch/arm64/kernel/cpuinfo.c:38:26: note: (near initialization for 'icache_policy_str[2]') arch/arm64/kernel/cpuinfo.c:39:26: warning: initialized field overwritten [-Woverride-init] 39 | [ICACHE_POLICY_PIPT] = "PIPT", | ^~~~~~ arch/arm64/kernel/cpuinfo.c:39:26: note: (near initialization for 'icache_policy_str[3]') arch/arm64/kernel/cpuinfo.c:40:27: warning: initialized field overwritten [-Woverride-init] 40 | [ICACHE_POLICY_VPIPT] = "VPIPT", | ^~~~~~~ arch/arm64/kernel/cpuinfo.c:40:27: note: (near initialization for 'icache_policy_str[0]') There is no real need for the default initializer here, as printing a NULL string is harmless. Rewrite the logic to have an explicit reserved value for the only one that uses the default value. This partially reverts the commit that removed ICACHE_POLICY_AIVIVT. Fixes: 155433cb365e ("arm64: cache: Remove support for ASID-tagged VIVT I-caches") Signed-off-by: Arnd Bergmann <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
2020-10-28KVM: arm64: ARM_SMCCC_ARCH_WORKAROUND_1 doesn't return SMCCC_RET_NOT_REQUIREDStephen Boyd2-3/+1
According to the SMCCC spec[1](7.5.2 Discovery) the ARM_SMCCC_ARCH_WORKAROUND_1 function id only returns 0, 1, and SMCCC_RET_NOT_SUPPORTED. 0 is "workaround required and safe to call this function" 1 is "workaround not required but safe to call this function" SMCCC_RET_NOT_SUPPORTED is "might be vulnerable or might not be, who knows, I give up!" SMCCC_RET_NOT_SUPPORTED might as well mean "workaround required, except calling this function may not work because it isn't implemented in some cases". Wonderful. We map this SMC call to 0 is SPECTRE_MITIGATED 1 is SPECTRE_UNAFFECTED SMCCC_RET_NOT_SUPPORTED is SPECTRE_VULNERABLE For KVM hypercalls (hvc), we've implemented this function id to return SMCCC_RET_NOT_SUPPORTED, 0, and SMCCC_RET_NOT_REQUIRED. One of those isn't supposed to be there. Per the code we call arm64_get_spectre_v2_state() to figure out what to return for this feature discovery call. 0 is SPECTRE_MITIGATED SMCCC_RET_NOT_REQUIRED is SPECTRE_UNAFFECTED SMCCC_RET_NOT_SUPPORTED is SPECTRE_VULNERABLE Let's clean this up so that KVM tells the guest this mapping: 0 is SPECTRE_MITIGATED 1 is SPECTRE_UNAFFECTED SMCCC_RET_NOT_SUPPORTED is SPECTRE_VULNERABLE Note: SMCCC_RET_NOT_AFFECTED is 1 but isn't part of the SMCCC spec Fixes: c118bbb52743 ("arm64: KVM: Propagate full Spectre v2 workaround state to KVM guests") Signed-off-by: Stephen Boyd <[email protected]> Acked-by: Marc Zyngier <[email protected]> Acked-by: Will Deacon <[email protected]> Cc: Andre Przywara <[email protected]> Cc: Steven Price <[email protected]> Cc: Marc Zyngier <[email protected]> Cc: [email protected] Link: https://developer.arm.com/documentation/den0028/latest [1] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
2020-10-28arm64: dts: freescale: sl28: add CAN nodeMichael Walle1-0/+4
The module supports one CAN controller. Enable it. Signed-off-by: Michael Walle <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2020-10-28arm64: dts: ls1028a: add missing CAN nodesMichael Walle1-0/+18
The LS1028A has two FlexCAN controller. These are compatible with the ones from the LX2160A. Add the nodes. The first controller was tested on the Kontron sl28 board. Signed-off-by: Michael Walle <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2020-10-27arm64: dts: qcom: Switch sc7180-trogdor to control SPI CS via GPIODouglas Anderson1-3/+16
As talked about in the patch ("arm64: dts: qcom: sc7180: Provide pinconf for SPI to use GPIO for CS"), on some boards it makes much more sense (and is much more efficient) to think of the SPI Chip Select as a GPIO. Trogdor is one such board where the SPI parts don't run in GSI mode and we do a lot of SPI traffic. Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Stephen Boyd <[email protected]> Reviewed-by: Akash Asthana <[email protected]> Link: https://lore.kernel.org/r/20200921142655.v3.2.I3c57d8b6d83d5bdad73a413eea1e249a98d11973@changeid Signed-off-by: Bjorn Andersson <[email protected]>
2020-10-27arm64: dts: qcom: sc7180: Provide pinconf for SPI to use GPIO for CSDouglas Anderson1-0/+104
When the chip select line is controlled by the QUP, changing CS is a time consuming operation. We have to send a command over to the geni and wait for it to Ack us every time we want to change (both making it high and low). To send this command we have to make a choice in software when we want to control the chip select, we have to either: A) Wait for the Ack via interrupt which slows down all SPI transfers (and incurrs extra processing associated with interrupts). B) Sit in a loop and poll, waiting for the Ack. Neither A) nor B) is a great option. We can avoid all of this by realizing that, at least on some boards, there is no advantage of considering this line to be a geni line. While it's true that geni _can_ control the line, it's also true that the line can be a GPIO and there is no downside of viewing it that way. Setting a GPIO is a simple MMIO operation. This patch provides definitions so a board can easily select the GPIO mode. NOTE: apparently, it's possible to run the geni in "GSI" mode. In GSI the SPI port is allowed to be controlled by more than one user (like firmware and Linux) and also the port can operate sequences of operations in one go. In GSI mode it _would_ be invalid to look at the chip select as a GPIO because that would prevent other users from using it. In theory GSI mode would also avoid some overhead by allowing us to sequence the chip select better. However, I'll argue GSI is not relevant for all boards (and certainly not any boards supported by mainline today). Why? - Apparently to run a SPI chip in GSI mode you need to initialize it (in the bootloader) with a different firmware and then it will always run in GSI mode. Since there is no support for GSI mode in the current Linux driver, it must be that existing boards don't have firmware that's doing that. Note that the kernel device tree describes hardware but also firmware, so it is legitimate to make the assumption that we don't have GSI firmware in a given dts file. - Some boards with sc7180 have SPI connected to the Chrome OS EC or security chip (Cr50). The protocols for talking to cros_ec and cr50 are extremely complex. Both drivers in Linux fully lock the bus across several distinct SPI transfers. While I am not an expert on GSI mode it feels highly unlikely to me that we'd ever be able to enable GSI mode for these devices. From a testing perspective, running "flashrom -p ec -r /tmp/foo.bin" in a loop after this patch shows almost no reduction in time, but the number of interrupts per command goes from 32357 down to 30611 (about a 5% reduction). Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Stephen Boyd <[email protected]> Reviewed-by: Akash Asthana <[email protected]> Link: https://lore.kernel.org/r/20200921142655.v3.1.I997a428f58ef9d48b37a27a028360f34e66c00ec@changeid Signed-off-by: Bjorn Andersson <[email protected]>
2020-10-27arm64: use asm-generic/mmu_context.h for no-op implementationsNicholas Piggin1-4/+4
Signed-off-by: Nicholas Piggin <[email protected]> Acked-by: Catalin Marinas <[email protected]> Cc: Will Deacon <[email protected]> Cc: [email protected] Signed-off-by: Arnd Bergmann <[email protected]>
2020-10-27Merge tag 'amlogic-fixes' of ↵Arnd Bergmann5-2/+67
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic into arm/fixes Amlogic fixes for v5.10-rc1 - misc DT only fixes * tag 'amlogic-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic: arm64: dts: meson: odroid-n2 plus: fix vddcpu_a pwm ARM: dts: meson8: remove two invalid interrupt lines from the GPU node arm64: dts: amlogic: add missing ethernet reset ID arm64: dts: amlogic: meson-g12: use the G12A specific dwmac compatible arm64: dts: meson: add missing g12 rng clock arm64: dts: meson-axg-s400: enable USB OTG arm64: dts: meson-axg: add USB nodes Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnd Bergmann <[email protected]>
2020-10-26arm64: dts: exynos: Harmonize DWC USB3 DT nodes nameSerge Semin2-3/+3
In accordance with the DWC USB3 bindings the corresponding node name is suppose to comply with the Generic USB HCD DT schema, which requires the USB nodes to have the name acceptable by the regexp: "^usb(@.*)?" . Make sure the "snps,dwc3"-compatible nodes are correctly named. Signed-off-by: Serge Semin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Krzysztof Kozlowski <[email protected]>
2020-10-26arm64: dts: qcom: msm8916-pm8916: Stop using s1/l3 as regulatorsStephan Gerhold4-32/+2
s1 (VDDCX) and l3 (VDDMX) are now managed by rpmpd as power domains. This allows us to vote for voltage corners instead of voting for raw voltages. But we cannot manage these as regulator and power domain at the same time: The votes by rpmpd would conflict with the ones from the regulator driver. All users of these regulators have been converted to power domains. Make sure that no new users are added by removing s1 and l3 from the regulator definitions. This also allows us to remove the arbitrary voltage constraints we have been using for these regulators. Not all of the voltages listed there would actually have been safe for the boards. Signed-off-by: Stephan Gerhold <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]>
2020-10-26arm64: dts: qcom: msm8916: Use power domains for MSS/WCNSS remoteprocsStephan Gerhold2-3/+9
So far we have been making proxy votes for the remote processors through the regulator interface. Now that we have rpmpd it's better to vote for performance states through the power domain interface. This also allows us to move these supplies back to msm8916.dtsi because the device tree binding for RPMPD is independent of the underlying regulator/PMIC. Signed-off-by: Stephan Gerhold <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.