kernel.git/arch/arm64/kernel/acpi.c, branch linux-6.15.y

ACPI: Suppress misleading SPCR console message when SPCR table is absent

2025-08-20T16:36:09Z

[ Upstream commit bad3fa2fb9206f4dcec6ddef094ec2fbf6e8dcb2 ] The kernel currently alway prints: "Use ACPI SPCR as default console: No/Yes " even on systems that lack an SPCR table. This can mislead users into thinking the SPCR table exists on the machines without SPCR. With this change, the "Yes" is only printed if the SPCR table is present, parsed and !param_acpi_nospcr. This avoids user confusion on SPCR-less systems. Signed-off-by: Li Chen Acked-by: Hanjun Guo Link: https://lore.kernel.org/r/20250620131309.126555-3-me@linux.beauty Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin

mm/ioremap: pass pgprot_t to ioremap_prot() instead of unsigned long

2025-03-17T05:06:23Z

ioremap_prot() currently accepts pgprot_val parameter as an unsigned long, thus implicitly assuming that pgprot_val and pgprot_t could never be bigger than unsigned long. But this assumption soon will not be true on arm64 when using D128 pgtables. In 128 bit page table configuration, unsigned long is 64 bit, but pgprot_t is 128 bit. Passing platform abstracted pgprot_t argument is better as compared to size based data types. Let's change the parameter to directly pass pgprot_t like another similar helper generic_ioremap_prot(). Without this change in place, D128 configuration does not work on arm64 as the top 64 bits gets silently stripped when passing the protection value to this function. Link: https://lkml.kernel.org/r/20250218101954.415331-1-anshuman.khandual@arm.com Signed-off-by: Ryan Roberts Co-developed-by: Anshuman Khandual Signed-off-by: Anshuman Khandual Acked-by: Catalin Marinas [arm64] Signed-off-by: Andrew Morton

Merge branch 'for-next/vcpu-hotplug' into for-next/core

2024-07-11T18:10:02Z

* for-next/vcpu-hotplug: (21 commits) : arm64 support for virtual CPU hotplug (ACPI) irqchip/gic-v3: Fix 'broken_rdists' unused warning when !SMP and !ACPI arm64: Kconfig: Fix dependencies to enable ACPI_HOTPLUG_CPU cpumask: Add enabled cpumask for present CPUs that can be brought online arm64: document virtual CPU hotplug's expectations arm64: Kconfig: Enable hotplug CPU on arm64 if ACPI_PROCESSOR is enabled. arm64: arch_register_cpu() variant to check if an ACPI handle is now available. arm64: psci: Ignore DENIED CPUs irqchip/gic-v3: Add support for ACPI's disabled but 'online capable' CPUs irqchip/gic-v3: Don't return errors from gic_acpi_match_gicc() arm64: acpi: Harden get_cpu_for_acpi_id() against missing CPU entry arm64: acpi: Move get_cpu_for_acpi_id() to a header ACPI: Add post_eject to struct acpi_scan_handler for cpu hotplug ACPI: scan: switch to flags for acpi_scan_check_and_detach() ACPI: processor: Register deferred CPUs from acpi_processor_get_info() ACPI: processor: Add acpi_get_processor_handle() helper ACPI: processor: Move checks and availability of acpi_processor earlier ACPI: processor: Fix memory leaks in error paths of processor_add() ACPI: processor: Return an error if acpi_processor_get_info() fails in processor_add() ACPI: processor: Drop duplicated check on _STA (enabled + present) cpu: Do not warn on arch_register_cpu() returning -EPROBE_DEFER ...

ACPI: Add acpi=nospcr to disable ACPI SPCR as default console on ARM64

2024-07-04T15:33:13Z

For varying privacy and security reasons, sometimes we would like to completely silence the _serial_ console, and only enable it when needed. But there are many existing systems that depend on this _serial_ console, so add acpi=nospcr to disable console in ACPI SPCR table as default _serial_ console. Signed-off-by: Liu Wei Suggested-by: Prarit Bhargava Suggested-by: Will Deacon Suggested-by: Andrew Lunn Reviewed-by: Hanjun Guo Reviewed-by: Prarit Bhargava Link: https://lore.kernel.org/r/20240625030504.58025-1-liuwei09@cestc.cn Signed-off-by: Catalin Marinas

arm64: Kconfig: Enable hotplug CPU on arm64 if ACPI_PROCESSOR is enabled.

2024-06-28T17:38:32Z

In order to move arch_register_cpu() to be called via the same path for initially present CPUs described by ACPI and hotplugged CPUs ACPI_HOTPLUG_CPU needs to be enabled. The protection against invalid IDs in acpi_map_cpu() is needed as at least one production BIOS is in the wild which reports entries in DSDT (with no _STA method, so assumed enabled and present) that don't match MADT. Tested-by: Miguel Luis Reviewed-by: Gavin Shan Signed-off-by: Jonathan Cameron Link: https://lore.kernel.org/r/20240529133446.28446-18-Jonathan.Cameron@huawei.com Signed-off-by: Catalin Marinas

arm64: FFH: Move ACPI specific code into drivers/acpi/arm64/

2024-06-13T09:18:40Z

The ACPI FFH Opregion code can be moved out of arm64 arch code as it just uses SMCCC. Move all the ACPI FFH Opregion code into drivers/acpi/arm64/ffh.c Signed-off-by: Sudeep Holla Acked-by: Catalin Marinas Acked-by: Hanjun Guo Link: https://lore.kernel.org/r/20240605131458.3341095-4-sudeep.holla@arm.com Signed-off-by: Catalin Marinas

arm64: acpi: Honour firmware_signature field of FACS, if it exists

2024-04-18T15:17:33Z

If the firmware_signature changes then OSPM should not attempt to resume from hibernate, but should instead perform a clean reboot. Set the global swsusp_hardware_signature to allow the generic code to include the value in the swsusp header on disk, and perform the appropriate check on resume. Signed-off-by: David Woodhouse Acked-by: Sudeep Holla Acked-by: Rafael J. Wysocki Link: https://lore.kernel.org/r/20240412073530.2222496-3-dwmw2@infradead.org Signed-off-by: Will Deacon

arm64: acpi: Fix possible memory leak of ffh_ctxt

2023-02-24T14:21:49Z

Allocated 'ffh_ctxt' memory leak is possible if the SMCCC version and conduit checks fail and -EOPNOTSUPP is returned without freeing the allocated memory. Fix the same by moving the allocation after the SMCCC version and conduit checks. Fixes: 1d280ce099db ("arm64: Add architecture specific ACPI FFH Opregion callbacks") Cc: # 6.2.x Cc: Will Deacon Reported-by: kernel test robot Reported-by: Dan Carpenter Suggested-by: Dan Carpenter Link: https://lore.kernel.org/r/202302191417.dAl9NuE8-lkp@intel.com/ Signed-off-by: Sudeep Holla Link: https://lore.kernel.org/r/20230223135742.2952091-1-sudeep.holla@arm.com Signed-off-by: Catalin Marinas

arm64: Add architecture specific ACPI FFH Opregion callbacks

2022-11-14T18:09:07Z

FFH Operation Region space can be used to trigger SMC or HVC calls, using the Arm SMC Calling Convention (SMCCC). The choice of conduit (SMC or HVC) is based on what the kernel choose based on PSCI as with any other users of SMCCC within the kernel. Function identifiers only in the SMCCC SiP Service, OEM Service and FF-A specific call range are allowed in FFH Opregions. Offset can be either 0(32 bit calling convention) or 1(64 bit calling convention). The length must be set with the range applicable based on the value of the offset. Acked-by: Catalin Marinas Cc: Will Deacon Signed-off-by: Sudeep Holla Signed-off-by: Rafael J. Wysocki

arm64: mm: Convert to GENERIC_IOREMAP

2022-06-27T11:22:31Z

Add hook for arm64's special operation when ioremap(), then ioremap_wc/np/cache is converted to use ioremap_prot() from GENERIC_IOREMAP, update the Copyright and kill the unused inclusions. Reviewed-by: Anshuman Khandual Acked-by: Catalin Marinas Signed-off-by: Kefeng Wang Link: https://lore.kernel.org/r/20220607125027.44946-6-wangkefeng.wang@huawei.com Signed-off-by: Will Deacon