summaryrefslogtreecommitdiff
path: root/drivers/acpi
AgeCommit message (Collapse)Author
2024-07-02ACPI: CPPC: Replace ternary operator with umax()Prabhakar Pujeri
Replace ternary operator with umax() in cppc_find_dmi_mhz(). Signed-off-by: Prabhakar Pujeri <prabhakar.pujeri@gmail.com> [ rjw: Subject and changelog edits ] Link: https://patch.msgid.link/20240626130941.1527127-2-prabhakar.pujeri@gmail.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-07-02ACPI: resource: Skip IRQ override on Asus Vivobook Pro N6506MUTamim Khan
Like various other Asus laptops, the Asus Vivobook Pro N6506MV has a DSDT table that describes IRQ 1 as ActiveLow while the kernel is overriding it to Edge_High. This prevents the internal keyboard from working. This patch prevents this issue by adding this laptop to the override table that prevents the kernel from overriding this IRQ Link: https://bugzilla.kernel.org/show_bug.cgi?id=218954 Tested-by: Lefteris <eleftherios.giapitzakis@gmail.com> Signed-off-by: Tamim Khan <tamim@fusetak.com> Link: https://patch.msgid.link/20240702125918.34683-1-tamim@fusetak.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-07-02ACPI: processor_idle: Fix invalid comparison with insertion sort for latencyKuan-Wei Chiu
The acpi_cst_latency_cmp() comparison function currently used for sorting C-state latencies does not satisfy transitivity, causing incorrect sorting results. Specifically, if there are two valid acpi_processor_cx elements A and B and one invalid element C, it may occur that A < B, A = C, and B = C. Sorting algorithms assume that if A < B and A = C, then C < B, leading to incorrect ordering. Given the small size of the array (<=8), we replace the library sort function with a simple insertion sort that properly ignores invalid elements and sorts valid ones based on latency. This change ensures correct ordering of the C-state latencies. Fixes: 65ea8f2c6e23 ("ACPI: processor idle: Fix up C-state latency if not ordered") Reported-by: Julian Sikorski <belegdol@gmail.com> Closes: https://lore.kernel.org/lkml/70674dc7-5586-4183-8953-8095567e73df@gmail.com Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com> Tested-by: Julian Sikorski <belegdol@gmail.com> Cc: All applicable <stable@vger.kernel.org> Link: https://patch.msgid.link/20240701205639.117194-1-visitorckw@gmail.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-07-01ACPI: PMIC: Constify struct pmic_tableChristophe JAILLET
'struct pmic_table' is not modified in these drivers. Constifying this structure moves some data to a read-only section, so increase overall security. On a x86_64, with allmodconfig, as an example: Before: ====== text data bss dec hex filename 3811 786 0 4597 11f5 drivers/acpi/pmic/intel_pmic_xpower.o text data bss dec hex filename 4147 450 0 4597 11f5 drivers/acpi/pmic/intel_pmic_xpower.o Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://patch.msgid.link/a6c9b1bcdf259adabbcaf91183d3f5ab87a98600.1719644292.git.christophe.jaillet@wanadoo.fr Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-07-01ACPI: bus: Indicate support for battery charge limiting thru _OSCArmin Wolf
The ACPI battery driver can handle the "charge limiting" state of the battery, so the platform can advertise this state. Indicate this by setting bit 19 ("Battery Charge Limiting Support") when evaluating _OSC. Tested on a Lenovo Ideapad S145-14IWL. Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://patch.msgid.link/20240620191410.3646-2-W_Armin@gmx.de Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-07-01ACPI: battery: Add support for charge limiting stateArmin Wolf
The ACPI specification says that bit 3 inside the battery state signals that the battery is in charge limiting state. In this state, the platform limits the battery from reaching its full capacity, the exact limit is platform-specific. This might explain why a number of batteries reported a "Unknown" battery state in the past when using platform-specific interfaces to stop battery charging at a user defined level. Unfortunately not all platforms set this bit in such cases, so "non-charging" is still the default state when the battery is neither charging, discharging or full. Tested on a Lenovo Ideapad S145-14IWL. Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://patch.msgid.link/20240620191410.3646-1-W_Armin@gmx.de Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-07-01ACPI: battery: add devm_battery_hook_register()Thomas Weißschuh
Add a utility function for device-managed registration of battery hooks. The function makes it easier to manage the lifecycle of a hook. Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20240630-cros_ec-charge-control-v5-1-8f649d018c52@weissschuh.net Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
2024-06-28irqchip/gic-v3: Add support for ACPI's disabled but 'online capable' CPUsJames Morse
To support virtual CPU hotplug, ACPI has added an 'online capable' bit to the MADT GICC entries. This indicates a disabled CPU entry may not be possible to online via PSCI until firmware has set enabled bit in _STA. This means that a "usable" GIC redistributor is one that is marked as either enabled, or online capable. The meaning of the acpi_gicc_is_usable() would become less clear than just checking the pair of flags at call sites. As such, drop that helper function. The test in gic_acpi_match_gicc() remains as testing just the enabled bit so the count of enabled distributors is correct. What about the redistributor in the GICC entry? ACPI doesn't want to say. Assume the worst: When a redistributor is described in the GICC entry, but the entry is marked as disabled at boot, assume the redistributor is inaccessible. The GICv3 driver doesn't support late online of redistributors, so this means the corresponding CPU can't be brought online either. Rather than modifying cpu masks that may already have been used, register a new cpuhp callback to fail this case. This must run earlier than the main gic_starting_cpu() so that this case can be rejected before the section of cpuhp that runs on the CPU that is coming up as that is not allowed to fail. This solution keeps the handling of this broken firmware corner case local to the GIC driver. As precise ordering of this callback doesn't need to be controlled as long as it is in that initial prepare phase, use CPUHP_BP_PREPARE_DYN. Systems that want CPU hotplug in a VM can ensure their redistributors are always-on, and describe them that way with a GICR entry in the MADT. Suggested-by: Marc Zyngier <maz@kernel.org> Signed-off-by: James Morse <james.morse@arm.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Tested-by: Miguel Luis <miguel.luis@oracle.com> Co-developed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20240529133446.28446-15-Jonathan.Cameron@huawei.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2024-06-28ACPI: Add post_eject to struct acpi_scan_handler for cpu hotplugJames Morse
struct acpi_scan_handler has a detach callback that is used to remove a driver when a bus is changed. When interacting with an eject-request, the detach callback is called before _EJ0. This means the ACPI processor driver can't use _STA to determine if a CPU has been made not-present, or some of the other _STA bits have been changed. acpi_processor_remove() needs to know the value of _STA after _EJ0 has been called. Add a post_eject callback to struct acpi_scan_handler. This is called after acpi_scan_hot_remove() has successfully called _EJ0. Because acpi_scan_check_and_detach() also clears the handler pointer, it needs to be told if the caller will go on to call acpi_bus_post_eject(), so that acpi_device_clear_enumerated() and clearing the handler pointer can be deferred. An extra flag is added to flags field introduced in the previous patch to achieve this. Signed-off-by: James Morse <james.morse@arm.com> Reviewed-by: Gavin Shan <gshan@redhat.com> Tested-by: Miguel Luis <miguel.luis@oracle.com> Tested-by: Vishnu Pajjuri <vishnu@os.amperecomputing.com> Tested-by: Jianyong Wu <jianyong.wu@arm.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Hanjun Guo <guohanjun@huawei.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/20240529133446.28446-11-Jonathan.Cameron@huawei.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2024-06-28ACPI: scan: switch to flags for acpi_scan_check_and_detach()Jonathan Cameron
Precursor patch adds the ability to pass a uintptr_t of flags into acpi_scan_check_and detach() so that additional flags can be added to indicate whether to defer portions of the eject flow. The new flag follows in the next patch. Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Hanjun Guo <guohanjun@huawei.com> Reviewed-by: Gavin Shan <gshan@redhat.com> Tested-by: Miguel Luis <miguel.luis@oracle.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/20240529133446.28446-10-Jonathan.Cameron@huawei.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2024-06-28ACPI: processor: Register deferred CPUs from acpi_processor_get_info()James Morse
The arm64 specific arch_register_cpu() call may defer CPU registration until the ACPI interpreter is available and the _STA method can be evaluated. If this occurs, then a second attempt is made in acpi_processor_get_info(). Note that the arm64 specific call has not yet been added so for now this will be called for the original hotplug case. For architectures that do not defer until the ACPI Processor driver loads (e.g. x86), for initially present CPUs there will already be a CPU device. If present do not try to register again. Systems can still be booted with 'acpi=off', or not include an ACPI description at all as in these cases arch_register_cpu() will not have deferred registration when first called. This moves the CPU register logic back to a subsys_initcall(), while the memory nodes will have been registered earlier. Note this is where the call was prior to the cleanup series so there should be no side effects of moving it back again for this specific case. [PATCH 00/21] Initial cleanups for vCPU HP. https://lore.kernel.org/all/ZVyz%2FVe5pPu8AWoA@shell.armlinux.org.uk/ commit 5b95f94c3b9f ("x86/topology: Switch over to GENERIC_CPU_DEVICES") Signed-off-by: James Morse <james.morse@arm.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Gavin Shan <gshan@redhat.com> Tested-by: Miguel Luis <miguel.luis@oracle.com> Tested-by: Vishnu Pajjuri <vishnu@os.amperecomputing.com> Tested-by: Jianyong Wu <jianyong.wu@arm.com> Reviewed-by: Hanjun Guo <guohanjun@huawei.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Co-developed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/20240529133446.28446-9-Jonathan.Cameron@huawei.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2024-06-28ACPI: processor: Add acpi_get_processor_handle() helperJonathan Cameron
If CONFIG_ACPI_PROCESSOR provide a helper to retrieve the acpi_handle for a given CPU allowing access to methods in DSDT. Tested-by: Miguel Luis <miguel.luis@oracle.com> Reviewed-by: Gavin Shan <gshan@redhat.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/20240529133446.28446-8-Jonathan.Cameron@huawei.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2024-06-28ACPI: processor: Move checks and availability of acpi_processor earlierJonathan Cameron
Make the per_cpu(processors, cpu) entries available earlier so that they are available in arch_register_cpu() as ARM64 will need access to the acpi_handle to distinguish between acpi_processor_add() and earlier registration attempts (which will fail as _STA cannot be checked). Reorder the remove flow to clear this per_cpu() after arch_unregister_cpu() has completed, allowing it to be used in there as well. Note that on x86 for the CPU hotplug case, the pr->id prior to acpi_map_cpu() may be invalid. Thus the per_cpu() structures must be initialized after that call or after checking the ID is valid (not hotplug path). Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Gavin Shan <gshan@redhat.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/20240529133446.28446-7-Jonathan.Cameron@huawei.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2024-06-28ACPI: processor: Fix memory leaks in error paths of processor_add()Jonathan Cameron
If acpi_processor_get_info() returned an error, pr and the associated pr->throttling.shared_cpu_map were leaked. The unwind code was in the wrong order wrt to setup, relying on some unwind actions having no affect (clearing variables that were never set etc). That makes it harder to reason about so reorder and add appropriate labels to only undo what was actually set up in the first place. Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Gavin Shan <gshan@redhat.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/20240529133446.28446-6-Jonathan.Cameron@huawei.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2024-06-28ACPI: processor: Return an error if acpi_processor_get_info() fails in ↵Jonathan Cameron
processor_add() Rafael observed [1] that returning 0 from processor_add() will result in acpi_default_enumeration() being called which will attempt to create a platform device, but that makes little sense when the processor is known to be not available. So just return the error code from acpi_processor_get_info() instead. Link: https://lore.kernel.org/all/CAJZ5v0iKU8ra9jR+EmgxbuNm=Uwx2m1-8vn_RAZ+aCiUVLe3Pw@mail.gmail.com/ [1] Suggested-by: Rafael J. Wysocki <rafael@kernel.org> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Gavin Shan <gshan@redhat.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/20240529133446.28446-5-Jonathan.Cameron@huawei.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2024-06-28ACPI: processor: Drop duplicated check on _STA (enabled + present)Jonathan Cameron
The ACPI bus scan will only result in acpi_processor_add() being called if _STA has already been checked and the result is that the processor is enabled and present. Hence drop this additional check. Suggested-by: Rafael J. Wysocki <rafael@kernel.org> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Hanjun Guo <guohanjun@huawei.com> Reviewed-by: Gavin Shan <gshan@redhat.com> Tested-by: Miguel Luis <miguel.luis@oracle.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/20240529133446.28446-4-Jonathan.Cameron@huawei.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2024-06-28ACPI: processor: Simplify initial onlining to use same path for cold and hotplugJonathan Cameron
Separate code paths, combined with a flag set in acpi_processor.c to indicate a struct acpi_processor was for a hotplugged CPU ensured that per CPU data was only set up the first time that a CPU was initialized. This appears to be unnecessary as the paths can be combined by letting the online logic also handle any CPUs online at the time of driver load. Motivation for this change, beyond simplification, is that ARM64 virtual CPU HP uses the same code paths for hotplug and cold path in acpi_processor.c so had no easy way to set the flag for hotplug only. Removing this necessity will enable ARM64 vCPU HP to reuse the existing code paths. Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Hanjun Guo <guohanjun@huawei.com> Tested-by: Miguel Luis <miguel.luis@oracle.com> Reviewed-by: Gavin Shan <gshan@redhat.com> Reviewed-by: Miguel Luis <miguel.luis@oracle.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/20240529133446.28446-2-Jonathan.Cameron@huawei.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2024-06-24ACPI / amba: Drop unnecessary check for registered amba_dummy_clkYouwan Wang
amba_register_dummy_clk() is called only once from acpi_amba_init() and acpi_amba_init() itself is called once during the initialisation. amba_dummy_clk can't be initialised before this in any other code path and hence the check for already registered amba_dummy_clk is not necessary. Drop the same. Signed-off-by: Youwan Wang <youwan@nfschina.com> Acked-by: Sudeep Holla <sudeep.holla@arm.com> Acked-by: Hanjun Guo <guohanjun@huawei.com> Link: https://lore.kernel.org/r/20240624023101.369633-1-youwan@nfschina.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2024-06-21Merge branch 'acpi-scan'Rafael J. Wysocki
Merge ACPI device enumeration fixes for 6.10-rc5: - Ignore MIPI camera graph port nodes created with the help of the information from the ACPI tables on all Dell Tiger, Alder and Raptor Lake models as that information is reported to be invalid on the systems in question (Hans de Goede). - Use new Intel CPU model matching macros in the MIPI DisCo for Imaging part of ACPI device enumeration (Hans de Goede). * acpi-scan: ACPI: mipi-disco-img: Switch to new Intel CPU model defines ACPI: scan: Ignore camera graph port nodes on all Dell Tiger, Alder and Raptor Lake models
2024-06-19ACPI: processor: Downgrade Intel _OSC and _PDC messages to debugMario Limonciello
Commit 95272641338a ("ACPI: processor: Use _OSC to convey OSPM processor support information") introduced messages related to determining processor support from the firmware. The UUID 4077A616-290C-47BE-9EBD-D87058713953 and _PDC methods are only used on Intel platforms, but all X86 platforms emit the messages. Attempting to evaluate them and showing messages on which are used is unnecessary for most users. Downgrade the messages to debug instead. Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://patch.msgid.link/20240618214225.50953-1-mario.limonciello@amd.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-06-17ACPI: NFIT: add missing MODULE_DESCRIPTION() macroJeff Johnson
make allmodconfig && make W=1 C=1 reports: WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/acpi/nfit/nfit.o Add the missing invocation of the MODULE_DESCRIPTION() macro. [iweiny: edit description] Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Link: https://patch.msgid.link/r/20240603-md-drivers-acpi-nfit-v1-1-11a5614a8dbe@quicinc.com Signed-off-by: Ira Weiny <ira.weiny@intel.com>
2024-06-17ACPI: mipi-disco-img: Switch to new Intel CPU model definesHans de Goede
Switch over to using the new Intel CPU model defines, as the old ones are going away. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-06-17ACPI: scan: Ignore camera graph port nodes on all Dell Tiger, Alder and ↵Hans de Goede
Raptor Lake models Dell laptops with IPU6 camera (the Tiger Lake, Alder Lake and Raptor Lake generations) have broken ACPI MIPI DISCO information (this results from an OEM attempt to make Linux work by supplying it with custom data in the ACPI tables which has never been supported in the mainline). Instead of adding a lot of DMI quirks for this, check for Dell platforms based on the processor generations in question and drop the ACPI graph port nodes, likely to be created with the help of invalid data, on all of them. Fixes: bd721b934323 ("ACPI: scan: Extract CSI-2 connection graph from _CRS") Signed-off-by: Hans de Goede <hdegoede@redhat.com> [ rjw: Changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-06-17ACPICA: Revert "ACPICA: avoid Info: mapping multiple BARs. Your kernel is fine."Raju Rangoju
Undo the modifications made in commit d410ee5109a1 ("ACPICA: avoid "Info: mapping multiple BARs. Your kernel is fine.""). The initial purpose of this commit was to stop memory mappings for operation regions from overlapping page boundaries, as it can trigger warnings if different page attributes are present. However, it was found that when this situation arises, mapping continues until the boundary's end, but there is still an attempt to read/write the entire length of the map, leading to a NULL pointer deference. For example, if a four-byte mapping request is made but only one byte is mapped because it hits the current page boundary's end, a four-byte read/write attempt is still made, resulting in a NULL pointer deference. Instead, map the entire length, as the ACPI specification does not mandate that it must be within the same page boundary. It is permissible for it to be mapped across different regions. Link: https://github.com/acpica/acpica/pull/954 Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218849 Fixes: d410ee5109a1 ("ACPICA: avoid "Info: mapping multiple BARs. Your kernel is fine."") Co-developed-by: Sanath S <Sanath.S@amd.com> Signed-off-by: Sanath S <Sanath.S@amd.com> Signed-off-by: Raju Rangoju <Raju.Rangoju@amd.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-06-17ACPI: tables: Print MULTIPROC_WAKEUP when MADT is parsedKirill A. Shutemov
When MADT is parsed, print MULTIPROC_WAKEUP information: ACPI: MP Wakeup (version[1], mailbox[0x7fffd000], reset[0x7fffe068]) This debug information will be very helpful during bringup. Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Baoquan He <bhe@redhat.com> Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Acked-by: Kai Huang <kai.huang@intel.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Tao Liu <ltao@redhat.com> Link: https://lore.kernel.org/r/20240614095904.1345461-20-kirill.shutemov@linux.intel.com
2024-06-15ASoC: codecs: lpass: add support for v2.5 rx macroMark Brown
Merge series from Srinivas Kandagatla <srinivas.kandagatla@linaro.org>: This patchset adds support to reading codec version and also adds support for v2.5 codec version in rx macro. LPASS 2.5 and up versions have changes in some of the rx blocks which are required to get headset functional correctly. Tested this on SM8450, X13s and x1e80100 crd. This changes also fixes issue with sm8450, sm8550, sm8660 and x1e80100.
2024-06-14Merge tag 'acpi-6.10-rc4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull ACPI fixes from Rafael Wysocki: "These fix a recent regression in the ACPI EC driver and make system suspend work on multiple platforms where StorageD3Enable _DSD is missing in the ACPI tables. Specifics: - Make the ACPI EC driver directly evaluate an "orphan" _REG method under the EC device, if present, which stopped being evaluated after the driver had started to install its EC address space handler at the root of the ACPI namespace (Rafael Wysocki) - Make more devices put NVMe storage devices into D3 at suspend to work around missing StorageD3Enable _DSD in the BIOS (Mario Limonciello)" * tag 'acpi-6.10-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: ACPI: EC: Evaluate orphan _REG under EC device ACPI: x86: Force StorageD3Enable on more products
2024-06-14Merge tag 'thermal-6.10-rc4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull thermal control fixes from Rafael Wysocki: "These fix three issues introduced recently, two related to defects in ACPI tables supplied by the platform firmware and one cause by a thermal core change that went too far: - Prevent the thermal core from failing the registration of a cooling device if its .get_cur_state() reports an incorrect state to start with which may happen for fans handled through firmware-supplied AML in ACPI tables (Rafael Wysocki) - Make the ACPI thermal zone driver initialize all trip points with temperature of 0 centigrade and below as invalid because such trip point temperatures do not make sense on systems with ACPI thermal control and they cause performance regressions due to permanent thermal mitigations to occur (Rafael Wysocki) - Restore passive polling management in the Step-Wise thermal governor that uses it to ensure that all cooling devices used for thermal mitigation will go back to their initial states eventually (Rafael Wysocki)" * tag 'thermal-6.10-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: thermal: gov_step_wise: Restore passive polling management thermal: ACPI: Invalidate trip points with temperature of 0 or below thermal: core: Do not fail cdev registration because of invalid initial state
2024-06-14Merge branch acpi-x86Rafael J. Wysocki
Merge a fix for a suspend issue related to storage handling on multiple systems based on AMD hardware: - Make more devices put NVMe storage devices into D3 at suspend to work around missing StorageD3Enable _DSD in the BIOS (Mario Limonciello). * branch acpi-x86: ACPI: x86: Force StorageD3Enable on more products
2024-06-13ACPI: SBS: manage alarm sysfs attribute through psy coreThomas Weißschuh
Let the power supply core register the attribute. This ensures that the attribute is created before the device is announced to userspace, avoiding a race condition. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-06-13ACPI: battery: create alarm sysfs attribute atomicallyThomas Weißschuh
Let the power supply core register the attribute. This ensures that the attribute is created before the device is announced to userspace, avoid a race condition. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-06-13ACPI: battery: use sysfs_emit over sprintfThomas Weißschuh
sysfs_emit validates assumptions made by sysfs and is the correct mechanism to format data for sysfs. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-06-13ACPI: battery: constify powersupply propertiesThomas Weißschuh
The arrays are never modified, make them const. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-06-13ACPI: SBS: constify powersupply propertiesThomas Weißschuh
The arrays are never modified, make them const. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-06-13ACPI: AC: constify powersupply propertiesThomas Weißschuh
The array is never modified, make it const. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-06-13ACPI: PMIC: Replace open coded be16_to_cpu()Andy Shevchenko
It's easier to understand the nature of a data type when it's written explicitly. With that, replace open coded endianess conversion. As a side effect it fixes the returned value of intel_crc_pmic_update_aux() since ACPI PMIC core code expects negative or zero and never uses positive one. While at it, use macros from bits.h to reduce a room for mistake. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-06-13ACPI: PMIC: Convert pr_*() to dev_*() printing macrosAndy Shevchenko
Since we have a device pointer in the regmap, use it for error messages. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-06-13ACPI: PMIC: Use sizeof() instead of hard coded valueAndy Shevchenko
It's better to use sizeof() of a given buffer than spreading a hard coded value. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-06-13ACPI: CPPC: add sysfs entry for guaranteed performancePetr Tesařík
Expose the CPPC guaranteed performance as reported by the platform through GuaranteedPerformanceRegister. The current value is already read in cppc_get_perf_caps() and stored in struct cppc_perf_caps (to be used by the intel_pstate driver), so only the attribute itself needs to be defined. Signed-off-by: Petr Tesařík <ptesarik@suse.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-06-13ACPI: HMAT: Use ACCESS_COORDINATE_CPU when appropriateHuang Ying
To improve the readability of the code via replacing the magic number "1" with ACCESS_COORDINATE_CPU when appropriate. No functionality change. Signed-off-by: "Huang, Ying" <ying.huang@intel.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-06-13ACPI: add missing MODULE_DESCRIPTION() macrosJeff Johnson
make allmodconfig && make W=1 C=1 reports: WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/acpi/acpi_tad.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/acpi/platform_profile.o Add the missing invocations of the MODULE_DESCRIPTION() macro. Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-06-13ACPI: acpi_pad: Still evaluate _OST when _PUR evaluation failsArmin Wolf
The ACPI specification says that if no action was performed when processing the _PUR object, _OST should still be evaluated, albeit with a different status code. Evaluate _OST even when evaluating _PUR fails, to signal the firmware that no action was performed. Compile-tested only. Signed-off-by: Armin Wolf <W_Armin@gmx.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-06-13ACPI: x86: Switch to new Intel CPU model definesTony Luck
New CPU #defines encode vendor and family as well as model. Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-06-13ACPI: EC: Evaluate orphan _REG under EC deviceRafael J. Wysocki
After starting to install the EC address space handler at the ACPI namespace root, if there is an "orphan" _REG method in the EC device's scope, it will not be evaluated any more. This breaks EC operation regions on some systems, like Asus gu605. To address this, use a wrapper around an existing ACPICA function to look for an "orphan" _REG method in the EC device scope and evaluate it if present. Fixes: 60fa6ae6e6d0 ("ACPI: EC: Install address space handler at the namespace root") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218945 Reported-by: VitaliiT <vitaly.torshyn@gmail.com> Tested-by: VitaliiT <vitaly.torshyn@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-06-13arm64: FFH: Move ACPI specific code into drivers/acpi/arm64/Sudeep Holla
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 <sudeep.holla@arm.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Hanjun Guo <guohanjun@huawei.com> Link: https://lore.kernel.org/r/20240605131458.3341095-4-sudeep.holla@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2024-06-13arm64: cpuidle: Move ACPI specific code into drivers/acpi/arm64/Sudeep Holla
The ACPI cpuidle LPI FFH code can be moved out of arm64 arch code as it just uses SMCCC. Move all the ACPI cpuidle LPI FFH code into drivers/acpi/arm64/cpuidle.c Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Hanjun Guo <guohanjun@huawei.com> Link: https://lore.kernel.org/r/20240605131458.3341095-3-sudeep.holla@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2024-06-13ACPI: arm64: Sort entries alphabeticallySudeep Holla
Sort the entries in the Makefile alphabetically. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Acked-by: Hanjun Guo <guohanjun@huawei.com> Link: https://lore.kernel.org/r/20240605131458.3341095-2-sudeep.holla@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2024-06-10ACPI: utils: introduce acpi_get_local_u64_address()Pierre-Louis Bossart
The ACPI _ADR is a 64-bit value. We changed the definitions in commit ca6f998cf9a2 ("ACPI: bus: change _ADR representation to 64 bits") but some helpers still assume the value is a 32-bit value. This patch adds a new helper to extract the full 64-bits. The existing 32-bit helper is kept for backwards-compatibility and cases where the _ADR is known to fit in a 32-bit value. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Takashi Iwai <tiwai@suse.de> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20240528192936.16180-2-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-06-07ACPI: LPSS: Switch to new Intel CPU model definesTony Luck
New CPU #defines encode vendor and family as well as model. Signed-off-by: Tony Luck <tony.luck@intel.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-06-07ACPI: x86: Force StorageD3Enable on more productsMario Limonciello
A Rembrandt-based HP thin client is reported to have problems where the NVME disk isn't present after resume from s2idle. This is because the NVME disk wasn't put into D3 at suspend, and that happened because the StorageD3Enable _DSD was missing in the BIOS. As AMD's architecture requires that the NVME is in D3 for s2idle, adjust the criteria for force_storage_d3 to match *all* Zen SoCs when the FADT advertises low power idle support. This will ensure that any future products with this BIOS deficiency don't need to be added to the allow list of overrides. Cc: All applicable <stable@vger.kernel.org> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
generated by cgit (git 2.34.1) at 2025-07-18 21:13:51 +0000