summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2020-01-14ARM: vdso: Set BUILD_VDSO32 and provide 32bit fallbacksThomas Gleixner
Setting BUILD_VDSO32 is required to expose the legacy 32bit interfaces in the generic VDSO code which are going to be hidden behind an #ifdef BUILD_VDSO32. The 32bit fallbacks are necessary to remove the existing VDSO_HAS_32BIT_FALLBACK hackery. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Vincenzo Frascino <vincenzo.frascino@arm.com> Cc: linux-arm-kernel@lists.infradead.org Link: https://lore.kernel.org/r/87tv4zq9dc.fsf@nanos.tec.linutronix.de
2020-01-14arm64: compat: vdso: Expose BUILD_VDSO32Vincenzo Frascino
clock_gettime32 and clock_getres_time32 should be compiled only with the 32 bit vdso library. Expose BUILD_VDSO32 when arm64 compat is compiled, to provide an indication to the generic library to include these symbols. Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Link: https://lore.kernel.org/r/20190830135902.20861-2-vincenzo.frascino@arm.com
2020-01-14m68k: Implement copy_thread_tls()Geert Uytterhoeven
This is required for clone3(), which passes the TLS value through a struct rather than a register. As do_fork() is only available if CONFIG_HAVE_COPY_THREAD_TLS is set, m68k_clone() must be changed to call _do_fork() directly. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Christian Brauner <christian.brauner@ubuntu.com> Acked-by: Greg Ungerer <gerg@linux-m68k.org> Link: https://lore.kernel.org/r/20200113103040.23661-1-geert@linux-m68k.org
2020-01-14parisc: fix map_pages() to actually populate upper directoryMike Rapoport
The commit d96885e277b5 ("parisc: use pgtable-nopXd instead of 4level-fixup") converted PA-RISC to use folded page tables, but it missed the conversion of pgd_populate() to pud_populate() in maps_pages() function. This caused the upper page table directory to remain empty and the system would crash as a result. Using pud_populate() that actually populates the page table instead of dummy pgd_populate() fixes the issue. Fixes: d96885e277b5 ("parisc: use pgtable-nopXd instead of 4level-fixup") Reported-by: Meelis Roos <mroos@linux.ee> Reported-by: Jeroen Roovers <jer@gentoo.org> Reported-by: Mikulas Patocka <mpatocka@redhat.com> Tested-by: Jeroen Roovers <jer@gentoo.org> Tested-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com> Signed-off-by: Helge Deller <deller@gmx.de>
2020-01-14parisc: Use proper printk format for resource_size_tKrzysztof Kozlowski
resource_size_t should be printed with its own size-independent format to fix warnings when compiling on 64-bit platform (e.g. with COMPILE_TEST): arch/parisc/kernel/drivers.c: In function 'print_parisc_device': arch/parisc/kernel/drivers.c:892:9: warning: format '%p' expects argument of type 'void *', but argument 4 has type 'resource_size_t {aka unsigned int}' [-Wformat=] Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Helge Deller <deller@gmx.de>
2020-01-14powerpc/pseries: Advance pfn if section is not present in lmb_is_removable()Pingfan Liu
In lmb_is_removable(), if a section is not present, it should continue to test the rest of the sections in the block. But the current code fails to do so. Fixes: 51925fb3c5c9 ("powerpc/pseries: Implement memory hotplug remove in the kernel") Cc: stable@vger.kernel.org # v4.1+ Signed-off-by: Pingfan Liu <kernelfans@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/1578632042-12415-1-git-send-email-kernelfans@gmail.com
2020-01-14powerpc/xmon: don't access ASDR in VMsSukadev Bhattiprolu
ASDR is HV-privileged and must only be accessed in HV-mode. Fixes a Program Check (0x700) when xmon in a VM dumps SPRs. Fixes: d1e1b351f50f ("powerpc/xmon: Add ISA v3.0 SPRs to SPR dump") Cc: stable@vger.kernel.org # v4.14+ Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.ibm.com> Reviewed-by: Andrew Donnellan <ajd@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20200107021633.GB29843@us.ibm.com
2020-01-13arch: wire up pidfd_getfd syscallSargun Dhillon
This wires up the pidfd_getfd syscall for all architectures. Signed-off-by: Sargun Dhillon <sargun@sargun.me> Acked-by: Christian Brauner <christian.brauner@ubuntu.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20200107175927.4558-4-sargun@sargun.me Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
2020-01-13arm64: dts: qcom: sdm845: move gpu zap nodes to per-device dtsRob Clark
We want to specify per-device firmware-name, so move the zap node into the .dts file for individual boards/devices. This lets us get rid of the /delete-node/ for cheza, which does not use zap. Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Rob Clark <robdclark@chromium.org> Link: https://lore.kernel.org/r/20200112195405.1132288-5-robdclark@gmail.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-01-13arm64: dts: qcom: sm8150: Hard code rpmhpd constantsBjorn Andersson
I missed the fact that these constants was not yet available, so hard code their values in the dts to make the branch compile on its own. Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-01-13MIPS: ip22-gio: Make gio_match_device() staticGeert Uytterhoeven
Unlike its PCI counterpart, gio_match_device() was never used outside the GIO bus code. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Paul Burton <paulburton@kernel.org> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: James Hogan <jhogan@kernel.org> Cc: linux-mips@vger.kernel.org Cc: linux-kernel@vger.kernel.org
2020-01-13KVM: VMX: Allow KVM_INTEL when building for Centaur and/or Zhaoxin CPUsSean Christopherson
Change the dependency for KVM_INTEL, i.e. KVM w/ VMX, from Intel CPUs to any CPU that supports the IA32_FEAT_CTL MSR and thus VMX functionality. This effectively allows building KVM_INTEL for Centaur and Zhaoxin CPUs. Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lkml.kernel.org/r/20191221044513.21680-20-sean.j.christopherson@intel.com
2020-01-13perf/x86: Provide stubs of KVM helpers for non-Intel CPUsSean Christopherson
Provide stubs for perf_guest_get_msrs() and intel_pt_handle_vmx() when building without support for Intel CPUs, i.e. CPU_SUP_INTEL=n. Lack of stubs is not currently a problem as the only user, KVM_INTEL, takes a dependency on CPU_SUP_INTEL=y. Provide the stubs for all CPUs so that KVM_INTEL can be built for any CPU with compatible hardware support, e.g. Centuar and Zhaoxin CPUs. Note, the existing stub for perf_guest_get_msrs() is essentially dead code as KVM selects CONFIG_PERF_EVENTS, i.e. the only user guarantees the full implementation is built. Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lkml.kernel.org/r/20191221044513.21680-19-sean.j.christopherson@intel.com
2020-01-13KVM: VMX: Use VMX_FEATURE_* flags to define VMCS control bitsSean Christopherson
Define the VMCS execution control flags (consumed by KVM) using their associated VMX_FEATURE_* to provide a strong hint that new VMX features are expected to be added to VMX_FEATURE and considered for reporting via /proc/cpuinfo. No functional change intended. Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lkml.kernel.org/r/20191221044513.21680-18-sean.j.christopherson@intel.com
2020-01-13KVM: VMX: Check for full VMX support when verifying CPU compatibilitySean Christopherson
Explicitly check the current CPU's IA32_FEAT_CTL and VMX feature flags when verifying compatibility across physical CPUs. This effectively adds a check on IA32_FEAT_CTL to ensure that VMX is fully enabled on all CPUs. Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lkml.kernel.org/r/20191221044513.21680-17-sean.j.christopherson@intel.com
2020-01-13KVM: VMX: Use VMX feature flag to query BIOS enablingSean Christopherson
Replace KVM's manual checks on IA32_FEAT_CTL with a query on the boot CPU's MSR_IA32_FEAT_CTL and VMX feature flags. The MSR_IA32_FEAT_CTL indicates that IA32_FEAT_CTL has been configured and that dependent features are accurately reflected in cpufeatures, e.g. the VMX flag is now cleared during boot if VMX isn't fully enabled via IA32_FEAT_CTL, including the case where the MSR isn't supported. Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lkml.kernel.org/r/20191221044513.21680-16-sean.j.christopherson@intel.com
2020-01-13ARM: dts: Add omap3-echoAndré Hentschel
This is the first generation Amazon Echo from 2016. Audio support is not yet implemented. Signed-off-by: André Hentschel <nerv@dawncrow.de> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-01-13ARM: dts: Add dtsi files for AM3703, AM3715 and DM3725André Hentschel
DM3730 is considered as omap36xx.dtsi, while the rest has: DM3730 | DM3725 | AM3715 | AM3703 IVA X | X | | SGX X | | X | Where X is "supported" Signed-off-by: André Hentschel <nerv@dawncrow.de> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-01-13ARM: OMAP2+: sleep43xx: Call secure suspend/resume handlersAndrew F. Davis
During suspend CPU context may be lost in both non-secure and secure CPU states. The kernel can handle saving and restoring the non-secure context but must call into the secure side to allow it to save any context it may lose. Add these calls here. Note that on systems with OP-TEE available the suspend call is issued to OP-TEE using the ARM SMCCC, but the resume call is always issued to the ROM. This is because on waking from suspend the ROM is restored as the secure monitor. It is this resume call that instructs the ROM to restore OP-TEE, all subsequent calls will be handled by OP-TEE and should use the ARM SMCCC. Signed-off-by: Andrew F. Davis <afd@ti.com> Acked-by: Dave Gerlach <d-gerlach@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-01-13ARM: OMAP2+: Use ARM SMC Calling Convention when OP-TEE is availableAndrew F. Davis
On High-Security(HS) OMAP2+ class devices a couple actions must be performed from the ARM TrustZone during boot. These traditionally can be performed by calling into the secure ROM code resident in this secure world using legacy SMC calls. Optionally OP-TEE can replace this secure world functionality by replacing the ROM after boot. ARM recommends a standard calling convention is used for this interaction (SMC Calling Convention). We check for the presence of OP-TEE and use this type of call to perform the needed actions, falling back to the legacy OMAP ROM call if OP-TEE is not available. Signed-off-by: Andrew F. Davis <afd@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-01-13ARM: OMAP2+: Introduce check for OP-TEE in omap_secure_init()Andrew F. Davis
This check and associated flag can be used to signal the presence of OP-TEE on the platform. This can be used to determine which SMC calls to make to perform secure operations. Signed-off-by: Andrew F. Davis <afd@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-01-13KVM: VMX: Drop initialization of IA32_FEAT_CTL MSRSean Christopherson
Remove KVM's code to initialize IA32_FEAT_CTL MSR when KVM is loaded now that the MSR is initialized during boot on all CPUs that support VMX, i.e. on all CPUs that can possibly load kvm_intel. Note, don't WARN if IA32_FEAT_CTL is unlocked, even though the MSR is unconditionally locked by init_ia32_feat_ctl(). KVM isn't tied directly to a CPU vendor detection, whereas init_ia32_feat_ctl() is invoked if and only if the CPU vendor is recognized and known to support VMX. As a result, vmx_disabled_by_bios() may be reached without going through init_ia32_feat_ctl() and thus without locking IA32_FEAT_CTL. This quirk will be eliminated in a future patch. Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Jim Mattson <jmattson@google.com> Link: https://lkml.kernel.org/r/20191221044513.21680-15-sean.j.christopherson@intel.com
2020-01-13ARM: OMAP2+: Add omap_secure_init callback hook for secure initializationAndrew F. Davis
This can be used for detecting secure features or making early device init sequence changes based on device security type. Signed-off-by: Andrew F. Davis <afd@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-01-13ARM: dts: am335x-boneblack-common: fix memory sizeMatwey V. Kornilov
BeagleBone Black series is equipped with 512MB RAM whereas only 256MB is included from am335x-bone-common.dtsi This leads to an issue with unusual setups when devicetree is loaded by GRUB2 directly. Signed-off-by: Matwey V. Kornilov <matwey@sai.msu.ru> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-01-13x86/cpufeatures: Add flag to track whether MSR IA32_FEAT_CTL is configuredSean Christopherson
Add a new feature flag, X86_FEATURE_MSR_IA32_FEAT_CTL, to track whether IA32_FEAT_CTL has been initialized. This will allow KVM, and any future subsystems that depend on IA32_FEAT_CTL, to rely purely on cpufeatures to query platform support, e.g. allows a future patch to remove KVM's manual IA32_FEAT_CTL MSR checks. Various features (on platforms that support IA32_FEAT_CTL) are dependent on IA32_FEAT_CTL being configured and locked, e.g. VMX and LMCE. The MSR is always configured during boot, but only if the CPU vendor is recognized by the kernel. Because CPUID doesn't incorporate the current IA32_FEAT_CTL value in its reporting of relevant features, it's possible for a feature to be reported as supported in cpufeatures but not truly enabled, e.g. if the CPU supports VMX but the kernel doesn't recognize the CPU. As a result, without the flag, KVM would see VMX as supported even if IA32_FEAT_CTL hasn't been initialized, and so would need to manually read the MSR and check the various enabling bits to avoid taking an unexpected #GP on VMXON. Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lkml.kernel.org/r/20191221044513.21680-14-sean.j.christopherson@intel.com
2020-01-13x86/cpu: Set synthetic VMX cpufeatures during init_ia32_feat_ctl()Sean Christopherson
Set the synthetic VMX cpufeatures, which need to be kept to preserve /proc/cpuinfo's ABI, in the common IA32_FEAT_CTL initialization code. Remove the vendor code that manually sets the synthetic flags. Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lkml.kernel.org/r/20191221044513.21680-13-sean.j.christopherson@intel.com
2020-01-13x86/cpu: Print VMX flags in /proc/cpuinfo using VMX_FEATURES_*Sean Christopherson
Add support for generating VMX feature names in capflags.c and use the resulting x86_vmx_flags to print the VMX flags in /proc/cpuinfo. Don't print VMX flags if no bits are set in word 0, which holds Pin Controls. Pin Control's INTR and NMI exiting are fundamental pillars of VMX, if they are not supported then the CPU is broken, it does not actually support VMX, or the kernel wasn't built with support for the target CPU. Print the features in a dedicated "vmx flags" line to avoid polluting the common "flags" and to avoid having to prefix all flags with "vmx_", which results in horrendously long names. Keep synthetic VMX flags in cpufeatures to preserve /proc/cpuinfo's ABI for those flags. This means that "flags" and "vmx flags" will have duplicate entries for tpr_shadow (virtual_tpr), vnmi, ept, flexpriority, vpid and ept_ad, but caps the pollution of "flags" at those six VMX features. The vendor-specific code that populates the synthetic flags will be consolidated in a future patch to further minimize the lasting damage. Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lkml.kernel.org/r/20191221044513.21680-12-sean.j.christopherson@intel.com
2020-01-13x86/cpu: Detect VMX features on Intel, Centaur and Zhaoxin CPUsSean Christopherson
Add an entry in struct cpuinfo_x86 to track VMX capabilities and fill the capabilities during IA32_FEAT_CTL MSR initialization. Make the VMX capabilities dependent on IA32_FEAT_CTL and X86_FEATURE_NAMES so as to avoid unnecessary overhead on CPUs that can't possibly support VMX, or when /proc/cpuinfo is not available. Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lkml.kernel.org/r/20191221044513.21680-11-sean.j.christopherson@intel.com
2020-01-13x86/vmx: Introduce VMX_FEATURES_*Sean Christopherson
Add a VMX-specific variant of X86_FEATURE_* flags, which will eventually supplant the synthetic VMX flags defined in cpufeatures word 8. Use the Intel-defined layouts for the major VMX execution controls so that their word entries can be directly populated from their respective MSRs, and so that the VMX_FEATURE_* flags can be used to define the existing bit definitions in asm/vmx.h, i.e. force developers to define a VMX_FEATURE flag when adding support for a new hardware feature. The majority of Intel's (and compatible CPU's) VMX capabilities are enumerated via MSRs and not CPUID, i.e. querying /proc/cpuinfo doesn't naturally provide any insight into the virtualization capabilities of VMX enabled CPUs. Commit e38e05a85828d ("x86: extended "flags" to show virtualization HW feature in /proc/cpuinfo") attempted to address the issue by synthesizing select VMX features into a Linux-defined word in cpufeatures. Lack of reporting of VMX capabilities via /proc/cpuinfo is problematic because there is no sane way for a user to query the capabilities of their platform, e.g. when trying to find a platform to test a feature or debug an issue that has a hardware dependency. Lack of reporting is especially problematic when the user isn't familiar with VMX, e.g. the format of the MSRs is non-standard, existence of some MSRs is reported by bits in other MSRs, several "features" from KVM's point of view are enumerated as 3+ distinct features by hardware, etc... The synthetic cpufeatures approach has several flaws: - The set of synthesized VMX flags has become extremely stale with respect to the full set of VMX features, e.g. only one new flag (EPT A/D) has been added in the the decade since the introduction of the synthetic VMX features. Failure to keep the VMX flags up to date is likely due to the lack of a mechanism that forces developers to consider whether or not a new feature is worth reporting. - The synthetic flags may incorrectly be misinterpreted as affecting kernel behavior, i.e. KVM, the kernel's sole consumer of VMX, completely ignores the synthetic flags. - New CPU vendors that support VMX have duplicated the hideous code that propagates VMX features from MSRs to cpufeatures. Bringing the synthetic VMX flags up to date would exacerbate the copy+paste trainwreck. Define separate VMX_FEATURE flags to set the stage for enumerating VMX capabilities outside of the cpu_has() framework, and for adding functional usage of VMX_FEATURE_* to help ensure the features reported via /proc/cpuinfo is up to date with respect to kernel recognition of VMX capabilities. Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lkml.kernel.org/r/20191221044513.21680-10-sean.j.christopherson@intel.com
2020-01-13x86/cpu: Clear VMX feature flag if VMX is not fully enabledSean Christopherson
Now that IA32_FEAT_CTL is always configured and locked for CPUs that are known to support VMX[*], clear the VMX capability flag if the MSR is unsupported or BIOS disabled VMX, i.e. locked IA32_FEAT_CTL and didn't set the appropriate VMX enable bit. [*] Because init_ia32_feat_ctl() is called from vendors ->c_init(), it's still possible for IA32_FEAT_CTL to be left unlocked when VMX is supported by the CPU. This is not fatal, and will be addressed in a future patch. Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lkml.kernel.org/r/20191221044513.21680-9-sean.j.christopherson@intel.com
2020-01-13x86/zhaoxin: Use common IA32_FEAT_CTL MSR initializationSean Christopherson
Use the recently added IA32_FEAT_CTL MSR initialization sequence to opportunistically enable VMX support when running on a Zhaoxin CPU. Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lkml.kernel.org/r/20191221044513.21680-8-sean.j.christopherson@intel.com
2020-01-13x86/centaur: Use common IA32_FEAT_CTL MSR initializationSean Christopherson
Use the recently added IA32_FEAT_CTL MSR initialization sequence to opportunistically enable VMX support when running on a Centaur CPU. Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lkml.kernel.org/r/20191221044513.21680-7-sean.j.christopherson@intel.com
2020-01-13x86/mce: WARN once if IA32_FEAT_CTL MSR is left unlockedSean Christopherson
WARN if the IA32_FEAT_CTL MSR is somehow left unlocked now that CPU initialization unconditionally locks the MSR. Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lkml.kernel.org/r/20191221044513.21680-6-sean.j.christopherson@intel.com
2020-01-13x86/intel: Initialize IA32_FEAT_CTL MSR at bootSean Christopherson
Opportunistically initialize IA32_FEAT_CTL to enable VMX when the MSR is left unlocked by BIOS. Configuring feature control at boot time paves the way for similar enabling of other features, e.g. Software Guard Extensions (SGX). Temporarily leave equivalent KVM code in place in order to avoid introducing a regression on Centaur and Zhaoxin CPUs, e.g. removing KVM's code would leave the MSR unlocked on those CPUs and would break existing functionality if people are loading kvm_intel on Centaur and/or Zhaoxin. Defer enablement of the boot-time configuration on Centaur and Zhaoxin to future patches to aid bisection. Note, Local Machine Check Exceptions (LMCE) are also supported by the kernel and enabled via feature control, but the kernel currently uses LMCE if and only if the feature is explicitly enabled by BIOS. Keep the current behavior to avoid introducing bugs, future patches can opt in to opportunistic enabling if it's deemed desirable to do so. Always lock IA32_FEAT_CTL if it exists, even if the CPU doesn't support VMX, so that other existing and future kernel code that queries the MSR can assume it's locked. Start from a clean slate when constructing the value to write to IA32_FEAT_CTL, i.e. ignore whatever value BIOS left in the MSR so as not to enable random features or fault on the WRMSR. Suggested-by: Borislav Petkov <bp@suse.de> Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lkml.kernel.org/r/20191221044513.21680-5-sean.j.christopherson@intel.com
2020-01-13x86/msr-index: Clean up bit defines for IA32_FEATURE_CONTROL MSRSean Christopherson
As pointed out by Boris, the defines for bits in IA32_FEATURE_CONTROL are quite a mouthful, especially the VMX bits which must differentiate between enabling VMX inside and outside SMX (TXT) operation. Rename the MSR and its bit defines to abbreviate FEATURE_CONTROL as FEAT_CTL to make them a little friendlier on the eyes. Arguably, the MSR itself should keep the full IA32_FEATURE_CONTROL name to match Intel's SDM, but a future patch will add a dedicated Kconfig, file and functions for the MSR. Using the full name for those assets is rather unwieldy, so bite the bullet and use IA32_FEAT_CTL so that its nomenclature is consistent throughout the kernel. Opportunistically, fix a few other annoyances with the defines: - Relocate the bit defines so that they immediately follow the MSR define, e.g. aren't mistaken as belonging to MISC_FEATURE_CONTROL. - Add whitespace around the block of feature control defines to make it clear they're all related. - Use BIT() instead of manually encoding the bit shift. - Use "VMX" instead of "VMXON" to match the SDM. - Append "_ENABLED" to the LMCE (Local Machine Check Exception) bit to be consistent with the kernel's verbiage used for all other feature control bits. Note, the SDM refers to the LMCE bit as LMCE_ON, likely to differentiate it from IA32_MCG_EXT_CTL.LMCE_EN. Ignore the (literal) one-off usage of _ON, the SDM is simply "wrong". Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lkml.kernel.org/r/20191221044513.21680-2-sean.j.christopherson@intel.com
2020-01-13x86/resctrl: Do not reconfigure exiting tasksXiaochen Shen
When writing a pid to file "tasks", a callback function move_myself() is queued to this task to be called when the task returns from kernel mode or exits. The purpose of move_myself() is to activate the newly assigned closid and/or rmid associated with this task. This activation is done by calling resctrl_sched_in() from move_myself(), the same function that is called when switching to this task. If this work is successfully queued but then the task enters PF_EXITING status (e.g., receiving signal SIGKILL, SIGTERM) prior to the execution of the callback move_myself(), move_myself() still calls resctrl_sched_in() since the task status is not currently considered. When a task is exiting, the data structure of the task itself will be freed soon. Calling resctrl_sched_in() to write the register that controls the task's resources is unnecessary and it implies extra performance overhead. Add check on task status in move_myself() and return immediately if the task is PF_EXITING. [ bp: Massage. ] Signed-off-by: Xiaochen Shen <xiaochen.shen@intel.com> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Reinette Chatre <reinette.chatre@intel.com> Link: https://lkml.kernel.org/r/1578500026-21152-1-git-send-email-xiaochen.shen@intel.com
2020-01-13ARM: davinci: dm644x-evm: Add Fixed regulators needed for tlv320aic33Peter Ujfalusi
The codec driver needs correct regulators in order to probe. Both VCC_3.3V and VCC_1.8V is always on fixed regulators on the board. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2020-01-13ARM: davinci: dm365-evm: Add Fixed regulators needed for tlv320aic3101Peter Ujfalusi
The codec driver needs correct regulators in order to probe. Both VCC_3V3 and VCC_1V8 is always on fixed regulators on the board. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2020-01-13arm64: kernel: Correct annotation of end of el0_syncMark Brown
Commit 582f95835a8fc812c ("arm64: entry: convert el0_sync to C") caused the ENDPROC() annotating the end of el0_sync to be placed after the code for el0_sync_compat. This replaced the previous annotation where it was located after all the cases that are now converted to C, including after the currently unannotated el0_irq_compat and el0_error_compat. Move the annotation to the end of the function and add separate annotations for the _compat ones. Fixes: 582f95835a8fc812c (arm64: entry: convert el0_sync to C) Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Will Deacon <will@kernel.org>
2020-01-13Merge 5.5-rc6 into tty-nextGreg Kroah-Hartman
We need the serial/tty fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-01-13Merge 5.5-rc6 into usb-nextGreg Kroah-Hartman
We need the USB fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-01-13ARM: dts: rockchip: add reg property to brcmf sub node for rk3188-bqedison2qcJohan Jonker
An experimental test with the command below gives this error: rk3188-bqedison2qc.dt.yaml: dwmmc@10218000: wifi@1: 'reg' is a required property So fix this by adding a reg property to the brcmf sub node. Also add #address-cells and #size-cells to prevent more warnings. make ARCH=arm dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml Signed-off-by: Johan Jonker <jbx6244@gmail.com> Link: https://lore.kernel.org/r/20200110134420.11280-1-jbx6244@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2020-01-13arm64: dts: rockchip: hook up the px30-evb dsi displayHeiko Stuebner
Create the necessary display nodes to activate the Xingpeng XPP055C272 dsi display that can be found on the px30-evb. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Link: https://lore.kernel.org/r/20191209145301.5307-2-heiko@sntech.de
2020-01-13Merge back power capping changes for v5.6.Rafael J. Wysocki
2020-01-13arm64: dts: mt8183: add reset-cells in infracfgyong.liang
Include mt8183-reset.h and add reset-cells in infracfg in dtsi file Signed-off-by: yong.liang <yong.liang@mediatek.com> Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
2020-01-13arm64: dts: rockchip: Enable sdio0 and uart0 on rk3399-roc-pc-mezzanineMarkus Reichl
The mezzanine board carries an E key type M.2 slot. This is connected to USB, SDIO and UART0. Enable sdio and uart0 for use with wlan and/or bt M.2 cards. Signed-off-by: Markus Reichl <m.reichl@fivetechno.de> Link: https://lore.kernel.org/r/20200109154211.1530-1-m.reichl@fivetechno.de Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2020-01-13arm64: dts: rockchip: add reg property to brcmf sub-nodesJohan Jonker
An experimental test with the command below gives this error: rk3399-firefly.dt.yaml: dwmmc@fe310000: wifi@1: 'reg' is a required property rk3399-orangepi.dt.yaml: dwmmc@fe310000: wifi@1: 'reg' is a required property rk3399-khadas-edge.dt.yaml: dwmmc@fe310000: wifi@1: 'reg' is a required property rk3399-khadas-edge-captain.dt.yaml: dwmmc@fe310000: wifi@1: 'reg' is a required property rk3399-khadas-edge-v.dt.yaml: dwmmc@fe310000: wifi@1: 'reg' is a required property So fix this by adding a reg property to the brcmf sub node. Also add #address-cells and #size-cells to prevent more warnings. make ARCH=arm64 dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml Signed-off-by: Johan Jonker <jbx6244@gmail.com> Link: https://lore.kernel.org/r/20200110142128.13522-1-jbx6244@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2020-01-13arm64: dts: rockchip: fix dwmmc clock name for rk3308Johan Jonker
An experimental test with the command below gives this error: rk3308-evb.dt.yaml: dwmmc@ff480000: clock-names:2: 'ciu-drive' was expected 'ciu-drv' is not a valid dwmmc clock name, so fix this by changing it to 'ciu-drive'. make ARCH=arm64 dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml Signed-off-by: Johan Jonker <jbx6244@gmail.com> Link: https://lore.kernel.org/r/20200110161200.22755-1-jbx6244@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2020-01-13arm64: dts: rockchip: fix dwmmc clock name for px30Johan Jonker
An experimental test with the command below gives this error: px30-evb.dt.yaml: dwmmc@ff390000: clock-names:2: 'ciu-drive' was expected 'ciu-drv' is not a valid dwmmc clock name, so fix this by changing it to 'ciu-drive'. make ARCH=arm64 dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml Signed-off-by: Johan Jonker <jbx6244@gmail.com> Link: https://lore.kernel.org/r/20200110161200.22755-1-jbx6244@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2020-01-13x86/mce: Fix use of uninitialized MCE message stringJan H. Schönherr
The function mce_severity() is not required to update its msg argument. In fact, mce_severity_amd() does not, which makes mce_no_way_out() return uninitialized data, which may be used later for printing. Assuming that implementations of mce_severity() either always or never update the msg argument (which is currently the case), it is sufficient to initialize the temporary variable in mce_no_way_out(). While at it, avoid printing a useless "Unknown". Signed-off-by: Jan H. Schönherr <jschoenh@amazon.de> Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lkml.kernel.org/r/20200103150722.20313-4-jschoenh@amazon.de
generated by cgit (git 2.34.1) at 2025-09-19 14:44:22 +0000