wireguard-linux/arch/x86/platform, branch update-toolchain

Merge tag 'for-linus-6.11-rc1a-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip

2024-07-27T16:58:24Z

Pull xen fixes from Juergen Gross: "Two fixes for issues introduced in this merge window: - fix enhanced debugging in the Xen multicall handling - two patches fixing a boot failure when running as dom0 in PVH mode" * tag 'for-linus-6.11-rc1a-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip: x86/xen: fix memblock_reserve() usage on PVH x86/xen: move xen_reserve_extra_memory() xen: fix multicall debug data referencing

x86/xen: fix memblock_reserve() usage on PVH

2024-07-25T11:11:08Z

The current usage of memblock_reserve() in init_pvh_bootparams() is done before the .bss is zeroed, and that used to be fine when memblock_reserved_init_regions implicitly ended up in the .meminit.data section. However after commit 73db3abdca58c memblock_reserved_init_regions ends up in the .bss section, thus breaking it's usage before the .bss is cleared. Move and rename the call to xen_reserve_extra_memory() so it's done in the x86_init.oem.arch_setup hook, which gets executed after the .bss has been zeroed, but before calling e820__memory_setup(). Fixes: 73db3abdca58c ("init/modpost: conditionally check section mismatch to __meminit*") Signed-off-by: Roger Pau Monné Reviewed-by: Juergen Gross Message-ID: <20240725073116.14626-3-roger.pau@citrix.com> Signed-off-by: Juergen Gross

Merge tag 'platform-drivers-x86-v6.11-1' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86

2024-07-18T00:05:21Z

Pull x86 platform driver updates from Ilpo Järvinen: - amd/pmf: Report system state changes using existing input events - asus-wmi: Zenbook 2023 camera LED disable support and fix TUF laptop keyboard RGB LED sysfs interface - dell-pc: Fan modes / platform profile support - hp-wmi: Fix platform profile switching on Omen/Victus laptops - intel/ISST: Use only TPMI interface when TPMI and legacy interfaces are available - intel/pmc: LTR restore support to pair with LTR ignore - intel/tpmi: Performance Limit Reasons (PLR) and APIC <-> Punit CPU numbering mapping support - WMI: driver override support and docs improvements - lenovo-yoga-c630: Support for EC (platform/arm64) - platform/arm64: Fix build with COMPILE_TEST (broke after addition of C630) - tools: Intel Speed Select Turbo Ratio Limit fix - Miscellaneous cleanups / refactoring / improvements * tag 'platform-drivers-x86-v6.11-1' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86: (65 commits) platform/x86: asus-wmi: fix TUF laptop RGB variant platform/x86/intel/tpmi/plr: Fix output in plr_print_bits() Docs/admin-guide: Remove pmf leftover reference from the index platform/x86: ideapad-laptop: use cleanup.h platform/x86: hp-wmi: Fix implementation of the platform_profile_omen_get function platform: arm64: EC_LENOVO_YOGA_C630 should depend on ARCH_QCOM platform: arm64: EC_ACER_ASPIRE1 should depend on ARCH_QCOM platform/x86/amd/pmf: Remove update system state document platform/x86/amd/pmf: Use existing input event codes to update system states platform/x86: hp-wmi: Fix platform profile option switch bug on Omen and Victus laptops platform/x86:intel/pmc: Add support to undo ltr_ignore platform/x86:intel/pmc: Use the Elvis operator platform/x86:intel/pmc: Use DEFINE_SHOW_STORE_ATTRIBUTE macro platform/x86:intel/pmc: Remove unneeded min_t check platform/x86:intel/pmc: Add support to show ltr_ignore value platform/x86:intel/pmc: Move pmc assignment closer to first usage platform/x86:intel/pmc: Convert index variables to be unsigned platform/x86:intel/pmc: Simplify mutex usage with cleanup helpers platform/x86:intel/pmc: Use the return value of pmc_core_send_msg tools/power/x86/intel-speed-select: v1.20 release ...

Merge tag 'efi-next-for-v6.11' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi

2024-07-16T19:22:07Z

Pull EFI updates from Ard Biesheuvel: "Note the removal of the EFI fake memory map support - this is believed to be unused and no longer worth supporting. However, we could easily bring it back if needed. With recent developments regarding confidential VMs and unaccepted memory, combined with kexec, creating a known inaccurate view of the firmware's memory map and handing it to the OS is a feature we can live without, hence the removal. Alternatively, I could imagine making this feature mutually exclusive with those confidential VM related features, but let's try simply removing it first. Summary: - Drop support for the 'fake' EFI memory map on x86 - Add an SMBIOS based tweak to the EFI stub instructing the firmware on x86 Macbook Pros to keep both GPUs enabled - Replace 0-sized array with flexible array in EFI memory attributes table handling - Drop redundant BSS clearing when booting via the native PE entrypoint on x86 - Avoid returning EFI_SUCCESS when aborting on an out-of-memory condition - Cosmetic tweak for arm64 KASLR loading logic" * tag 'efi-next-for-v6.11' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi: efi: Replace efi_memory_attributes_table_t 0-sized array with flexible array efi: Rename efi_early_memdesc_ptr() to efi_memdesc_ptr() arm64/efistub: Clean up KASLR logic x86/efistub: Drop redundant clearing of BSS x86/efistub: Avoid returning EFI_SUCCESS on error x86/efistub: Call Apple set_os protocol on dual GPU Intel Macs x86/efistub: Enable SMBIOS protocol handling for x86 efistub/smbios: Simplify SMBIOS enumeration API x86/efi: Drop support for fake EFI memory maps

Merge tag 'x86_cpu_for_v6.11_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2024-07-16T03:25:16Z

Pull x86 cpu model updates from Borislav Petkov: - Flip the logic to add feature names to /proc/cpuinfo to having to explicitly specify the flag if there's a valid reason to show it in /proc/cpuinfo - Switch a bunch of Intel x86 model checking code to the new CPU model defines - Fixes and cleanups * tag 'x86_cpu_for_v6.11_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/cpu/intel: Drop stray FAM6 check with new Intel CPU model defines x86/cpufeatures: Flip the /proc/cpuinfo appearance logic x86/CPU/AMD: Always inline amd_clear_divider() x86/mce/inject: Add missing MODULE_DESCRIPTION() line perf/x86/rapl: Switch to new Intel CPU model defines x86/boot: Switch to new Intel CPU model defines x86/cpu: Switch to new Intel CPU model defines perf/x86/intel: Switch to new Intel CPU model defines x86/virt/tdx: Switch to new Intel CPU model defines x86/PCI: Switch to new Intel CPU model defines x86/cpu/intel: Switch to new Intel CPU model defines x86/platform/intel-mid: Switch to new Intel CPU model defines x86/pconfig: Remove unused MKTME pconfig code x86/cpu: Remove useless work in detect_tme_early()

Merge tag 'x86_misc_for_v6.11_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2024-07-16T02:53:07Z

Pull misc x86 updates from Borislav Petkov: - Make error checking of AMD SMN accesses more robust in the callers as they're the only ones who can interpret the results properly - The usual cleanups and fixes, left and right * tag 'x86_misc_for_v6.11_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/kmsan: Fix hook for unaligned accesses x86/platform/iosf_mbi: Convert PCIBIOS_* return codes to errnos x86/pci/xen: Fix PCIBIOS_* return code handling x86/pci/intel_mid_pci: Fix PCIBIOS_* return code handling x86/of: Return consistent error type from x86_of_pci_irq_enable() hwmon: (k10temp) Rename _data variable hwmon: (k10temp) Remove unused HAVE_TDIE() macro hwmon: (k10temp) Reduce k10temp_get_ccd_support() parameters hwmon: (k10temp) Define a helper function to read CCD temperature x86/amd_nb: Enhance SMN access error checking hwmon: (k10temp) Check return value of amd_smn_read() EDAC/amd64: Check return value of amd_smn_read() EDAC/amd64: Remove unused register accesses tools/x86/kcpuid: Add missing dir via Makefile x86, arm: Add missing license tag to syscall tables files

x86/efi: Drop support for fake EFI memory maps

2024-07-01T22:26:24Z

Between kexec and confidential VM support, handling the EFI memory maps correctly on x86 is already proving to be rather difficult (as opposed to other EFI architectures which manage to never modify the EFI memory map to begin with) EFI fake memory map support is essentially a development hack (for testing new support for the 'special purpose' and 'more reliable' EFI memory attributes) that leaked into production code. The regions marked in this manner are not actually recognized as such by the firmware itself or the EFI stub (and never have), and marking memory as 'more reliable' seems rather futile if the underlying memory is just ordinary RAM. Marking memory as 'special purpose' in this way is also dubious, but may be in use in production code nonetheless. However, the same should be achievable by using the memmap= command line option with the ! operator. EFI fake memmap support is not enabled by any of the major distros (Debian, Fedora, SUSE, Ubuntu) and does not exist on other architectures, so let's drop support for it. Acked-by: Borislav Petkov (AMD) Acked-by: Dan Williams Signed-off-by: Ard Biesheuvel

x86/platform/iosf_mbi: Convert PCIBIOS_* return codes to errnos

2024-06-24T17:28:18Z

iosf_mbi_pci_{read,write}_mdr() use pci_{read,write}_config_dword() that return PCIBIOS_* codes but functions also return -ENODEV which are not compatible error codes. As neither of the functions are related to PCI read/write functions, they should return normal errnos. Convert PCIBIOS_* returns code using pcibios_err_to_errno() into normal errno before returning it. Fixes: 46184415368a ("arch: x86: New MailBox support driver for Intel SOC's") Signed-off-by: Ilpo Järvinen Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/r/20240527125538.13620-4-ilpo.jarvinen@linux.intel.com

efi/x86: Free EFI memory map only when installing a new one.

2024-06-15T08:25:02Z

The logic in __efi_memmap_init() is shared between two different execution flows: - mapping the EFI memory map early or late into the kernel VA space, so that its entries can be accessed; - the x86 specific cloning of the EFI memory map in order to insert new entries that are created as a result of making a memory reservation via a call to efi_mem_reserve(). In the former case, the underlying memory containing the kernel's view of the EFI memory map (which may be heavily modified by the kernel itself on x86) is not modified at all, and the only thing that changes is the virtual mapping of this memory, which is different between early and late boot. In the latter case, an entirely new allocation is created that carries a new, updated version of the kernel's view of the EFI memory map. When installing this new version, the old version will no longer be referenced, and if the memory was allocated by the kernel, it will leak unless it gets freed. The logic that implements this freeing currently lives on the code path that is shared between these two use cases, but it should only apply to the latter. So move it to the correct spot. While at it, drop the dummy definition for non-x86 architectures, as that is no longer needed. Cc: Fixes: f0ef6523475f ("efi: Fix efi_memmap_alloc() leaks") Tested-by: Ashish Kalra Link: https://lore.kernel.org/all/36ad5079-4326-45ed-85f6-928ff76483d3@amd.com Signed-off-by: Ard Biesheuvel

x86/platform/atom: Switch to new Intel CPU model defines

2024-06-03T06:49:00Z

New CPU #defines encode vendor and family as well as model. Signed-off-by: Tony Luck Link: https://lore.kernel.org/r/20240531203706.233365-4-tony.luck@intel.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen