summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2021-08-20KVM: arm64: Add feature register flag definitionsFuad Tabba3-10/+14
Add feature register flag definitions to clarify which features might be supported. Consolidate the various ID_AA64PFR0_ELx flags for all ELs. No functional change intended. Signed-off-by: Fuad Tabba <tabba@google.com> Acked-by: Will Deacon <will@kernel.org> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210817081134.2918285-10-tabba@google.com
2021-08-20KVM: arm64: Track value of cptr_el2 in struct kvm_vcpu_archFuad Tabba3-1/+3
Track the baseline guest value for cptr_el2 in struct kvm_vcpu_arch, similar to the other registers that control traps. Use this value when setting cptr_el2 for the guest. Currently this value is unchanged (CPTR_EL2_DEFAULT), but future patches will set trapping bits based on features supported for the guest. No functional change intended. Acked-by: Will Deacon <will@kernel.org> Signed-off-by: Fuad Tabba <tabba@google.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210817081134.2918285-9-tabba@google.com
2021-08-20KVM: arm64: Keep mdcr_el2's value as set by __init_el2_debugFuad Tabba2-8/+0
__init_el2_debug configures mdcr_el2 at initialization based on, among other things, available hardware support. Trap deactivation doesn't check that, so keep the initial value. No functional change intended. Signed-off-by: Fuad Tabba <tabba@google.com> Acked-by: Will Deacon <will@kernel.org> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210817081134.2918285-8-tabba@google.com
2021-08-20KVM: arm64: Restore mdcr_el2 from vcpuFuad Tabba6-21/+21
On deactivating traps, restore the value of mdcr_el2 from the newly created and preserved host value vcpu context, rather than directly reading the hardware register. Up until and including this patch the two values are the same, i.e., the hardware register and the vcpu one. A future patch will be changing the value of mdcr_el2 on activating traps, and this ensures that its value will be restored. No functional change intended. Signed-off-by: Fuad Tabba <tabba@google.com> Acked-by: Will Deacon <will@kernel.org> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210817081134.2918285-7-tabba@google.com
2021-08-20KVM: arm64: Refactor sys_regs.h,c for nVHE reuseFuad Tabba3-44/+52
Refactor sys_regs.h and sys_regs.c to make it easier to reuse common code. It will be used in nVHE in a later patch. Note that the refactored code uses __inline_bsearch for find_reg instead of bsearch to avoid copying the bsearch code for nVHE. No functional change intended. Acked-by: Will Deacon <will@kernel.org> Signed-off-by: Fuad Tabba <tabba@google.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210817081134.2918285-6-tabba@google.com
2021-08-20KVM: arm64: Fix names of config register fieldsFuad Tabba1-6/+6
Change the names of hcr_el2 register fields to match the Arm Architecture Reference Manual. Easier for cross-referencing and for grepping. Also, change the name of CPTR_EL2_RES1 to CPTR_NVHE_EL2_RES1, because res1 bits are different for VHE. No functional change intended. Acked-by: Will Deacon <will@kernel.org> Signed-off-by: Fuad Tabba <tabba@google.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210817081134.2918285-5-tabba@google.com
2021-08-20KVM: arm64: MDCR_EL2 is a 64-bit registerFuad Tabba6-15/+15
Fix the places in KVM that treat MDCR_EL2 as a 32-bit register. More recent features (e.g., FEAT_SPEv1p2) use bits above 31. No functional change intended. Acked-by: Will Deacon <will@kernel.org> Signed-off-by: Fuad Tabba <tabba@google.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210817081134.2918285-4-tabba@google.com
2021-08-20KVM: arm64: Remove trailing whitespace in commentFuad Tabba1-2/+2
Remove trailing whitespace from comment in trap_dbgauthstatus_el1(). No functional change intended. Acked-by: Will Deacon <will@kernel.org> Signed-off-by: Fuad Tabba <tabba@google.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210817081134.2918285-3-tabba@google.com
2021-08-20KVM: arm64: placeholder to check if VM is protectedFuad Tabba1-0/+5
Add a function to check whether a VM is protected (under pKVM). Since the creation of protected VMs isn't enabled yet, this is a placeholder that always returns false. The intention is for this to become a check for protected VMs in the future (see Will's RFC). No functional change intended. Acked-by: Will Deacon <will@kernel.org> Signed-off-by: Fuad Tabba <tabba@google.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/kvmarm/20210603183347.1695-1-will@kernel.org/ Link: https://lore.kernel.org/r/20210817081134.2918285-2-tabba@google.com
2021-08-20KVM: arm64: Upgrade VMID accesses to {READ,WRITE}_ONCEMarc Zyngier4-5/+10
Since TLB invalidation can run in parallel with VMID allocation, we need to be careful and avoid any sort of load/store tearing. Use {READ,WRITE}_ONCE consistently to avoid any surprise. Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Jade Alglave <jade.alglave@arm.com> Cc: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Will Deacon <will@kernel.org> Reviewed-by: Quentin Perret <qperret@google.com> Link: https://lore.kernel.org/r/20210806113109.2475-6-will@kernel.org
2021-08-20KVM: arm64: Unify stage-2 programming behind __load_stage2()Marc Zyngier7-18/+13
The protected mode relies on a separate helper to load the S2 context. Move over to the __load_guest_stage2() helper instead, and rename it to __load_stage2() to present a unified interface. Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Jade Alglave <jade.alglave@arm.com> Cc: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/20210806113109.2475-5-will@kernel.org
2021-08-20KVM: arm64: Move kern_hyp_va() usage in __load_guest_stage2() into the callersMarc Zyngier5-6/+9
It is a bit awkward to use kern_hyp_va() in __load_guest_stage2(), specially as the helper is shared between VHE and nVHE. Instead, move the use of kern_hyp_va() in the nVHE code, and pass a pointer to the kvm->arch structure instead. Although this may look a bit awkward, it allows for some further simplification. Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Jade Alglave <jade.alglave@arm.com> Cc: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/20210806113109.2475-4-will@kernel.org
2021-08-20KVM: arm64: vgic: Resample HW pending state on deactivationMarc Zyngier4-62/+50
When a mapped level interrupt (a timer, for example) is deactivated by the guest, the corresponding host interrupt is equally deactivated. However, the fate of the pending state still needs to be dealt with in SW. This is specially true when the interrupt was in the active+pending state in the virtual distributor at the point where the guest was entered. On exit, the pending state is potentially stale (the guest may have put the interrupt in a non-pending state). If we don't do anything, the interrupt will be spuriously injected in the guest. Although this shouldn't have any ill effect (spurious interrupts are always possible), we can improve the emulation by detecting the deactivation-while-pending case and resample the interrupt. While we're at it, move the logic into a common helper that can be shared between the two GIC implementations. Fixes: e40cc57bac79 ("KVM: arm/arm64: vgic: Support level-triggered mapped interrupts") Reported-by: Raghavendra Rao Ananta <rananta@google.com> Tested-by: Raghavendra Rao Ananta <rananta@google.com> Reviewed-by: Oliver Upton <oupton@google.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210819180305.1670525-1-maz@kernel.org
2021-08-20powerpc/perf/hv-gpci: Fix counter value parsingKajol Jain1-1/+1
H_GetPerformanceCounterInfo (0xF080) hcall returns the counter data in the result buffer. Result buffer has specific format defined in the PAPR specification. One of the fields is counter offset and width of the counter data returned. Counter data are returned in a unsigned char array in big endian byte order. To get the final counter data, the values must be left shifted byte at a time. But commit 220a0c609ad17 ("powerpc/perf: Add support for the hv gpci (get performance counter info) interface") made the shifting bitwise and also assumed little endian order. Because of that, hcall counters values are reported incorrectly. In particular this can lead to counters go backwards which messes up the counter prev vs now calculation and leads to huge counter value reporting: #: perf stat -e hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/ -C 0 -I 1000 time counts unit events 1.000078854 18,446,744,073,709,535,232 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/ 2.000213293 0 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/ 3.000320107 0 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/ 4.000428392 0 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/ 5.000537864 0 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/ 6.000649087 0 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/ 7.000760312 0 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/ 8.000865218 16,448 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/ 9.000978985 18,446,744,073,709,535,232 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/ 10.001088891 16,384 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/ 11.001201435 0 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/ 12.001307937 18,446,744,073,709,535,232 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/ Fix the shifting logic to correct match the format, ie. read bytes in big endian order. Fixes: e4f226b1580b ("powerpc/perf/hv-gpci: Increase request buffer size") Cc: stable@vger.kernel.org # v4.6+ Reported-by: Nageswara R Sastry<rnsastry@linux.ibm.com> Signed-off-by: Kajol Jain <kjain@linux.ibm.com> Tested-by: Nageswara R Sastry<rnsastry@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20210813082158.429023-1-kjain@linux.ibm.com
2021-08-20powerpc/tau: Add 'static' storage qualifier to 'tau_work' definitionFinn Thain1-1/+1
This patch prevents the following sparse warning. arch/powerpc/kernel/tau_6xx.c:199:1: sparse: sparse: symbol 'tau_work' was not declared. Should it be static? Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Finn Thain <fthain@linux-m68k.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/44ab381741916a51e783c4a50d0b186abdd8f280.1629334014.git.fthain@linux-m68k.org
2021-08-20powerpc: Re-enable ARCH_ENABLE_SPLIT_PMD_PTLOCKLukas Bulwahn1-1/+1
Commit 66f24fa766e3 ("mm: drop redundant ARCH_ENABLE_SPLIT_PMD_PTLOCK") broke PMD split page table lock for powerpc. It selects the non-existent config ARCH_ENABLE_PMD_SPLIT_PTLOCK in arch/powerpc/platforms/Kconfig.cputype, but clearly intended to select ARCH_ENABLE_SPLIT_PMD_PTLOCK (notice the word swapping!), as that commit did for all other architectures. Fix it by selecting the correct symbol ARCH_ENABLE_SPLIT_PMD_PTLOCK. Fixes: 66f24fa766e3 ("mm: drop redundant ARCH_ENABLE_SPLIT_PMD_PTLOCK") Cc: stable@vger.kernel.org # v5.13+ Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Reviewed-by: Daniel Axtens <dja@axtens.net> [mpe: Reword change log to make it clear this is a bug fix] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20210819113954.17515-3-lukas.bulwahn@gmail.com
2021-08-20powerpc/kvm: Remove obsolete and unneeded selectLukas Bulwahn1-1/+0
Commit a278e7ea608b ("powerpc: Fix compile issue with force DAWR") selects the non-existing config PPC_DAWR_FORCE_ENABLE for config KVM_BOOK3S_64_HANDLER. As this commit also introduces a config PPC_DAWR and this config PPC_DAWR is selected with PPC if PPC64, there is no need for any further select in the KVM_BOOK3S_64_HANDLER. Remove an obsolete and unneeded select in config KVM_BOOK3S_64_HANDLER. The issue was identified with ./scripts/checkkconfigsymbols.py. Fixes: a278e7ea608b ("powerpc: Fix compile issue with force DAWR") Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Reviewed-by: Daniel Axtens <dja@axtens.net> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20210819113954.17515-2-lukas.bulwahn@gmail.com
2021-08-20Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski32-149/+242
drivers/ptp/Kconfig: 55c8fca1dae1 ("ptp_pch: Restore dependency on PCI") e5f31552674e ("ethernet: fix PTP_1588_CLOCK dependencies") Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-08-20Merge tag 'soc-fixes-5.14-3' of ↵Linus Torvalds7-34/+48
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull ARM SoC fixes from Arnd Bergmann: "Not much to see here. Half the fixes this time are for Qualcomm dts files, fixing small mistakes on certain machines. The other fixes are: - A 5.13 regression fix for freescale QE interrupt controller\ - A fix for TI OMAP gpt12 timer error handling - A randconfig build regression fix for ixp4xx - Another defconfig fix following the CONFIG_FB dependency rework" * tag 'soc-fixes-5.14-3' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: soc: fsl: qe: fix static checker warning ARM: ixp4xx: fix building both pci drivers ARM: configs: Update the nhk8815_defconfig bus: ti-sysc: Fix error handling for sysc_check_active_timer() soc: fsl: qe: convert QE interrupt controller to platform_device arm64: dts: qcom: sdm845-oneplus: fix reserved-mem arm64: dts: qcom: msm8994-angler: Disable cont_splash_mem arm64: dts: qcom: sc7280: Fixup cpufreq domain info for cpu7 arm64: dts: qcom: msm8992-bullhead: Fix cont_splash_mem mapping arm64: dts: qcom: msm8992-bullhead: Remove PSCI arm64: dts: qcom: c630: fix correct powerdown pin for WSA881x
2021-08-20ARM: s3c: delete unneed local variable "delay"Jason Wang1-2/+1
"delay" variable on line 79 can be deleted by returning "0" on line 88. Signed-off-by: Jason Wang <wangborong@cdjrlc.com> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Link: https://lore.kernel.org/r/20210624055627.22295-1-wangborong@cdjrlc.com Link: https://lore.kernel.org/r/20210818204422.17919-1-krzysztof.kozlowski@canonical.com' Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2021-08-19KVM: arm64: vgic: Drop WARN from vgic_get_irqRicardo Koller1-1/+0
vgic_get_irq(intid) is used all over the vgic code in order to get a reference to a struct irq. It warns whenever intid is not a valid number (like when it's a reserved IRQ number). The issue is that this warning can be triggered from userspace (e.g., KVM_IRQ_LINE for intid 1020). Drop the WARN call from vgic_get_irq. Signed-off-by: Ricardo Koller <ricarkol@google.com> Reviewed-by: Oliver Upton <oupton@google.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210818213205.598471-1-ricarkol@google.com
2021-08-19KVM: arm64: Use generic KVM xfer to guest work functionOliver Upton2-28/+45
Clean up handling of checks for pending work by switching to the generic infrastructure to do so. We pick up handling for TIF_NOTIFY_RESUME from this switch, meaning that task work will be correctly handled. Signed-off-by: Oliver Upton <oupton@google.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210802192809.1851010-4-oupton@google.com
2021-08-19KVM: arm64: Record number of signal exits as a vCPU statOliver Upton3-0/+3
Most other architectures that implement KVM record a statistic indicating the number of times a vCPU has exited due to a pending signal. Add support for that stat to arm64. Reviewed-by: Jing Zhang <jingzhangos@google.com> Signed-off-by: Oliver Upton <oupton@google.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210802192809.1851010-2-oupton@google.com
2021-08-19arm64: initialize all of CNTHCTL_EL2Mark Rutland1-2/+1
In __init_el2_timers we initialize CNTHCTL_EL2.{EL1PCEN,EL1PCTEN} with a RMW sequence, leaving all other bits UNKNOWN. In general, we should initialize all bits in a register rather than using an RMW sequence, since most bits are UNKNOWN out of reset, and as new bits are added to the reigster their reset value might not result in expected behaviour. In the case of CNTHCTL_EL2, FEAT_ECV added a number of new control bits in previously RES0 bits, which reset to UNKNOWN values, and may cause issues for EL1 and EL0: * CNTHCTL_EL2.ECV enables the CNTPOFF_EL2 offset (which itself resets to an UNKNOWN value) at EL0 and EL1. Since the offset could reset to distinct values across CPUs, when the control bit resets to 1 this could break timekeeping generally. * CNTHCTL_EL2.{EL1TVT,EL1TVCT} trap EL0 and EL1 accesses to the EL1 virtual timer/counter registers to EL2. When reset to 1, this could cause unexpected traps to EL2. Initializing these bits to zero avoids these problems, and all other bits in CNTHCTL_EL2 other than EL1PCEN and EL1PCTEN can safely be reset to zero. This patch ensures we initialize CNTHCTL_EL2 accordingly, only setting EL1PCEN and EL1PCTEN, and setting all other bits to zero. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Marc Zyngier <maz@kernel.org> Cc: Oliver Upton <oupton@google.com> Cc: Will Deacon <will@kernel.org> Reviewed-by: Oliver Upton <oupton@google.com> Acked-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210818161535.52786-1-mark.rutland@arm.com Signed-off-by: Will Deacon <will@kernel.org>
2021-08-19KVM: arm64: Enforce reserved bits for PSCI target affinitiesOliver Upton1-3/+12
According to the PSCI specification, ARM DEN 0022D, 5.1.4 "CPU_ON", the CPU_ON function takes a target_cpu argument that is bit-compatible with the affinity fields in MPIDR_EL1. All other bits in the argument are RES0. Note that the same constraints apply to the target_affinity argument for the AFFINITY_INFO call. Enforce the spec by returning INVALID_PARAMS if a guest incorrectly sets a RES0 bit. Signed-off-by: Oliver Upton <oupton@google.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210818202133.1106786-4-oupton@google.com
2021-08-19KVM: arm64: Handle PSCI resets before userspace touches vCPU stateOliver Upton1-0/+8
The CPU_ON PSCI call takes a payload that KVM uses to configure a destination vCPU to run. This payload is non-architectural state and not exposed through any existing UAPI. Effectively, we have a race between CPU_ON and userspace saving/restoring a guest: if the target vCPU isn't ran again before the VMM saves its state, the requested PC and context ID are lost. When restored, the target vCPU will be runnable and start executing at its old PC. We can avoid this race by making sure the reset payload is serviced before userspace can access a vCPU's state. Fixes: 358b28f09f0a ("arm/arm64: KVM: Allow a VCPU to fully reset itself") Signed-off-by: Oliver Upton <oupton@google.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210818202133.1106786-3-oupton@google.com
2021-08-19KVM: arm64: Fix read-side race on updates to vcpu reset stateOliver Upton1-6/+10
KVM correctly serializes writes to a vCPU's reset state, however since we do not take the KVM lock on the read side it is entirely possible to read state from two different reset requests. Cure the race for now by taking the KVM lock when reading the reset_state structure. Fixes: 358b28f09f0a ("arm/arm64: KVM: Allow a VCPU to fully reset itself") Signed-off-by: Oliver Upton <oupton@google.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210818202133.1106786-2-oupton@google.com
2021-08-19ARM: config: aspeed: Regenerate defconfigsJoel Stanley2-24/+8
A make defconfig && make savedefconfig was performed for each configuration. Most changes are due to options moving around, except for the following which are due to changing defaults: - SECCOMP is enabled by default as of commit 282a181b1a0d ("seccomp: Move config option SECCOMP to arch/Kconfig") in v5.9 - The soc drivers ASPEED_LPC_CTRL, ASPEED_LPC_SNOOP and ASPEED_P2A_CTRL are enabled by default when the aspeed platform is enabled, as of commit 592693a1f881 ("soc: aspeed: Improve kconfig") in v5.9 - The ZBOOT_ROM_TEXT/BSS values fall out of the defconfig as of commit 39c3e304567a ("ARM: 8984/1: Kconfig: set default ZBOOT_ROM_TEXT/BSS value to 0x0") in v5.8 - I2C_MUX is selected by MEDIA_SUBDRV_AUTOSELECT, probably as of about v5.8. It was in the config as it is required bt the PCA I2C muxes that enabled it Signed-off-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/20210819065203.2620911-5-joel@jms.id.au Signed-off-by: Joel Stanley <joel@jms.id.au>
2021-08-19hexagon: use the generic global coherent poolChristoph Hellwig2-46/+12
Switch hexagon to use the generic code for dma_alloc_coherent from a global pre-filled pool. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Brian Cain <bcain@codeaurora.org>
2021-08-19ARM: config: aspeed_g4: Enable EDAC and SPGIOJoel Stanley1-0/+2
These two devices are part of the AST2400 and the drivers have support for that version of the soc. Signed-off-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/20210819065203.2620911-4-joel@jms.id.au Signed-off-by: Joel Stanley <joel@jms.id.au>
2021-08-19ARM: config: aspeed: Enable KCS adapter for raw SerIOJoel Stanley1-1/+2
Raw SerIO is used by the OpenBMC debug-trigger application to take signals from the host that applications are unresponsive on the BMC. Signed-off-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/20210819065203.2620911-3-joel@jms.id.au Signed-off-by: Joel Stanley <joel@jms.id.au>
2021-08-19ARM: config: aspeed: Enable hardened allocator featureJoel Stanley2-2/+2
SLAB_FREELIST_HARDENED can protect from freelist overwrite attacks with really small overhead. It works best with the SLUB allocator, so make SLUB the default by removing SLAB=y. total used free shared buff/cache available SLAB 425596 44065.3+/-220 311099+/-3800 14864+/-3900 70432+/-3700 352767+/-3900 SLUB 425592 44225.3+/-280 313275+/-600 12132+/-3.3 68092+/-530 355295+/-280 These figures are the average memory usage from three boots of each option in qemu, running the Romulus userspace. The output is from free(1), reported in kilobytes. Signed-off-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/20210819065203.2620911-2-joel@jms.id.au Signed-off-by: Joel Stanley <joel@jms.id.au>
2021-08-19isystem: ship and use stdarg.hAlexey Dobriyan6-6/+6
Ship minimal stdarg.h (1 type, 4 macros) as <linux/stdarg.h>. stdarg.h is the only userspace header commonly used in the kernel. GPL 2 version of <stdarg.h> can be extracted from http://archive.debian.org/debian/pool/main/g/gcc-4.2/gcc-4.2_4.2.4.orig.tar.gz Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2021-08-19isystem: trim/fixup stdarg.h and other headersAlexey Dobriyan14-22/+4
Delete/fixup few includes in anticipation of global -isystem compile option removal. Note: crypto/aegis128-neon-inner.c keeps <stddef.h> due to redefinition of uintptr_t error (one definition comes from <stddef.h>, another from <linux/types.h>). Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2021-08-19powerpc/mm: Fix set_memory_*() against concurrent accessesMichael Ellerman1-13/+10
Laurent reported that STRICT_MODULE_RWX was causing intermittent crashes on one of his systems: kernel tried to execute exec-protected page (c008000004073278) - exploit attempt? (uid: 0) BUG: Unable to handle kernel instruction fetch Faulting instruction address: 0xc008000004073278 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries Modules linked in: drm virtio_console fuse drm_panel_orientation_quirks ... CPU: 3 PID: 44 Comm: kworker/3:1 Not tainted 5.14.0-rc4+ #12 Workqueue: events control_work_handler [virtio_console] NIP: c008000004073278 LR: c008000004073278 CTR: c0000000001e9de0 REGS: c00000002e4ef7e0 TRAP: 0400 Not tainted (5.14.0-rc4+) MSR: 800000004280b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 24002822 XER: 200400cf ... NIP fill_queue+0xf0/0x210 [virtio_console] LR fill_queue+0xf0/0x210 [virtio_console] Call Trace: fill_queue+0xb4/0x210 [virtio_console] (unreliable) add_port+0x1a8/0x470 [virtio_console] control_work_handler+0xbc/0x1e8 [virtio_console] process_one_work+0x290/0x590 worker_thread+0x88/0x620 kthread+0x194/0x1a0 ret_from_kernel_thread+0x5c/0x64 Jordan, Fabiano & Murilo were able to reproduce and identify that the problem is caused by the call to module_enable_ro() in do_init_module(), which happens after the module's init function has already been called. Our current implementation of change_page_attr() is not safe against concurrent accesses, because it invalidates the PTE before flushing the TLB and then installing the new PTE. That leaves a window in time where there is no valid PTE for the page, if another CPU tries to access the page at that time we see something like the fault above. We can't simply switch to set_pte_at()/flush TLB, because our hash MMU code doesn't handle a set_pte_at() of a valid PTE. See [1]. But we do have pte_update(), which replaces the old PTE with the new, meaning there's no window where the PTE is invalid. And the hash MMU version hash__pte_update() deals with synchronising the hash page table correctly. [1]: https://lore.kernel.org/linuxppc-dev/87y318wp9r.fsf@linux.ibm.com/ Fixes: 1f9ad21c3b38 ("powerpc/mm: Implement set_memory() routines") Reported-by: Laurent Vivier <lvivier@redhat.com> Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu> Reviewed-by: Murilo Opsfelder Araújo <muriloo@linux.ibm.com> Tested-by: Laurent Vivier <lvivier@redhat.com> Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20210818120518.3603172-1-mpe@ellerman.id.au
2021-08-19powerpc/32s: Fix random crashes by adding isync() after locking/unlocking KUEPChristophe Leroy1-0/+20
Commit b5efec00b671 ("powerpc/32s: Move KUEP locking/unlocking in C") removed the 'isync' instruction after adding/removing NX bit in user segments. The reasoning behind this change was that when setting the NX bit we don't mind it taking effect with delay as the kernel never executes text from userspace, and when clearing the NX bit this is to return to userspace and then the 'rfi' should synchronise the context. However, it looks like on book3s/32 having a hash page table, at least on the G3 processor, we get an unexpected fault from userspace, then this is followed by something wrong in the verification of MSR_PR at end of another interrupt. This is fixed by adding back the removed isync() following update of NX bit in user segment registers. Only do it for cores with an hash table, as 603 cores don't exhibit that problem and the two isync increase ./null_syscall selftest by 6 cycles on an MPC 832x. First problem: unexpected WARN_ON() for mysterious PROTFAULT WARNING: CPU: 0 PID: 1660 at arch/powerpc/mm/fault.c:354 do_page_fault+0x6c/0x5b0 Modules linked in: CPU: 0 PID: 1660 Comm: Xorg Not tainted 5.13.0-pmac-00028-gb3c15b60339a #40 NIP: c001b5c8 LR: c001b6f8 CTR: 00000000 REGS: e2d09e40 TRAP: 0700 Not tainted (5.13.0-pmac-00028-gb3c15b60339a) MSR: 00021032 <ME,IR,DR,RI> CR: 42d04f30 XER: 20000000 GPR00: c000424c e2d09f00 c301b680 e2d09f40 0000001e 42000000 00cba028 00000000 GPR08: 08000000 48000010 c301b680 e2d09f30 22d09f30 00c1fff0 00cba000 a7b7ba4c GPR16: 00000031 00000000 00000000 00000000 00000000 00000000 a7b7b0d0 00c5c010 GPR24: a7b7b64c a7b7d2f0 00000004 00000000 c1efa6c0 00cba02c 00000300 e2d09f40 NIP [c001b5c8] do_page_fault+0x6c/0x5b0 LR [c001b6f8] do_page_fault+0x19c/0x5b0 Call Trace: [e2d09f00] [e2d09f04] 0xe2d09f04 (unreliable) [e2d09f30] [c000424c] DataAccess_virt+0xd4/0xe4 --- interrupt: 300 at 0xa7a261dc NIP: a7a261dc LR: a7a253bc CTR: 00000000 REGS: e2d09f40 TRAP: 0300 Not tainted (5.13.0-pmac-00028-gb3c15b60339a) MSR: 0000d032 <EE,PR,ME,IR,DR,RI> CR: 228428e2 XER: 20000000 DAR: 00cba02c DSISR: 42000000 GPR00: a7a27448 afa6b0e0 a74c35c0 a7b7b614 0000001e a7b7b614 00cba028 00000000 GPR08: 00020fd9 00000031 00cb9ff8 a7a273b0 220028e2 00c1fff0 00cba000 a7b7ba4c GPR16: 00000031 00000000 00000000 00000000 00000000 00000000 a7b7b0d0 00c5c010 GPR24: a7b7b64c a7b7d2f0 00000004 00000002 0000001e a7b7b614 a7b7aff4 00000030 NIP [a7a261dc] 0xa7a261dc LR [a7a253bc] 0xa7a253bc --- interrupt: 300 Instruction dump: 7c4a1378 810300a0 75278410 83820298 83a300a4 553b018c 551e0036 4082038c 2e1b0000 40920228 75280800 41820220 <0fe00000> 3b600000 41920214 81420594 Second problem: MSR PR is seen unset allthough the interrupt frame shows it set kernel BUG at arch/powerpc/kernel/interrupt.c:458! Oops: Exception in kernel mode, sig: 5 [#1] BE PAGE_SIZE=4K MMU=Hash SMP NR_CPUS=2 PowerMac Modules linked in: CPU: 0 PID: 1660 Comm: Xorg Tainted: G W 5.13.0-pmac-00028-gb3c15b60339a #40 NIP: c0011434 LR: c001629c CTR: 00000000 REGS: e2d09e70 TRAP: 0700 Tainted: G W (5.13.0-pmac-00028-gb3c15b60339a) MSR: 00029032 <EE,ME,IR,DR,RI> CR: 42d09f30 XER: 00000000 GPR00: 00000000 e2d09f30 c301b680 e2d09f40 83440000 c44d0e68 e2d09e8c 00000000 GPR08: 00000002 00dc228a 00004000 e2d09f30 22d09f30 00c1fff0 afa6ceb4 00c26144 GPR16: 00c25fb8 00c26140 afa6ceb8 90000000 00c944d8 0000001c 00000000 00200000 GPR24: 00000000 000001fb afa6d1b4 00000001 00000000 a539a2a0 a530fd80 00000089 NIP [c0011434] interrupt_exit_kernel_prepare+0x10/0x70 LR [c001629c] interrupt_return+0x9c/0x144 Call Trace: [e2d09f30] [c000424c] DataAccess_virt+0xd4/0xe4 (unreliable) --- interrupt: 300 at 0xa09be008 NIP: a09be008 LR: a09bdfe8 CTR: a09bdfc0 REGS: e2d09f40 TRAP: 0300 Tainted: G W (5.13.0-pmac-00028-gb3c15b60339a) MSR: 0000d032 <EE,PR,ME,IR,DR,RI> CR: 420028e2 XER: 20000000 DAR: a539a308 DSISR: 0a000000 GPR00: a7b90d50 afa6b2d0 a74c35c0 a0a8b690 a0a8b698 a5365d70 a4fa82a8 00000004 GPR08: 00000000 a09bdfc0 00000000 a5360000 a09bde7c 00c1fff0 afa6ceb4 00c26144 GPR16: 00c25fb8 00c26140 afa6ceb8 90000000 00c944d8 0000001c 00000000 00200000 GPR24: 00000000 000001fb afa6d1b4 00000001 00000000 a539a2a0 a530fd80 00000089 NIP [a09be008] 0xa09be008 LR [a09bdfe8] 0xa09bdfe8 --- interrupt: 300 Instruction dump: 80010024 83e1001c 7c0803a6 4bffff80 3bc00800 4bffffd0 486b42fd 4bffffcc 81430084 71480002 41820038 554a0462 <0f0a0000> 80620060 74630001 40820034 Fixes: b5efec00b671 ("powerpc/32s: Move KUEP locking/unlocking in C") Cc: stable@vger.kernel.org # v5.13+ Reported-by: Stan Johnson <userm57@yahoo.com> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/4856f5574906e2aec0522be17bf3848a22b2cd0b.1629269345.git.christophe.leroy@csgroup.eu
2021-08-19ARM: dts: rockchip: Add SFC to RV1108Chris Morgan1-0/+37
Add a devicetree entry for the Rockchip SFC for the RV1108 SOC. Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Signed-off-by: Jon Lin <jon.lin@rock-chips.com> Link: https://lore.kernel.org/r/20210812134546.31340-5-jon.lin@rock-chips.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2021-08-18ARM/nommu: use the generic dma-direct code for non-coherent devicesChristoph Hellwig2-169/+9
Select the right options to just use the generic dma-direct code instead of reimplementing it. Signed-off-by: Christoph Hellwig <hch@lst.de> Tested-by: Dillon Min <dillon.minfei@gmail.com>
2021-08-18ARM: tegra: paz00: Handle device properties with software node APIHeikki Krogerus1-1/+1
The old device property API is going to be removed. Replacing the device_add_properties() call with the software node API equivalent, device_create_managed_software_node(). Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20210817102449.39994-2-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-18powerpc/xive: Do not mark xive_request_ipi() as __initNathan Chancellor1-1/+1
Compiling ppc64le_defconfig with clang-14 shows a modpost warning: WARNING: modpost: vmlinux.o(.text+0xa74e0): Section mismatch in reference from the function xive_setup_cpu_ipi() to the function .init.text:xive_request_ipi() The function xive_setup_cpu_ipi() references the function __init xive_request_ipi(). This is often because xive_setup_cpu_ipi lacks a __init annotation or the annotation of xive_request_ipi is wrong. xive_request_ipi() is called from xive_setup_cpu_ipi(), which is not __init, so xive_request_ipi() should not be marked __init. Remove the attribute so there is no more warning. Fixes: cbc06f051c52 ("powerpc/xive: Do not skip CPU-less nodes when creating the IPIs") Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20210816185711.21563-1-nathan@kernel.org
2021-08-18powerpc/32: Remove unneccessary calculations in load_up_{fpu/altivec}Christophe Leroy2-5/+2
No need to re-read SPRN_THREAD, we can calculate thread address from current (r2). And remove a reload of value 1 into r4 as r4 is already 1. Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/c04cce578b97a76a9e69a096698b1d89f721768a.1629276437.git.christophe.leroy@csgroup.eu
2021-08-18Merge tag 'ixp4xx-del-boardfiles-v5.15' of ↵Arnd Bergmann25-3888/+0
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik into arm/soc This deletes the following IXP4xx boardfiles: - NSLU2 - NAS100D - D-Link DSM-G600 - Omicron - Gateway WG302v2 - Arcom Vulcan - Avila - Intel reference designs - Coyote and IXDPG425 - GTW5715 - Freecom FSG-3 In each case except Omicron, the board has been replaced by a corresponding device tree and tested where someone volunteered: Marc Zyngier has tested Arcom Vulcan and Freecom FSG-3 and I have tested NSLU2 and Avila for example. All that were tested boot to prompt, some devices may need some more massage before working perfectly. We can just as well delete these board files because we are confident that we will fix them to a working state if people are able to test patches. I am holding back the following boards for now: - Gateway 7001 - because Zoltan is working on this board and needs more time. He might need to test things with the board file so let's allow him time for that. - Goramo MLR - the consensus is to replace this with a dry coded device tree, but the bindings for that tree need some more time to make so we keep the boardfile around until we can merge a complete device tree for it. After these two (target v5.16) we can delete the remaining board files and the old mach structure along with the old PCI driver. * tag 'ixp4xx-del-boardfiles-v5.15' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik: ARM: ixp4xx: Delete the Freecom FSG-3 boardfiles ARM: ixp4xx: Delete GTWX5715 board files ARM: ixp4xx: Delete Coyote and IXDPG425 boardfiles ARM: ixp4xx: Delete Intel reference design boardfiles ARM: ixp4xx: Delete Avila boardfiles ARM: ixp4xx: Delete the Arcom Vulcan boardfiles ARM: ixp4xx: Delete Gateway WG302v2 boardfiles ARM: ixp4xx: Delete Omicron boardfiles ARM: ixp4xx: Delete the D-Link DSM-G600 boardfiles ARM: ixp4xx: Delete NAS100D boardfiles ARM: ixp4xx: Delete NSLU2 boardfiles Link: https://lore.kernel.org/r/CACRpkdY=sPDkzmbmm+0UQnJi7BXZKH14GLmyVwKC+4cLCJpmdA@mail.gmail.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2021-08-18Merge tag 'tegra-for-5.15-soc' of ↵Arnd Bergmann3-9/+1
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into arm/drivers soc/tegra: Changes for v5.15-rc1 Implements runtime PM support for the FUSE block and prepares the driver to work better in conjunction with the CPUIDLE driver. * tag 'tegra-for-5.15-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux: soc/tegra: fuse: Enable fuse clock on suspend for Tegra124 soc/tegra: fuse: Add runtime PM support soc/tegra: fuse: Clear fuse->clk on driver probe failure soc/tegra: pmc: Prevent racing with cpuilde driver soc/tegra: bpmp: Remove unused including <linux/version.h> Link: https://lore.kernel.org/r/20210813162157.2820913-3-thierry.reding@gmail.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2021-08-18Merge tag 'mvebu-dt64-5.15-1' of ↵Arnd Bergmann17-805/+1267
git://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu into arm/dt mvebu dt64 for 5.15 (part 1) - DTS updates for Marvell Armada CN913x platforms + Add support for Armada CN913x Development Board topology "B" + Add support for Armada CN913x Reference Design boards (CRB) + Fixes the NAND partitioning scheme in DTS eliminating gap between consecutive partitions + Fix 10Gb ports PHY mode names - Extend PCIe MEM space on Armada 37xx: useful for some combination of PCIe cards where the initial 16MB was not enough * tag 'mvebu-dt64-5.15-1' of git://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu: arm64: dts: marvell: armada-37xx: Extend PCIe MEM space arch/arm64: dts: change 10gbase-kr to 10gbase-r in Armada arm64: dts: add support for Marvell cn9130-crb platform dts: marvell: Enable 10G interfaces on 9130-DB and 9131-DB boards arm64: dts: cn913x: add device trees for topology B boards Link: https://lore.kernel.org/r/878s10ypxe.fsf@BL-laptop Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2021-08-18Merge tag 'hisi-arm64-dt-for-5.15' of git://github.com/hisilicon/linux-hisi ↵Arnd Bergmann1-1/+1
into arm/dt ARM64: DT: HiSilicon ARM64 DT updates for 5.15 - Address a PCI bus range warning of the hi3660 SoC * tag 'hisi-arm64-dt-for-5.15' of git://github.com/hisilicon/linux-hisi: arm64: dts: HiSilicon: hi3660: address a PCI warning Link: https://lore.kernel.org/r/611B9BE9.8050904@hisilicon.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2021-08-18Merge tag 'sunxi-dt-for-5.15-1' of ↵Arnd Bergmann1-2/+25
git://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux into arm/dt Our usual round of DT patches for the 5.15 merge window, with some Tanix TX6 improvements this time. * tag 'sunxi-dt-for-5.15-1' of git://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux: arm64: dts: allwinner: h6: tanix-tx6: enable emmc arm64: dts: allwinner: h6: tanix-tx6: Add PIO power supplies arm64: dts: allwinner: h6: tanix-tx6: Fix regulator node names Link: https://lore.kernel.org/r/39cd7be5-a9a7-42b6-bc29-f895b9a3448a.lettre@localhost Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2021-08-18Merge tag 'aspeed-5.15-devicetree' of ↵Arnd Bergmann20-66/+2956
git://git.kernel.org/pub/scm/linux/kernel/git/joel/bmc into arm/dt ASPEED device tree updates for 5.15 - New machines * Facebook's Cloudripper * Facebook's Elbert * Facebook's Fuji All three carry the description of "Facebook's next generation switch platform with an AST2600 BMC integrated for health monitoring purpose." They share a 128 MB SPI NOR flash layout that is also used by some older platforms. * Inspur's NF5280M6, an x86 platform server with an AST2500-based BMC - SGPIO updates including AST2600 support - GPIO descriptions for the IBM AST2600 machines - Pinctrl fix - Updates to Facebook's AST2500 based machines * tag 'aspeed-5.15-devicetree' of git://git.kernel.org/pub/scm/linux/kernel/git/joel/bmc: (23 commits) ARM: dts: aspeed: p10bmc: Add power control pins ARM: dts: aspeed: cloudripper: Add comments for "mdio1" ARM: dts: aspeed: minipack: Update flash partition table ARM: dts: aspeed: Add Facebook Fuji (AST2600) BMC ARM: dts: aspeed: Add Facebook Elbert (AST2600) BMC ARM: dts: aspeed: Add Facebook Cloudripper (AST2600) BMC ARM: dts: aspeed: Common dtsi for Facebook AST2600 Network BMCs ARM: dts: aspeed: wedge400: Use common flash layout ARM: dts: Add Facebook BMC 128MB flash layout ARM: dts: aspeed-g5: Remove ngpios from sgpio node. ARM: dts: aspeed-g6: Add SGPIO node. dt-bindings: aspeed-sgpio: Add ast2600 sgpio dt-bindings: aspeed-sgpio: Convert txt bindings to yaml. ARM: dts: aspeed: ast2500evb: Enable built in RTC ARM: dts: aspeed: tacoma: Add TPM reset GPIO ARM: dts: rainier, everest: Add TPM reset GPIO ARM: dts: aspeed: wedge100: Enable ADC channels ARM: dts: aspeed: galaxy100: Remove redundant ADC device ARM: dts: aspeed: wedge40: Remove redundant ADC device ARM: dts: aspeed: Enable ADC in Facebook AST2400 common dtsi ... Link: https://lore.kernel.org/r/CACPK8XdWRBb9cuDWGQPfK8R8TsZuydJQHsL4_e2w=HvCKAMogg@mail.gmail.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2021-08-18Merge tag 'qcom-arm64-for-5.15' of ↵Arnd Bergmann58-892/+6749
git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/dt Qualcomm ARM64 updates for v5.15 SDM660 and SDM630 was concluded to be similar enough that they should be merged, and the derivative SDM636 was added to the bunch. The combined platform gained support for GPU, DMA, I2C, IMEM, display, power-domains, SDHCI, thermal, USB, interconnects, VADC, WLED and audio remoteproc. The Sony Xperia "Ganges" platform was similarly merged with "Nile", got cleaned up and gained touchscreen, USB, volume keys and uSD support. IPQ6018 gains USB2 and PCIe support and a few minor fixes. IPQ8074 gains SCM, PRNG and Crypto support and a DT style update of the PCIe nodes. MSM8916 gains Coresight STM support. The Xiaomi Redmi 2 is introduced, with touchscreen, notification LED and IMU support. MSM8996 gains support for GPU cooling and v3.0 of the SoC, which is used to introduce support for the Sony Xperia X Performance, XZ and XZs phones. SC7180 finally gains DisplayPort support and LPASS is updated accordingly. A number of fixes are introduced and with the newly introduced DRM aux bus in place Trogdor's panel is moved under the eDP bridge. SC7280 gained USB, eMMC, SD-card, QFPROM and IPA support, the new IDP2 board was added. SM6126 (aka Snapdragon 665) was introduced, together with the Sony Xperia 10II phone with support for framebuffer, USB, eMMC and volume keys. SM8150 gained inline crypto support for UFS enabled, CPU opp-tables was introduced to scale DDR and L3 frequencies and SPI nodes where added, in addition to a number of smaller fixes. SM8250 gained a number of minor fixes and had its serial engines wired up to use the GENI wrappers' DMA engines. SM8350 had wakeup-parent defined for the TLMM gpio node and I2C13 was introduced. SDM845 display clocks was corrected and Lenovo Yoga C630 got IPA enabled and now has working LTE connectivity. Additionally a number of minor fixes throughout to correct DT validation warnings. Lastly v5.14-rc3 is merge in to resolve the merge conflicts caused by the USB maintainer deciding to fix a regression in his tree. * tag 'qcom-arm64-for-5.15' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux: (114 commits) arm64: dts: qcom: sm8250: assign DSI clock source parents arm64: dts: qcom: sdm845-mtp: assign DSI clock source parents arm64: dts: qcom: sdm845: assign DSI clock source parents arm64: dts: qcom: sc7180: assign DSI clock source parents arm64: dts: qcom: sc7280-idp: Add device tree files for IDP2 dt-bindings: arm: qcom: Document qcom,sc7280-idp2 board arm64: dts: qcom: sm8350: fix IPA interconnects arm64: dts: qcom: sc7180: define ipa_fw_mem node arm64: dts: qcom: sc7280: enable IPA for sc7280-idp arm64: dts: qcom: sc7280: add IPA information arm64: dts: qcom: sc7180-trogdor: Move panel under the bridge chip arm64: dts: qcom: ipq8074: add PRNG node arm64: dts: qcom: ipq8074: add crypto nodes arm64: dts: qcom: sm8350: add qupv3_id_1/i2c13 nodes arm64: dts: qcom: ipq6018: Add pcie support arm64: dts: qcom: pm8150b: Add DTS node for PMIC VBUS booster arm64: dts: qcom: sm8150: add SPI nodes arm64: dts: qcom: msm8916: Enable CoreSight STM component arm64: dts: qcom: sc7280: Add qfprom node arm64: dts: qcom: sc7280: Fixup the cpufreq node ... Link: https://lore.kernel.org/r/20210816231223.586597-1-bjorn.andersson@linaro.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2021-08-18KVM: arm64: Make hyp_panic() more robust when protected mode is enabledWill Deacon2-13/+31
When protected mode is enabled, the host is unable to access most parts of the EL2 hypervisor image, including 'hyp_physvirt_offset' and the contents of the hypervisor's '.rodata.str' section. Unfortunately, nvhe_hyp_panic_handler() tries to read from both of these locations when handling a BUG() triggered at EL2; the former for converting the ELR to a physical address and the latter for displaying the name of the source file where the BUG() occurred. Hack the EL2 panic asm to pass both physical and virtual ELR values to the host and utilise the newly introduced CONFIG_NVHE_EL2_DEBUG so that we disable stage-2 protection for the host before returning to the EL1 panic handler. If the debug option is not enabled, display the address instead of the source file:line information. Cc: Andrew Scull <ascull@google.com> Cc: Quentin Perret <qperret@google.com> Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210813130336.8139-1-will@kernel.org
2021-08-18KVM: arm64: Drop unused REQUIRES_VIRTAnshuman Khandual1-4/+0
This seems like a residue from the past. REQUIRES_VIRT is no more available . Hence it can just be dropped along with the related code section. Cc: Marc Zyngier <maz@kernel.org> Cc: James Morse <james.morse@arm.com> Cc: Alexandru Elisei <alexandru.elisei@arm.com> Cc: Suzuki K Poulose <suzuki.poulose@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org> Cc: linux-arm-kernel@lists.infradead.org Cc: kvmarm@lists.cs.columbia.edu Cc: linux-kernel@vger.kernel.org Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/1628744994-16623-6-git-send-email-anshuman.khandual@arm.com