aboutsummaryrefslogtreecommitdiff
path: root/arch/arm64
AgeCommit message (Collapse)AuthorFilesLines
2020-11-10KVM: arm64: Consolidate exception injectionMarc Zyngier4-102/+73
Move the AArch32 exception injection code back into the inject_fault.c file, removing the need for a few non-static functions now that AArch32 host support is a thing of the past. Signed-off-by: Marc Zyngier <[email protected]>
2020-11-10KVM: arm64: Remove SPSR manipulation primitivesMarc Zyngier2-122/+0
The SPSR setting code is now completely unused, including that dealing with banked AArch32 SPSRs. Cleanup time. Acked-by: Mark Rutland <[email protected]> Signed-off-by: Marc Zyngier <[email protected]>
2020-11-10KVM: arm64: Inject AArch32 exceptions from HYPMarc Zyngier2-154/+195
Similarly to what has been done for AArch64, move the AArch32 exception injection to HYP. In order to not use the regmap selection code at EL2, simplify the code populating the target mode's LR register by useing the compatibility aliases for LR_abt and LR_und. We also introduce new accessors for SPSR_abt and SPSR_und, and move VBAR/SCTLR to using the AArch64 accessors (the use of the AArch32 names was an ARMv7 leftover). Acked-by: Mark Rutland <[email protected]> Signed-off-by: Marc Zyngier <[email protected]>
2020-11-10KVM: arm64: Inject AArch64 exceptions from HYPMarc Zyngier3-108/+154
Move the AArch64 exception injection code from EL1 to HYP, leaving only the ESR_EL1 updates to EL1. In order to come with the differences between VHE and nVHE, two set of system register accessors are provided. SPSR, ELR, PC and PSTATE are now completely handled in the hypervisor. Signed-off-by: Marc Zyngier <[email protected]>
2020-11-10KVM: arm64: Add basic hooks for injecting exceptions from EL2Marc Zyngier5-6/+53
Add the basic infrastructure to describe injection of exceptions into a guest. So far, nothing uses this code path. Signed-off-by: Marc Zyngier <[email protected]>
2020-11-10KVM: arm64: Move VHE direct sysreg accessors into kvm_host.hMarc Zyngier2-81/+91
As we are about to need to access system registers from the HYP code based on their internal encoding, move the direct sysreg accessors to a common include file, with a VHE-specific guard. No functionnal change. Acked-by: Mark Rutland <[email protected]> Signed-off-by: Marc Zyngier <[email protected]>
2020-11-10KVM: arm64: Move PC rollback on SError to HYPMarc Zyngier2-17/+15
Instead of handling the "PC rollback on SError during HVC" at EL1 (which requires disclosing PC to a potentially untrusted kernel), let's move this fixup to ... fixup_guest_exit(), which is where we do all fixups. Isn't that neat? Signed-off-by: Marc Zyngier <[email protected]>
2020-11-10KVM: arm64: Make kvm_skip_instr() and co private to HYPMarc Zyngier12-31/+77
In an effort to remove the vcpu PC manipulations from EL1 on nVHE systems, move kvm_skip_instr() to be HYP-specific. EL1's intent to increment PC post emulation is now signalled via a flag in the vcpu structure. Signed-off-by: Marc Zyngier <[email protected]>
2020-11-10KVM: arm64: Move kvm_vcpu_trap_il_is32bit into kvm_skip_instr32()Marc Zyngier6-12/+12
There is no need to feed the result of kvm_vcpu_trap_il_is32bit() to kvm_skip_instr(), as only AArch32 has a variable length ISA, and this helper can equally be called from kvm_skip_instr32(), reducing the complexity at all the call sites. Acked-by: Mark Rutland <[email protected]> Signed-off-by: Marc Zyngier <[email protected]>
2020-11-10KVM: arm64: Don't adjust PC on SError during SMC trapMarc Zyngier1-8/+8
On SMC trap, the prefered return address is set to that of the SMC instruction itself. It is thus wrong to try and roll it back when an SError occurs while trapping on SMC. It is still necessary on HVC though, as HVC doesn't cause a trap, and sets ELR to returning *after* the HVC. It also became apparent that there is no 16bit encoding for an AArch32 HVC instruction, meaning that the displacement is always 4 bytes, no matter what the ISA is. Take this opportunity to simplify it. Acked-by: Mark Rutland <[email protected]> Signed-off-by: Marc Zyngier <[email protected]>
2020-11-10arm64: dts: renesas: hihope-rev4: Add a comment explaining switch SW2404Lad Prabhakar1-1/+5
Switch SW2404 should be at position 1 so that the clock output from CS2000 is connected to AUDIO_CLKB_A. Signed-off-by: Lad Prabhakar <[email protected]> Reviewed-by: Chris Paterson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]>
2020-11-10arm64: dts: renesas: r8a77961: ulcb-kf: Initial device treeEugeniu Rosca2-0/+16
Create a dedicated DTB for M3-ES3.0 + ULCB + Kingfisher combo. Inspire from the pre-existing ULCB-KF device trees: $ ls -1 arch/arm64/boot/dts/renesas/*ulcb-kf.dts arch/arm64/boot/dts/renesas/r8a77950-ulcb-kf.dts arch/arm64/boot/dts/renesas/r8a77951-ulcb-kf.dts arch/arm64/boot/dts/renesas/r8a77960-ulcb-kf.dts arch/arm64/boot/dts/renesas/r8a77965-ulcb-kf.dts Signed-off-by: Eugeniu Rosca <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]>
2020-11-10arm64: dts: renesas: r8a77961: Add CAN{0,1} placeholder nodesEugeniu Rosca1-0/+10
With the same background and purpose as described in v4.20-rc1 commit 92bc66bfce99cd ("arm64: dts: renesas: r8a77965: Add CAN{0,1} placeholder nodes"), add can0 and can1 placeholder nodes. Signed-off-by: Eugeniu Rosca <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]>
2020-11-10arm64: dts: renesas: beacon-renesom-baseboard: Move connector node out of ↵Biju Das1-17/+50
hd3ss3220 device Move connector node out of hd3ss3220 device in order to comply with usb connector bindings. Signed-off-by: Biju Das <[email protected]> Reviewed-by: Lad Prabhakar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]>
2020-11-10arm64: dts: renesas: cat874: Move connector node out of hd3ss3220 deviceBiju Das1-17/+50
Move connector node out of hd3ss3220 device in order to comply with usb connector bindings. Signed-off-by: Biju Das <[email protected]> Reviewed-by: Lad Prabhakar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]>
2020-11-10arm64: dts: renesas: rzg2: Convert EtherAVB to explicit delay handlingGeert Uytterhoeven6-2/+10
Some EtherAVB variants support internal clock delay configuration, which can add larger delays than the delays that are typically supported by the PHY (using an "rgmii-*id" PHY mode, and/or "[rt]xc-skew-ps" properties). Historically, the EtherAVB driver configured these delays based on the "rgmii-*id" PHY mode. This was wrong, as these are meant solely for the PHY, not for the MAC. Hence properties were introduced for explicit configuration of these delays. Convert the RZ/G2 DTS files from the old to the new scheme: - Add default "rx-internal-delay-ps" and "tx-internal-delay-ps" properties to the SoC .dtsi files, to be overridden by board files where needed, - Convert board files from "rgmii-*id" PHY modes to "rgmii", adding the appropriate "rx-internal-delay-ps" and/or "tx-internal-delay-ps" overrides. Notes: - RZ/G2E does not support TX internal delay handling. Signed-off-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-11-10arm64: dts: renesas: rcar-gen3: Convert EtherAVB to explicit delay handlingGeert Uytterhoeven12-4/+20
Some EtherAVB variants support internal clock delay configuration, which can add larger delays than the delays that are typically supported by the PHY (using an "rgmii-*id" PHY mode, and/or "[rt]xc-skew-ps" properties). Historically, the EtherAVB driver configured these delays based on the "rgmii-*id" PHY mode. This was wrong, as these are meant solely for the PHY, not for the MAC. Hence properties were introduced for explicit configuration of these delays. Convert the R-Car Gen3 DTS files from the old to the new scheme: - Add default "rx-internal-delay-ps" and "tx-internal-delay-ps" properties to the SoC .dtsi files, to be overridden by board files where needed, - Convert board files from "rgmii-*id" PHY modes to "rgmii", adding the appropriate "rx-internal-delay-ps" and/or "tx-internal-delay-ps" overrides. Notes: - R-Car E3 and D3 do not support TX internal delay handling, - On R-Car D3, TX internal delay handling must always be enabled, hence this fixes a bug on Draak, - On R-Car V3H, RX internal delay handling must always be enabled. Signed-off-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-11-10arm64: dts: renesas: r8a77965: Add DRIF supportFabrizio Castro1-0/+120
Add the DRIF controller nodes for r8a77965 (a.k.a. R-Car M3-N). Signed-off-by: Fabrizio Castro <[email protected]> Reviewed-by: Lad Prabhakar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]>
2020-11-10arm64: defconfig: Enable R8A779A0 SoCGeert Uytterhoeven1-0/+1
Enable the Renesas R-Car V3U (R8A779A0) SoC in the ARM64 defconfig. Signed-off-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-11-10arm64: dts: imx8mm: fix voltage for 1.6GHz CPU operating pointLucas Stach1-1/+1
The datasheet for both the industrial and consumer variant of the SoC lists a typical voltage of 0.95V for the 1.6GHz CPU operating point. Fixes: e85c9d0faa75 (arm64: dts: imx8mm: Add cpufreq properties) Signed-off-by: Lucas Stach <[email protected]> Reviewed-by: Fabio Estevam <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2020-11-09arm64: meson: ship only the necessary clock controllersJerome Brunet1-3/+0
There now the menu entries for the amlogic clock controllers. Do not select these when ARM64 is enabled so it possible to ship only the required. Signed-off-by: Jerome Brunet <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Acked-by: Kevin Hilman <[email protected]> Signed-off-by: Kevin Hilman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-11-09Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds3-83/+43
Pull kvm fixes from Paolo Bonzini: "ARM: - fix compilation error when PMD and PUD are folded - fix regression in reads-as-zero behaviour of ID_AA64ZFR0_EL1 - add aarch64 get-reg-list test x86: - fix semantic conflict between two series merged for 5.10 - fix (and test) enforcement of paravirtual cpuid features selftests: - various cleanups to memory management selftests - new selftests testcase for performance of dirty logging" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: (30 commits) KVM: selftests: allow two iterations of dirty_log_perf_test KVM: selftests: Introduce the dirty log perf test KVM: selftests: Make the number of vcpus global KVM: selftests: Make the per vcpu memory size global KVM: selftests: Drop pointless vm_create wrapper KVM: selftests: Add wrfract to common guest code KVM: selftests: Simplify demand_paging_test with timespec_diff_now KVM: selftests: Remove address rounding in guest code KVM: selftests: Factor code out of demand_paging_test KVM: selftests: Use a single binary for dirty/clear log test KVM: selftests: Always clear dirty bitmap after iteration KVM: selftests: Add blessed SVE registers to get-reg-list KVM: selftests: Add aarch64 get-reg-list test selftests: kvm: test enforcement of paravirtual cpuid features selftests: kvm: Add exception handling to selftests selftests: kvm: Clear uc so UCALL_NONE is being properly reported selftests: kvm: Fix the segment descriptor layout to match the actual layout KVM: x86: handle MSR_IA32_DEBUGCTLMSR with report_ignored_msrs kvm: x86: request masterclock update any time guest uses different msr kvm: x86: ensure pv_cpuid.features is initialized when enabling cap ...
2020-11-09arm64: lto: Strengthen READ_ONCE() to acquire when CONFIG_LTO=yWill Deacon4-3/+76
When building with LTO, there is an increased risk of the compiler converting an address dependency headed by a READ_ONCE() invocation into a control dependency and consequently allowing for harmful reordering by the CPU. Ensure that such transformations are harmless by overriding the generic READ_ONCE() definition with one that provides acquire semantics when building with LTO. Acked-by: Peter Zijlstra (Intel) <[email protected]> Acked-by: Mark Rutland <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2020-11-09arm64: alternatives: Remove READ_ONCE() usage during patch operationWill Deacon1-3/+4
In preparation for patching the internals of READ_ONCE() itself, replace its usage on the alternatives patching patch with a volatile variable instead. Acked-by: Peter Zijlstra (Intel) <[email protected]> Acked-by: Mark Rutland <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2020-11-09arm64: cpufeatures: Add capability for LDAPR instructionWill Deacon3-1/+15
Armv8.3 introduced the LDAPR instruction, which provides weaker memory ordering semantics than LDARi (RCpc vs RCsc). Generally, we provide an RCsc implementation when implementing the Linux memory model, but LDAPR can be used as a useful alternative to dependency ordering, particularly when the compiler is capable of breaking the dependencies. Since LDAPR is not available on all CPUs, add a cpufeature to detect it at runtime and allow the instruction to be used with alternative code patching. Acked-by: Peter Zijlstra (Intel) <[email protected]> Acked-by: Mark Rutland <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2020-11-09arm64: alternatives: Split up alternative.hWill Deacon5-209/+222
asm/alternative.h contains both the macros needed to use alternatives, as well the type definitions and function prototypes for applying them. Split the header in two, so that alternatives can be used from core header files such as linux/compiler.h without the risk of circular includes Acked-by: Peter Zijlstra (Intel) <[email protected]> Acked-by: Mark Rutland <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2020-11-09arm64: uaccess: move uao_* alternatives to asm-uaccess.hMark Rutland3-60/+60
The uao_* alternative asm macros are only used by the uaccess assembly routines in arch/arm64/lib/, where they are included indirectly via asm-uaccess.h. Since they're specific to the uaccess assembly (and will lose the alternatives in subsequent patches), let's move them into asm-uaccess.h. There should be no functional change as a result of this patch. Signed-off-by: Mark Rutland <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: James Morse <[email protected]> Cc: Will Deacon <[email protected]> [will: update #include in mte.S to pull in uao asm macros] Signed-off-by: Will Deacon <[email protected]>
2020-11-09arm64: mm: tidy up top of kernel VA spaceArd Biesheuvel2-3/+3
Tidy up the way the top of the kernel VA space is organized, by mirroring the 256 MB region we have below the vmalloc space, and populating it top down with the PCI I/O space, some guard regions, and the fixmap region. The latter region is itself populated top down, and today only covers about 4 MB, and so 224 MB is ample, and no guard region is therefore required. The resulting layout is identical between 48-bit/4k and 52-bit/64k configurations. Signed-off-by: Ard Biesheuvel <[email protected]> Reviewed-by: Steve Capper <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Catalin Marinas <[email protected]>
2020-11-09arm64: mm: make vmemmap region a projection of the linear regionArd Biesheuvel2-8/+8
Now that we have reverted the introduction of the vmemmap struct page pointer and the separate physvirt_offset, we can simplify things further, and place the vmemmap region in the VA space in such a way that virtual to page translations and vice versa can be implemented using a single arithmetic shift. One happy coincidence resulting from this is that the 48-bit/4k and 52-bit/64k configurations (which are assumed to be the two most prevalent) end up with the same placement of the vmemmap region. In a subsequent patch, we will take advantage of this, and unify the memory maps even more. Signed-off-by: Ard Biesheuvel <[email protected]> Reviewed-by: Steve Capper <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Catalin Marinas <[email protected]>
2020-11-09arm64: mm: extend linear region for 52-bit VA configurationsArd Biesheuvel3-18/+16
For historical reasons, the arm64 kernel VA space is configured as two equally sized halves, i.e., on a 48-bit VA build, the VA space is split into a 47-bit vmalloc region and a 47-bit linear region. When support for 52-bit virtual addressing was added, this equal split was kept, resulting in a substantial waste of virtual address space in the linear region: 48-bit VA 52-bit VA 0xffff_ffff_ffff_ffff +-------------+ +-------------+ | vmalloc | | vmalloc | 0xffff_8000_0000_0000 +-------------+ _PAGE_END(48) +-------------+ | linear | : : 0xffff_0000_0000_0000 +-------------+ : : : : : : : : : : : : : : : : : currently : : unusable : : : : : : unused : : by : : : : : : : : hardware : : : : : : : 0xfff8_0000_0000_0000 : : _PAGE_END(52) +-------------+ : : | | : : | | : : | | : : | | : : | | : unusable : | | : : | linear | : by : | | : : | region | : hardware : | | : : | | : : | | : : | | : : | | : : | | : : | | 0xfff0_0000_0000_0000 +-------------+ PAGE_OFFSET +-------------+ As illustrated above, the 52-bit VA kernel uses 47 bits for the vmalloc space (as before), to ensure that a single 64k granule kernel image can support any 64k granule capable system, regardless of whether it supports the 52-bit virtual addressing extension. However, due to the fact that the VA space is still split in equal halves, the linear region is only 2^51 bytes in size, wasting almost half of the 52-bit VA space. Let's fix this, by abandoning the equal split, and simply assigning all VA space outside of the vmalloc region to the linear region. The KASAN shadow region is reconfigured so that it ends at the start of the vmalloc region, and grows downwards. That way, the arrangement of the vmalloc space (which contains kernel mappings, modules, BPF region, the vmemmap array etc) is identical between non-KASAN and KASAN builds, which aids debugging. Signed-off-by: Ard Biesheuvel <[email protected]> Reviewed-by: Steve Capper <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Catalin Marinas <[email protected]>
2020-11-09perf/arch: Remove perf_sample_data::regs_user_copyPeter Zijlstra1-2/+1
struct perf_sample_data lives on-stack, we should be careful about it's size. Furthermore, the pt_regs copy in there is only because x86_64 is a trainwreck, solve it differently. Reported-by: Thomas Gleixner <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Tested-by: Steven Rostedt <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2020-11-09KVM: arm64: Turn host HVC handling into a dispatch tableMarc Zyngier2-94/+135
Now that we can use function pointer, use a dispatch table to call the individual HVC handlers, leading to more maintainable code. Further improvements include helpers to declare the mapping of local variables to values passed in the host context. Reviewed-by: Alexandru Elisei <[email protected]> Signed-off-by: Marc Zyngier <[email protected]>
2020-11-09KVM: arm64: Add kimg_hyp_va() helperMarc Zyngier2-0/+68
KVM/arm64 is so far unable to deal with function pointers, as the compiler will generate the kernel's runtime VA, and not the linear mapping address, meaning that kern_hyp_va() will give the wrong result. We so far have been able to use PC-relative addressing, but that's not always easy to use, and prevents the implementation of things like the mapping of an index to a pointer. To allow this, provide a new helper that computes the required translation from the kernel image to the HYP VA space. Signed-off-by: Marc Zyngier <[email protected]>
2020-11-09arm64: add support for TIF_NOTIFY_SIGNALJens Axboe2-2/+5
Wire up TIF_NOTIFY_SIGNAL handling for arm64. Cc: [email protected] Acked-by: Will Deacon <[email protected]> Acked-by: Catalin Marinas <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2020-11-09arm64: dts: renesas: r8a774e1: Add missing audio_clk_bLad Prabhakar1-0/+6
Add audio_clk_b configured as 0 Hz, this will be overridden by the boards providing the audio clock. Fixes: 8183a7938cfec ("arm64: dts: renesas: r8a774e1: Add audio support") Reported-by: Nobuhiro Iwamatsu <[email protected]> Signed-off-by: Lad Prabhakar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]>
2020-11-08arm64: dts: rockchip: Add Engicam PX30.Core C.TOUCH 2.0Jagan Teki2-0/+23
PX30.Core is an EDIMM SOM based on Rockchip PX30 from Engicam. C.TOUCH 2.0 is a general purpose carrier board with capacitive touch interface support. PX30.Core needs to mount on top of this Carrier board for creating complete PX30.Core C.TOUCH 2.0 board. Add support for it. Signed-off-by: Jagan Teki <[email protected]> Signed-off-by: Michael Trimarchi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Heiko Stuebner <[email protected]>
2020-11-08arm64: dts: rockchip: Add Engicam C.TOUCH 2.0Jagan Teki1-0/+8
Engicam C.TOUCH 2.0 is an EDIMM compliant general purpose carrier board with capacitive touch interface. Genaral features: - TFT 10.1" industrial, 1280x800 LVDS display - Ethernet 10/100 - Wifi/BT - USB Type A/OTG - Audio Out - CAN - LVDS panel connector SOM's like PX30.Core needs to mount on top of this Carrier board for creating complete PX30.Core C.TOUCH 2.0 board. Add support for it. Signed-off-by: Jagan Teki <[email protected]> Signed-off-by: Michael Trimarchi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Heiko Stuebner <[email protected]>
2020-11-08arm64: dts: rockchip: Add Engicam PX30.Core EDIMM2.2 Starter KitJagan Teki2-0/+22
PX30.Core is an EDIMM SOM based on Rockchip PX30 from Engicam. EDIMM2.2 Starter Kit is an EDIMM 2.2 Form Factor Capacitive Evaluation Board from Engicam. PX30.Core needs to mount on top of this Evaluation board for creating complete PX30.Core EDIMM2.2 Starter Kit. Add support for it. Signed-off-by: Jagan Teki <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Heiko Stuebner <[email protected]>
2020-11-08arm64: dts: rockchip: Add Engicam PX30.Core SOMMichael Trimarchi1-0/+232
PX30.Core is an EDIMM SOM based on Rockchip PX30 from Engicam. General features: - Rockchip PX30 - Up to 2GB DDR4 - eMMC 4 GB expandible - rest of PX30 features PX30.Core needs to mount on top of Engicam baseboards for creating complete platform boards. Possible baseboards are, - EDIMM2.2 - C.TOUCH 2.0 Add support for it. Signed-off-by: Jagan Teki <[email protected]> Signed-off-by: Michael Trimarchi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Heiko Stuebner <[email protected]>
2020-11-08arm64: dts: rockchip: Add Engicam EDIMM2.2 Starter KitJagan Teki2-0/+46
Engicam EDIMM2.2 Starter Kit is an EDIMM 2.2 Form Factor Capacitive Evaluation Board. Genaral features: - LCD 7" C.Touch - microSD slot - Ethernet 1Gb - Wifi/BT - 2x LVDS Full HD interfaces - 3x USB 2.0 - 1x USB 3.0 - HDMI Out - Mini PCIe - MIPI CSI - 2x CAN - Audio Out SOM's like PX30.Core needs to mount on top of this Evaluation board for creating complete PX30.Core EDIMM2.2 Starter Kit. Add support for it. Signed-off-by: Jagan Teki <[email protected]> Signed-off-by: Michael Trimarchi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Heiko Stuebner <[email protected]>
2020-11-08arm64: dts: exynos: Correct psci compatible used on Exynos7Paweł Chmiel1-1/+3
It's not possible to reboot or poweroff Exynos7420 using PSCI. Instead we need to use syscon reboot/poweroff drivers, like it's done for other Exynos SoCs. This was confirmed by checking vendor source and testing it on Samsung Galaxy S6 device based on this SoC. To be able to use custom restart/poweroff handlers instead of PSCI functions, we need to correct psci compatible. This also requires us to provide function ids for CPU_ON and CPU_OFF. Fixes: fb026cb65247 ("arm64: dts: Add reboot node for exynos7") Fixes: b9024cbc937d ("arm64: dts: Add initial device tree support for exynos7") Signed-off-by: Paweł Chmiel <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Krzysztof Kozlowski <[email protected]>
2020-11-08arm64: dts: exynos: Include common syscon restart/poweroff for Exynos7Paweł Chmiel1-7/+1
Exynos7 uses the same syscon reboot and poweroff nodes as other Exynos SoCs, so instead of duplicating code we can just include common dtsi file, which already contains definitions of them. After this change, poweroff node will be also available, previously this dts file did contain only reboot node. Fixes: fb026cb65247 ("arm64: dts: Add reboot node for exynos7") Fixes: b9024cbc937d ("arm64: dts: Add initial device tree support for exynos7") Signed-off-by: Paweł Chmiel <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Krzysztof Kozlowski <[email protected]>
2020-11-08Merge tag 'kvmarm-fixes-5.10-2' of ↵Paolo Bonzini3-83/+43
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD KVM/arm64 fixes for v5.10, take #2 - Fix compilation error when PMD and PUD are folded - Fix regresssion of the RAZ behaviour of ID_AA64ZFR0_EL1
2020-11-08arm64: dts: rockchip: Reorder LED triggers from mmc devices on rk3399-roc-pc.Markus Reichl1-2/+2
After patch [1] SD-card becomes mmc1 and eMMC becomes mmc2. Correct trigger of LEDs accordingly. [1] https://patchwork.kernel.org/patch/11881427 Signed-off-by: Markus Reichl <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Heiko Stuebner <[email protected]>
2020-11-08arm64: dts: rockchip: add adc joystick to Odroid Go AdvanceHeiko Stuebner1-0/+24
Add the now usable adc-joystick node that describes the analog joystick connected to two saradc channels from the rk3326 soc. Signed-off-by: Heiko Stuebner <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-11-08arm64: dts: rockchip: Assign a fixed index to mmc devices on rk3399 boards.Markus Reichl1-0/+3
Recently introduced async probe on mmc devices can shuffle block IDs. Pin them to fixed values to ease booting in environments where UUIDs are not practical. Use newly introduced aliases for mmcblk devices from [1]. [1] https://patchwork.kernel.org/patch/11747669/ Signed-off-by: Markus Reichl <[email protected]> Reviewed-by: Douglas Anderson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Heiko Stuebner <[email protected]>
2020-11-06Merge tag 'arm64-fixes' of ↵Linus Torvalds7-59/+67
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 fixes from Will Deacon: "Here's the weekly batch of fixes for arm64. Not an awful lot here, but there are still a few unresolved issues relating to CPU hotplug, RCU and IRQ tracing that I hope to queue fixes for next week. Summary: - Fix early use of kprobes - Fix kernel placement in kexec_file_load() - Bump maximum number of NUMA nodes" * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: arm64: kexec_file: try more regions if loading segments fails arm64: kprobes: Use BRK instead of single-step when executing instructions out-of-line arm64: NUMA: Kconfig: Increase NODES_SHIFT to 4
2020-11-06KVM: arm64: Fix build error in user_mem_abort()Gavin Shan1-0/+2
The PUD and PMD are folded into PGD when the following options are enabled. In that case, PUD_SHIFT is equal to PMD_SHIFT and we fail to build with the indicated errors: CONFIG_ARM64_VA_BITS_42=y CONFIG_ARM64_PAGE_SHIFT=16 CONFIG_PGTABLE_LEVELS=3 arch/arm64/kvm/mmu.c: In function ‘user_mem_abort’: arch/arm64/kvm/mmu.c:798:2: error: duplicate case value case PMD_SHIFT: ^~~~ arch/arm64/kvm/mmu.c:791:2: note: previously used here case PUD_SHIFT: ^~~~ This fixes the issue by skipping the check on PUD huge page when PUD and PMD are folded into PGD. Fixes: 2f40c46021bbb ("KVM: arm64: Use fallback mapping sizes for contiguous huge page sizes") Reported-by: Eric Auger <[email protected]> Signed-off-by: Gavin Shan <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-11-06KVM: arm64: Remove AA64ZFR0_EL1 accessorsAndrew Jones1-50/+11
The AA64ZFR0_EL1 accessors are just the general accessors with its visibility function open-coded. It also skips the if-else chain in read_id_reg, but there's no reason not to go there. Indeed consolidating ID register accessors and removing lines of code make it worthwhile. Remove the AA64ZFR0_EL1 accessors, replacing them with the general accessors for sanitized ID registers. No functional change intended. Signed-off-by: Andrew Jones <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-11-06KVM: arm64: Check RAZ visibility in ID register accessorsAndrew Jones2-3/+26
The instruction encodings of ID registers are preallocated. Until an encoding is assigned a purpose the register is RAZ. KVM's general ID register accessor functions already support both paths, RAZ or not. If for each ID register we can determine if it's RAZ or not, then all ID registers can build on the general functions. The register visibility function allows us to check whether a register should be completely hidden or not, extending it to also report when the register should be RAZ or not allows us to use it for ID registers as well. Check for RAZ visibility in the ID register accessor functions, allowing the RAZ case to be handled in a generic way for all system registers. The new REG_RAZ flag will be used in a later patch. This patch has no intended functional change. Signed-off-by: Andrew Jones <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.