summaryrefslogtreecommitdiff
path: root/drivers/acpi
AgeCommit message (Collapse)Author
2026-01-09ACPI: processor: idle: Redefine two functions as voidRafael J. Wysocki
Notice that acpi_processor_power_init() and acpi_processor_power_exit() don't need to return any values because their callers don't check them anyway, so redefine those functions as void. While at it, rearrange the code in acpi_processor_power_init() to reduce the indentation level, get rid of a redundant local variable in that function, and rephrase a code comment in it. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Tested-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://patch.msgid.link/20251223100914.2407069-5-lihuisong@huawei.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-01-09ACPI: processor: Update cpuidle driver check in __acpi_processor_start()Rafael J. Wysocki
Commit 7a8c994cbb2d ("ACPI: processor: idle: Optimize ACPI idle driver registration") moved the ACPI idle driver registration to acpi_processor_driver_init() and acpi_processor_power_init() does not register an idle driver any more. Accordingly, the cpuidle driver check in __acpi_processor_start() needs to be updated to avoid calling acpi_processor_power_init() without a cpuidle driver, in which case the registration of the cpuidle device in that function would lead to a NULL pointer dereference in __cpuidle_register_device(). Fixes: 7a8c994cbb2d ("ACPI: processor: idle: Optimize ACPI idle driver registration") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Tested-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://patch.msgid.link/20251223100914.2407069-4-lihuisong@huawei.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-01-09ACPI: processor: idle: Optimize ACPI idle driver registrationHuisong Li
Currently, the ACPI idle driver is registered from within a CPU hotplug callback. Although this didn't cause any functional issues, this is questionable and confusing. And it is better to register the cpuidle driver when all of the CPUs have been brought up. So add a new function to initialize acpi_idle_driver based on the power management information of an available CPU and register cpuidle driver in acpi_processor_driver_init(). This commit has four changes under the commit 7a8c994cbb2d (ACPI: processor: idle: Optimize ACPI idle driver registration): 1) move acpi_processor_register_idle_driver() ahead of the driver_register(). 2) add acpi_processor_cstate_first_run_checks() before calling acpi_processor_get_power_info(). 3) squash the commit 9d68320b2bca (ACPI: processor: idle: Fix function defined but not used warning) into this change. 4) use for_each_possible_cpu(cpu) to scan all possible cpus. Signed-off-by: Huisong Li <lihuisong@huawei.com> Tested-by: Borislav Petkov (AMD) <bp@alien8.de> [ rjw: New comment edits, changelog tweak ] Link: https://patch.msgid.link/20251223100914.2407069-2-lihuisong@huawei.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-01-08ACPI: AGDI: Add interrupt signaling mode supportKazuhiro Abe
AGDI has two types of signaling modes: SDEI and interrupt. Currently, the AGDI driver only supports SDEI. Therefore, add support for interrupt signaling mode. The interrupt vector is retrieved from the AGDI table, and call panic function when an interrupt occurs. Acked-by: Hanjun Guo <guohanjun@huawei.com> Reviewed-by: Ilkka Koskinen <ilkka@os.amperecomputing.com> Signed-off-by: Kazuhiro Abe <fj1078ii@aa.jp.fujitsu.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-01-07ACPI: APEI: EINJ: make read-only array non_mmio_desc static constColin Ian King
Don't populate the read-only array non_mmio_desc on the stack at run time, instead make it static const. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Link: https://patch.msgid.link/20251219215900.494211-1-colin.i.king@gmail.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-01-07ACPI: acpi_watchdog: use LIST_HEAD for stack-allocated listCan Peng
Replace the separate declaration of 'resource_list' and subsequent INIT_LIST_HEAD() call with LIST_HEAD(), which declares and initializes the list head in one idiomatic step. This reduces code verbosity and aligns with common kernel coding patterns, without functional change. Signed-off-by: Can Peng <pengcan@kylinos.cn> [ rjw: Subject edits ] Link: https://patch.msgid.link/20251209072757.3110467-1-pengcan@kylinos.cn Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-01-05ACPI: PCI: IRQ: Fix INTx GSIs signednessLorenzo Pieralisi
In ACPI Global System Interrupts (GSIs) are described using a 32-bit value. ACPI/PCI legacy interrupts (INTx) parsing code treats GSIs as 'int', which poses issues if the GSI interrupt value is a 32-bit value with the MSB set (as required in some interrupt configurations - eg ARM64 GICv5 systems) because acpi_pci_link_allocate_irq() treats a negative gsi return value as a failed GSI allocation (and acpi_irq_get_penalty() would trigger an out-of-bounds array dereference if the 'irq' param is a negative value). Fix ACPI/PCI legacy INTx parsing by converting variables representing GSIs from 'int' to 'u32' bringing the code in line with the ACPI specification and fixing the current parsing issue. Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Reviewed-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20260105101705.36703-1-lpieralisi@kernel.org Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-01-02ACPI: scan: Drop outdated comment regarding removed functionJulia Lawall
The function acpi_video_get_capabilities() was removed from drivers/acpi/video_detect.c by commit 87521e16a7ab ("acpi-video-detect: Rewrite backlight interface selection logic") in 2015. At the time, comments about this function were just removed, and no replacement seemed to be proposed. Drop the reference to acpi_video_get_capabilities() here as well. Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr> [ rjw: Subject adjustment, changelog edits ] Link: https://patch.msgid.link/20251230160644.100439-1-Julia.Lawall@inria.fr Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-01-02ACPI: scan: Use resource_type() for resource type checkingRafael J. Wysocki
To follow a well-established existing pattern, use resource_type() for resource type checking in acpi_scan_claim_resources(). No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Link: https://patch.msgid.link/12814730.O9o76ZdvQC@rafael.j.wysocki
2026-01-02ACPI: bus: Fix typo under sizeof() in acpi_run_osc()Rafael J. Wysocki
The sizeof(32) in acpi_run_osc() should be sizeof(u32), so fix it. Fixes: e5322888e6bf ("ACPI: bus: Rework the handling of \_SB._OSC platform features") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Link: https://patch.msgid.link/2817106.mvXUDI8C0e@rafael.j.wysocki
2026-01-02ACPI: bus: Adjust acpi_osc_handshake() parameter listRafael J. Wysocki
For the sake of interface cleanliness, it is better to avoid using ACPICA data types in the parameter lists of helper functions that don't belong to ACPICA, so adjust the parameter list of recently introduced acpi_osc_handshake() to take a capabilities buffer pointer and the size of the buffer (in u32 size units) as parameters directly instead of a struct acpi_buffer pointer. This is also somewhat more straightforward on the caller side because they won't need to create struct acpi_buffer objects themselves to pass them to the helper function and it guarantees that the size of the buffer in bytes will always be a multiple of 4 (the size of u32). Moreover, it addresses a premature cap pointer dereference and eliminates a sizeof(32) that should have been sizeof(u32) [1]. Fixes: e5322888e6bf ("ACPI: bus: Rework the handling of \_SB._OSC platform features") Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/linux-acpi/202512242052.W4GhDauV-lkp@intel.com/ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> [ rjw: Fixed typo under sizeof(), used ARRAY_SIZE() in two places ] Link: https://patch.msgid.link/12833187.O9o76ZdvQC@rafael.j.wysocki Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-12-29ACPI: sysfs: Add device cid attribute for exposing _CID listsRafael J. Wysocki
Add a new sysfs attribute called "cid" under struct acpi_device for exposing the list of compatible device IDs returned by the device's _CID object, if present. The new attribute will be present only if the _CID object is present. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/5957407.DvuYhMxLoT@rafael.j.wysocki
2025-12-29ACPI: SBS: Convert the driver to a platform oneRafael J. Wysocki
While binding drivers directly to struct acpi_device objects allows basic functionality to be provided, at least in the majority of cases, there are some problems with it, related to general consistency, sysfs layout, power management operation ordering, and code cleanliness. Overall, it is better to bind drivers to platform devices than to their ACPI companions, so convert the ACPI smart battery subsystem (SBS) driver to a platform one. After this conversion, acpi_smbus_hc_probe() does not need to populate the driver_data pointer of the SMBUS HC platform device's ACPI companion any more, so update it accordingly. While this is not expected to alter functionality, it changes sysfs layout and so it will be visible to user space. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/3390477.aeNJFYEL58@rafael.j.wysocki
2025-12-29ACPI: SMBUS HC: Convert the driver to a platform oneRafael J. Wysocki
While binding drivers directly to struct acpi_device objects allows basic functionality to be provided, at least in the majority of cases, there are some problems with it, related to general consistency, sysfs layout, power management operation ordering, and code cleanliness. Overall, it is better to bind drivers to platform devices than to their ACPI companions, so convert the ACPI SMBUS HC driver to a platform one. After this conversion, acpi_ec_probe() does not need to populate the driver_data pointer of the EC platform device's ACPI companion any more, so update it accordingly. While this is not expected to alter functionality, it changes sysfs layout and so it will be visible to user space. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/13909645.uLZWGnKmhe@rafael.j.wysocki
2025-12-29ACPI: EC: Convert the driver to a platform oneRafael J. Wysocki
While binding drivers directly to struct acpi_device objects allows basic functionality to be provided, at least in the majority of cases, there are some problems with it, related to general consistency, sysfs layout, power management operation ordering, and code cleanliness. Overall, it is better to bind drivers to platform devices than to their ACPI companions, so convert the ACPI embedded controller (EC) driver to a platform one. After this conversion, acpi_bus_register_early_device() does not need to attempt to bind an ACPI driver to the struct acpi_device created by it, so update it accordingly. While this is not expected to alter functionality, it changes sysfs layout and so it will be visible to user space. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> [ rjw: Removed excess semicolon ] Link: https://patch.msgid.link/1946304.tdWV9SEqCh@rafael.j.wysocki Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-12-29ACPI: EC: Register a platform device for ECDT ECRafael J. Wysocki
To facilitate converting the ACPI EC driver into a platform one, modify acpi_bus_register_early_device(), used by acpi_ec_ecdt_start() for creating a struct acpi_device to represent the "early" EC based on the ECDT ACPI table, to carry out the default ACPI enumeration for the given device which will cause a platform device to be registered for it. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/2397353.ElGaqSPkdT@rafael.j.wysocki
2025-12-29ACPI: HED: Convert the driver to a platform oneRafael J. Wysocki
While binding drivers directly to struct acpi_device objects allows basic functionality to be provided, at least in the majority of cases, there are some problems with it, related to general consistency, sysfs layout, power management operation ordering, and code cleanliness. Overall, it is better to bind drivers to platform devices than to their ACPI companions, so convert the ACPI hardware error device (HED) driver to a platform one. While this is not expected to alter functionality, it changes sysfs layout and so it will be visible to user space. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/8620378.T7Z3S40VBb@rafael.j.wysocki
2025-12-26ACPI: battery: Convert the driver to a platform oneRafael J. Wysocki
While binding drivers directly to struct acpi_device objects allows basic functionality to be provided, at least in the majority of cases, there are some problems with it, related to general consistency, sysfs layout, power management operation ordering, and code cleanliness. Overall, it is better to bind drivers to platform devices than to their ACPI companions, so convert the ACPI battery driver to a platform one. While this is not expected to alter functionality, it changes sysfs layout and so it will be visible to user space. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/3187448.CbtlEUcBR6@rafael.j.wysocki
2025-12-26ACPI: battery: Reduce code duplication related to cleanupRafael J. Wysocki
Notice that sysfs_battery_cleanup() calls sysfs_remove_battery() under battery->update_lock which is also done in acpi_battery_remove(), so adjust the latter to use it. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/1866517.TLkxdtWsSY@rafael.j.wysocki
2025-12-26ACPI: battery: Adjust event notification routineRafael J. Wysocki
Adjust acpi_battery_notify() to cast its "data" argument to a struct acpi_battery pointer istead of a struct acpi_device one, which allows the use of acpi_driver_data() to be limited and will facilitate subsequent changes. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/4344406.1IzOArtZ34@rafael.j.wysocki
2025-12-26ACPI: thermal: Rework system suspend and resume handlingRafael J. Wysocki
In the process of handling system resume, acpi_thermal_resume() attempts to power up active cooling devices to guarantee that they will be operational when the ACPI thermal check queued by it runs. However, the only kind of cooling devices that can be bound to ACPI thermal zones is fans and they are already powered up by the ACPI fan driver resume, which additionally takes "ACPI 4" fans that don't need to be powered up into account. For this reason, remove the part of acpi_thermal_resume() related to fans and in order to ensure that it will run after powering up all fans, rename it to acpi_thermal_complete() and point the .complete() driver callback to it. Analogously, rename acpi_thermal_suspend() to acpi_thermal_prepare() and point the .prepare() driver callback to it. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: lihuisong@huawei.com Link: https://patch.msgid.link/3024049.e9J7NaK4W3@rafael.j.wysocki
2025-12-26ACPI: thermal: Convert the driver to a platform oneRafael J. Wysocki
While binding drivers directly to struct acpi_device objects allows basic functionality to be provided, at least in the majority of cases, there are some problems with it, related to general consistency, sysfs layout, power management operation ordering, and code cleanliness. Overall, it is better to bind drivers to platform devices than to their ACPI companions, so convert the ACPI thermal zone driver to a platform one. While this is not expected to alter functionality, it changes sysfs layout and so it will be visible to user space. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: lihuisong@huawei.com Link: https://patch.msgid.link/2249483.irdbgypaU6@rafael.j.wysocki
2025-12-26ACPI: thermal: Adjust event notification routineRafael J. Wysocki
Adjust acpi_thermal_notify() to cast its "data" argument to a struct acpi_thermal pointer istead of a struct acpi_device one, which allows the use of acpi_driver_data() to be limited and will facilitate subsequent changes. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: lihuisong@huawei.com Link: https://patch.msgid.link/5035876.GXAFRqVoOG@rafael.j.wysocki
2025-12-26ACPI: scan: Register platform devices for thermal zonesRafael J. Wysocki
Currently, platform devices are not registered for ACPI thermal zones because they are not represented as device objects in the ACPI namespace. Instead, they are represented as thermal zone objects, so in particular the platform_id flag is not set for them during enumeration because it is only set for objects of type ACPI_BUS_TYPE_DEVICE, but otherwise they are handled similarly at the ACPI core level. To facilitate converting the ACPI thermal zone driver into a platform one, modify acpi_set_pnp_ids() to set the platform_id flag for thermal zones in analogy with device objects to cause platform devices to be registered for them. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: lihuisong@huawei.com Link: https://patch.msgid.link/4701463.LvFx2qVVIh@rafael.j.wysocki
2025-12-26ACPI: scan: Do not mark button ACPI devices as wakeup-capableRafael J. Wysocki
It is generally questionable to mark struct acpi_device "devices" as wakeup-capable because they represent firmware entities that by themselves have no wakeup capabilities. It was done for struct acpi_device "devices" corresponding to buttons because the ACPI button driver was binding to them directly, but now that corresponding platform devices are created for the buttons and they are marked as wakeup-capable by the ACPI button driver, there is no reason to continue doing it. Update acpi_wakeup_gpe_init() accordingly. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/2891119.BEx9A2HvPv@rafael.j.wysocki
2025-12-26ACPI: scan: Do not bind ACPI drivers to fixed event buttonsRafael J. Wysocki
Both ACPI button drivers have been converted to platform ones, so there is no reason to attempt to bind an ACPI driver to a struct acpi_device representing a fixed event device button. Update the relevant code accordingly. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/2213073.OBFZWjSADL@rafael.j.wysocki
2025-12-26ACPI: tiny-power-button: Convert the driver to a platform oneRafael J. Wysocki
While binding drivers directly to struct acpi_device objects allows basic functionality to be provided, at least in the majority of cases, there are some problems with it, related to general consistency, sysfs layout, power management operation ordering, and code cleanliness. Overall, it is better to bind drivers to platform devices than to their ACPI companions, so convert the ACPI tiny-power-button driver to a platform one. While this is not expected to alter functionality, it changes sysfs layout and so it will be visible to user space. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> [ rjw: White space fixup ] Link: https://patch.msgid.link/5629403.Sb9uPGUboI@rafael.j.wysocki Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-12-26ACPI: button: Convert the driver to a platform oneRafael J. Wysocki
While binding drivers directly to struct acpi_device objects allows basic functionality to be provided, at least in the majority of cases, there are some problems with it, related to general consistency, sysfs layout, power management operation ordering, and code cleanliness. Overall, it is better to bind drivers to platform devices than to their ACPI companions, so convert the ACPI button driver to a platform one. While this is not expected to alter functionality, it changes sysfs layout and so it will be visible to user space. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/2461734.NG923GbCHz@rafael.j.wysocki
2025-12-26ACPI: button: Adjust event notification routinesRafael J. Wysocki
Adjust the event notification routines in the ACPI button driver to take a struct acpi_button pointer as an argument istead of a struct acpi_device one where applicable, which allows the use of acpi_driver_data() to be limited and will facilitate subsequent changes. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/2260995.Icojqenx9y@rafael.j.wysocki
2025-12-26ACPI: scan: Reduce code duplication related to fixed event devicesRafael J. Wysocki
Move duplicate fixed event device registration code from acpi_bus_scan_fixed() into a new function called acpi_bus_add_fixed_device_object() and make acpi_bus_scan_fixed() invoke that function as needed. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/1916860.atdPhlSkOF@rafael.j.wysocki
2025-12-26ACPI: scan: Register platform devices for fixed event buttonsRafael J. Wysocki
On platforms using ACPI, power and sleep buttons may be so called "fixed event devices" in which case they are hooked up directly to the Fixed Events register in the platform via dedicated lines and there are no corresponding device objects in the ACPI namespace. Nevertheless, in Linux they get corresponding struct acpi_device objects with special device IDs, either LNXPWRBN or LNXSLPBN, which are then used for driver binding in a ususal way. However, the function creating those struct acpi_device objects for "fixed event device" buttons, acpi_bus_scan_fixed(), does not register platform devices for them, unlike the generic code handling device enumeration based on the ACPI namespace. Consequently, if an ACPI power or sleep button is represented by a device object in the ACPI namespace, it will get a corresponding platform device, but if it is a "fixed event device", it will not get one, which is inconsistent and prevents the ACPI power button driver from being converted into a platform driver. For the sake of consistency and to allow the ACPI power button driver to become a platform one going forward, modify acpi_bus_scan_fixed() to register platform devices for "fixed event device" buttons and update ACPI platform device registration code to work with non-device ACPI object types, so it can handle the buttons in question. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/3731144.R56niFO833@rafael.j.wysocki
2025-12-26ACPI: NFIT: core: Convert the driver to a platform oneRafael J. Wysocki
While binding drivers directly to struct acpi_device objects allows basic functionality to be provided, at least in the majority of cases, there are some problems with it, related to general consistency, sysfs layout, power management operation ordering, and code cleanliness. Overall, it is better to bind drivers to platform devices than to their ACPI companions, so convert the ACPI NFIT core driver to a platform one. While this is not expected to alter functionality, it changes sysfs layout and so it will be visible to user space. This change was mostly developed by Michal Wilczynski [1]. Linu: https://lore.kernel.org/linux-acpi/20231011083334.3987477-6-michal.wilczynski@intel.com/ [1] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/6221453.lOV4Wx5bFT@rafael.j.wysocki Acked-by: Ira Weiny <ira.weiny@intel.com> Tested-by: Ira Weiny <ira.weiny@intel.com>
2025-12-23ACPI: bus: Rework the handling of \_SB._OSC USB4 featuresRafael J. Wysocki
Use acpi_osc_handshake() introduced previously for implementing the \_SB._OSC USB4 features control negotiation. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Link: https://patch.msgid.link/3879947.MHq7AAxBmi@rafael.j.wysocki
2025-12-23ACPI: bus: Adjust feature mask creation for \_SB._OSCRafael J. Wysocki
The feature mask creation for \_SB._OSC is messy and hard to follow, so clean it up and make all of the CPPC-related features depend on CONFIG_ACPI_CPPC_LIB as they will not work if it is not set anyway. Also make acpi_bus_osc_negotiate_platform_control() print a message including a bit mask representig the features for which control has been granted. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Link: https://patch.msgid.link/4495088.ejJDZkT8p0@rafael.j.wysocki
2025-12-23ACPI: bus: Rework the handling of \_SB._OSC platform featuresRafael J. Wysocki
Both acpi_bus_osc_negotiate_platform_control() and acpi_bus_osc_negotiate_usb_control() first call acpi_run_osc() to evaluate _OSC in "query mode", with OSC_QUERY_ENABLE set in the capabilities buffer, and then use the resultant feature mask as the input buffer for requesting control of those features by calling acpi_run_osc() to evaluate _OSC with OSC_QUERY_ENABLE clear. This involves some code duplication and unnecessary memory allocations, so introduce a new helper function carrying out an _OSC handshake along the lines of the above description in a simpler way and update acpi_bus_osc_negotiate_platform_control() to use it. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Link: https://patch.msgid.link/1966378.CQOukoFCf9@rafael.j.wysocki
2025-12-23ACPI: bus: Rename label and use ACPI_FREE() in acpi_run_osc()Rafael J. Wysocki
Use ACPI_FREE() for freeing an object coming from acpi_eval_osc() and rename the "out_free" to "out" because it does not involve kfree() any more. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Link: https://patch.msgid.link/8682086.NyiUUSuA9g@rafael.j.wysocki
2025-12-23ACPI: bus: Split _OSC error processing out of acpi_run_osc()Rafael J. Wysocki
Split a function for processing _OSC errors called acpi_osc_error_check() out of acpi_run_osc() to facilitate subsequent changes. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Link: https://patch.msgid.link/6135328.MhkbZ0Pkbq@rafael.j.wysocki
2025-12-23ACPI: bus: Split _OSC evaluation out of acpi_run_osc()Rafael J. Wysocki
Split a function for evaluating _OSC called acpi_eval_osc() out of acpi_run_osc() to facilitate subsequent changes and add some more parameters sanity checks to the latter. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Link: https://patch.msgid.link/22963770.EfDdHjke4D@rafael.j.wysocki
2025-12-23ACPI: bus: Rework printing debug messages on _OSC errorsRafael J. Wysocki
Instead of using one function, acpi_print_osc_error(), for printing a debug message and dumping the _OSC request data in one go, use acpi_handle_debug() directly for printing messages and a separate function called acpi_dump_osc_data() for dumping the _OSC request data before printing one or more of them. This avoids * dumping _OSC request data multiple times when there are multiple error bits set in the return buffer, * wrapping message lines on terminals with 80 character line width, * mixing up unrelated messages by printing full lines only, and generally helps to make the messages easier to parse. Also, use %pUL for UUID printing instead of printing UUIDs as strings and include the revision number into the dumped _OSC request data. This is how the debug printout looks like when the OSC_REQUEST_ERROR and OSC_INVALID_REVISION_ERROR bits are set in the return buffer before the change: ACPI: \_SB_: ACPI: (0811B06E-4A27-44F9-8D60-3CBBC22E7B48): _OSC request failed ACPI: _OSC request data: ACPI: 1 ACPI: 2e7eff ACPI: ACPI: \_SB_: ACPI: (0811B06E-4A27-44F9-8D60-3CBBC22E7B48): _OSC invalid revision ACPI: _OSC request data: ACPI: 1 ACPI: 2e7eff ACPI: and this is how it is going to look like afterward: ACPI: \_SB_: ACPI: _OSC: UUID: 0811B06E-4A27-44F9-8D60-3CBBC22E7B48, rev: 1 ACPI: \_SB_: ACPI: _OSC: capabilities DWORD 0: [00000001] ACPI: \_SB_: ACPI: _OSC: capabilities DWORD 1: [002e7eff] ACPI: \_SB_: ACPI: _OSC: request failed ACPI: \_SB_: ACPI: _OSC: invalid revision Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Link: https://patch.msgid.link/10794028.nUPlyArG6x@rafael.j.wysocki
2025-12-23ACPI: bus: Fix handling of _OSC errors in acpi_run_osc()Rafael J. Wysocki
The handling of _OSC errors in acpi_run_osc() is inconsistent and arguably not compliant with the _OSC definition (cf. Section 6.2.12 of ACPI 6.6 [1]). Namely, if OSC_QUERY_ENABLE is not set in the capabilities buffer and any of the error bits are set in the _OSC return buffer, acpi_run_osc() returns an error code and the _OSC return buffer is discarded. However, in that case, depending on what error bits are set, the return buffer may contain acknowledged bits for features that need to be controlled by the kernel going forward. If the OSC_INVALID_UUID_ERROR bit is set, the request could not be processed at all and so in that particular case discarding the _OSC return buffer and returning an error is the right thing to do regardless of whether or not OSC_QUERY_ENABLE is set in the capabilities buffer. If OSC_QUERY_ENABLE is set in the capabilities buffer and the OSC_REQUEST_ERROR or OSC_INVALID_REVISION_ERROR bits are set in the return buffer, acpi_run_osc() may return an error and discard the _OSC return buffer because in that case the platform configuration does not change. However, if any of them is set in the return buffer when OSC_QUERY_ENABLE is not set in the capabilities buffer, the feature mask in the _OSC return buffer still represents a set of acknowleded features as per the _OSC definition: The platform acknowledges the Capabilities Buffer by returning a buffer of DWORDs of the same length. Set bits indicate acknowledgment that OSPM may take control of the capability and cleared bits indicate that the platform either does not support the capability or that OSPM may not assume control. which is not conditional on the error bits being clear, so in that case, discarding the _OSC return buffer is questionable. There is also no reason to return an error and discard the _OSC return buffer if the OSC_CAPABILITIES_MASK_ERROR bit is set in it, but printing diagnostic messages is appropriate when that happens with OSC_QUERY_ENABLE clear in the capabilities buffer. Adress this issue by making acpi_run_osc() follow the rules outlined above. Moreover, make acpi_run_osc() only take the defined _OSC error bits into account when checking _OSC errors. Link: https://uefi.org/specs/ACPI/6.6/06_Device_Configuration.html#osc-operating-system-capabilities [1] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> [ rjw: Corrected typo in the changelog ] Link: https://patch.msgid.link/3042649.e9J7NaK4W3@rafael.j.wysocki Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-12-17ACPI: PM: Register wakeup sources under physical devicesRafael J. Wysocki
Currently, acpi_add_pm_notifier() registers wakeup sources under ACPI companions of the devices affected by the handling of wakeup events which goes against the rule that a struct acpi_device can only be a parent of another struct acpi_device. Moreover, it would be more logically consistent to register wakeup sources under the devices affected by wakeup events handling which would cause them to appear in more suitable places in sysfs and would help to identify the devices they are associated with more easily. Accordingly, update acpi_add_pm_notifier() to register wakeup sources under the "target" devices directly instead of registering them under the ACPI companions of those devices. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Armin Wolf <W_Armin@gmx.de> Link: https://patch.msgid.link/1944126.tdWV9SEqCh@rafael.j.wysocki
2025-12-17ACPI: PCI: PM: Rework root bus notification setupRafael J. Wysocki
Since pci_acpi_add_bus_pm_notifier() is only suitable for adding ACPI PM notifiers to root buses, rename it to pci_acpi_add_root_pm_notifier() and modify it to take an additional "root" argument, which is then used for passing a PCI root bridge device pointer to acpi_add_pm_notifier(). That function uses it to populate the "dev" field in the context structure attached to the ACPI device object that will receive the ACPI "wake" notifications on behalf of the given PCI root bus. The context structure in question is passed to pci_acpi_wake_bus(), so the latter can be simplified quite a bit now because the target PCI host bridge structure address can be derived from "dev". No intentional functional impact. This change will also facilitate a subsequent update related to the registration of wakeup sources. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Armin Wolf <W_Armin@gmx.de> [ rjw: Kerneldoc comment fixup ] Link: https://patch.msgid.link/2395263.ElGaqSPkdT@rafael.j.wysocki Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-12-16ACPI: PNP: Drop acpi_nonpnp_device_ids[]Rafael J. Wysocki
Now that "system" devices are represented as platform devices, they are not claimed by the PNP ACPI scan handler any more and platform devices can be created for ACPI device objects listing "system" device IDs as their compatible device IDs. Accordingly, it should not be necessary any more to add device IDs to acpi_nonpnp_device_ids[], so drop it. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Link: https://patch.msgid.link/3587570.QJadu78ljV@rafael.j.wysocki
2025-12-16ACPI: PNP: Drop PNP0C01 and PNP0C02 from acpi_pnp_device_ids[]Rafael J. Wysocki
There is a long-standing problem with ACPI device enumeration that if the given device has a compatible ID which is one of the generic system resource device IDs (PNP0C01 and PNP0C02), it will be claimed by the PNP scan handler and it will not be represented as a platform device, so it cannot be handled by a platform driver. Drivers have been working around this issue by "manually" creating platform devices that they can bind to (see the Intel HID driver for one example) or adding their device IDs to acpi_nonpnp_device_ids[]. None of the above is particularly clean though and the only reason why the PNP0C01 and PNP0C02 device IDs are present in acpi_pnp_device_ids[] is to allow the legacy PNP system driver to bind to those devices and reserve their resources so they are not used going forward. Obviously, to address this problem PNP0C01 and PNP0C02 need to be dropped from acpi_pnp_device_ids[], but doing so without making any other changes would be problematic because the ACPI core would then create platform devices for the generic system resource device objects and that would not work on all systems for two reasons. First, the PNP system driver explicitly avoids reserving I/O resources below the "standard PC hardware" boundary, 0x100, to avoid conflicts in that range (one possible case when this may happen is when the CMOS RTC driver is involved), but the platform device creation code does not do that. Second, there may be resource conflicts between the "system" devices and the other devices in the system, possibly including conflicts with PCI BARs. Registering the PNP system driver via fs_initcall() helps to manage those conflicts, even though it does not make them go away. Resource conflicts during the registration of "motherboard resources" that occur after PCI has claimed BARs are harmless as a rule and do not need to be addressed in any specific way. To overcome the issues mentioned above, use the observation that it is not actually necessary to create any device objects in addition to struct acpi_device ones in order to reserve the "system" device resources because that can be done directly in the ACPI device enumeration code. Namely, modify acpi_default_enumeration() to add the given ACPI device object to a special "system devices" list if its _HID is either PNP0C01 or PNP0C02 without creating a platform device for it. Next, add a new special acpi_scan_claim_resources() function that will be run via fs_initcall() and will walk that list and reserve resources for each device in it along the lines of what the PNP system driver does. Having made the above changes, drop PNP0C01 and PNP0C02 from acpi_pnp_device_ids[] which will allow platform devices to be created for ACPI device objects whose _CID lists contain PNP0C01 or PNP0C02, but the _HID is not in acpi_pnp_device_ids[]. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> [ rjw: Drop a leftover comment and add a new one elsewhere ] Link: https://patch.msgid.link/9550709.CDJkKcVGEf@rafael.j.wysocki Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-12-15ACPI: PCC: Fix race condition by removing static qualifierPengjie Zhang
Local variable 'ret' in acpi_pcc_address_space_setup() is currently declared as 'static'. This can lead to race conditions in a multithreaded environment. Remove the 'static' qualifier to ensure that 'ret' will be allocated directly on the stack as a local variable. Fixes: a10b1c99e2dc ("ACPI: PCC: Setup PCC Opregion handler only if platform interrupt is available") Signed-off-by: Pengjie Zhang <zhangpengjie2@huawei.com> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> Acked-by: lihuisong@huawei.com Cc: 6.2+ <stable@vger.kernel.org> # 6.2+ [ rjw: Changelog edits ] Link: https://patch.msgid.link/20251210132634.2050033-1-zhangpengjie2@huawei.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-12-15ACPI: CPPC: Fix missing PCC check for guaranteed_perfPengjie Zhang
The current implementation overlooks the 'guaranteed_perf' register in this check. If the Guaranteed Performance register is located in the PCC subspace, the function currently attempts to read it without acquiring the lock and without sending the CMD_READ doorbell to the firmware. This can result in reading stale data. Fixes: 29523f095397 ("ACPI / CPPC: Add support for guaranteed performance") Signed-off-by: Pengjie Zhang <zhangpengjie2@huawei.com> Cc: 4.20+ <stable@vger.kernel.org> # 4.20+ [ rjw: Subject and changelog edits ] Link: https://patch.msgid.link/20251210132227.1988380-1-zhangpengjie2@huawei.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-12-10Merge tag 'platform-drivers-x86-v6.19-1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86 Pull x86 platform driver updates from Ilpo Järvinen: - acer-wmi: Add PH16-72, PHN16-72, and PT14-51 fan control support - acpi: platform_profile: Add max-power profile option (power draw limited by the cooling hardware, may exceed battery power draw limit when on AC power) - amd/hsmp: Allow more than one data-fabric per socket - asus-armoury: Add WMI attributes driver to expose miscellaneous WMI functions through fw_attributes (deprecates the custom BIOS features interface through asus-wmi) - asus-wmi: Use brightness_set_blocking() for kbd led - ayaneo-ec: Add Ayaneo Embedded Controller driver - fs/nls: - Fix utf16 to utf8 string conversion when output size restricted - Improve error code consistency for utf8 to utf32 conversions - ideapad-laptop: Fast (Rapid Charge) charge type support - intel/hid: Add Dell Pro Rugged 10/12 tablet to VGBS DMI quirks - intel/pmc: - Arrow Lake telemetry GUID improvements - Add support for Wildcat Lake PMC information - intel_pmc_ipc: Fix ACPI buffer memleak - intel/punit_ipc: Fix memory corruption - intel/vsec: Wildcat Lake PMT telemetry support - lenovo-wmi-gamezone: Map "Extreme" performance mode to max-power - lg-laptop: Add support for the HDAP opregion field - serial-multi-instantiate: Add IRQ_RESOURCE_OPT for IRQ missing projects - thinkpad-t14s-ec: Improve suspend/resume support (lid LEDs, keyboard backlight) - uniwill: Add Uniwill laptop driver - wmi: Move under drivers/platform/wmi as non-x86 WMI support is around the corner and other WMI features will require adding more C files as well - tools/power/x86/intel-speed-select: v1.24 - Check feature status to check if the feature enablement was successful - Reset SST-TF bucket structure to display valid bucket info - Miscellaneous cleanups / refactoring / improvements * tag 'platform-drivers-x86-v6.19-1' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86: (73 commits) tools/power/x86/intel-speed-select: v1.24 release tools/power/x86/intel-speed-select: Reset isst_turbo_freq_info for invalid buckets tools/power/x86/intel-speed-select: Check feature status platform/x86: asus-wmi: use brightness_set_blocking() for kbd led fs/nls: Fix inconsistency between utf8_to_utf32() and utf32_to_utf8() platform/x86: asus-armoury: add support for GA503QR platform/x86: intel_pmc_ipc: fix ACPI buffer memory leak platform/x86: hp-wmi: Order DMI board name arrays platform/x86/intel/hid: Add Dell Pro Rugged 10/12 tablet to VGBS DMI quirks platform: surface: replace use of system_wq with system_percpu_wq platform: x86: replace use of system_wq with system_percpu_wq platform/surface: acpi-notify: add WQ_PERCPU to alloc_workqueue users platform/x86: wmi-gamezone: Add Legion Go 2 Quirks platform/x86: lenovo-wmi-gamezone Use max-power rather than balanced-performance acpi: platform_profile - Add max-power profile option platform/x86/amd/pmf: Use devm_mutex_init() for mutex initialization platform/x86/amd/pmf: Add BIOS_INPUTS_MAX macro to replace hardcoded array size platform/x86: serial-multi-instantiate: Add IRQ_RESOURCE_OPT for IRQ missing projects platform/x86/amd/pmf: Refactor repetitive BIOS output handling platform/x86/uniwill: Add TUXEDO devices ...
2025-12-06Merge tag 'mm-nonmm-stable-2025-12-06-11-14' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Pull non-MM updates from Andrew Morton: - "panic: sys_info: Refactor and fix a potential issue" (Andy Shevchenko) fixes a build issue and does some cleanup in ib/sys_info.c - "Implement mul_u64_u64_div_u64_roundup()" (David Laight) enhances the 64-bit math code on behalf of a PWM driver and beefs up the test module for these library functions - "scripts/gdb/symbols: make BPF debug info available to GDB" (Ilya Leoshkevich) makes BPF symbol names, sizes, and line numbers available to the GDB debugger - "Enable hung_task and lockup cases to dump system info on demand" (Feng Tang) adds a sysctl which can be used to cause additional info dumping when the hung-task and lockup detectors fire - "lib/base64: add generic encoder/decoder, migrate users" (Kuan-Wei Chiu) adds a general base64 encoder/decoder to lib/ and migrates several users away from their private implementations - "rbree: inline rb_first() and rb_last()" (Eric Dumazet) makes TCP a little faster - "liveupdate: Rework KHO for in-kernel users" (Pasha Tatashin) reworks the KEXEC Handover interfaces in preparation for Live Update Orchestrator (LUO), and possibly for other future clients - "kho: simplify state machine and enable dynamic updates" (Pasha Tatashin) increases the flexibility of KEXEC Handover. Also preparation for LUO - "Live Update Orchestrator" (Pasha Tatashin) is a major new feature targeted at cloud environments. Quoting the cover letter: This series introduces the Live Update Orchestrator, a kernel subsystem designed to facilitate live kernel updates using a kexec-based reboot. This capability is critical for cloud environments, allowing hypervisors to be updated with minimal downtime for running virtual machines. LUO achieves this by preserving the state of selected resources, such as memory, devices and their dependencies, across the kernel transition. As a key feature, this series includes support for preserving memfd file descriptors, which allows critical in-memory data, such as guest RAM or any other large memory region, to be maintained in RAM across the kexec reboot. Mike Rappaport merits a mention here, for his extensive review and testing work. - "kexec: reorganize kexec and kdump sysfs" (Sourabh Jain) moves the kexec and kdump sysfs entries from /sys/kernel/ to /sys/kernel/kexec/ and adds back-compatibility symlinks which can hopefully be removed one day - "kho: fixes for vmalloc restoration" (Mike Rapoport) fixes a BUG which was being hit during KHO restoration of vmalloc() regions * tag 'mm-nonmm-stable-2025-12-06-11-14' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: (139 commits) calibrate: update header inclusion Reinstate "resource: avoid unnecessary lookups in find_next_iomem_res()" vmcoreinfo: track and log recoverable hardware errors kho: fix restoring of contiguous ranges of order-0 pages kho: kho_restore_vmalloc: fix initialization of pages array MAINTAINERS: TPM DEVICE DRIVER: update the W-tag init: replace simple_strtoul with kstrtoul to improve lpj_setup KHO: fix boot failure due to kmemleak access to non-PRESENT pages Documentation/ABI: new kexec and kdump sysfs interface Documentation/ABI: mark old kexec sysfs deprecated kexec: move sysfs entries to /sys/kernel/kexec test_kho: always print restore status kho: free chunks using free_page() instead of kfree() selftests/liveupdate: add kexec test for multiple and empty sessions selftests/liveupdate: add simple kexec-based selftest for LUO selftests/liveupdate: add userspace API selftests docs: add documentation for memfd preservation via LUO mm: memfd_luo: allow preserving memfd liveupdate: luo_file: add private argument to store runtime state mm: shmem: export some functions to internal.h ...
2025-12-05Merge tag 'soc-drivers-6.19' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull SoC driver updates from Arnd Bergmann: "This is the first half of the driver changes: - A treewide interface change to the "syscore" operations for power management, as a preparation for future Tegra specific changes - Reset controller updates with added drivers for LAN969x, eic770 and RZ/G3S SoCs - Protection of system controller registers on Renesas and Google SoCs, to prevent trivially triggering a system crash from e.g. debugfs access - soc_device identification updates on Nvidia, Exynos and Mediatek - debugfs support in the ST STM32 firewall driver - Minor updates for SoC drivers on AMD/Xilinx, Renesas, Allwinner, TI - Cleanups for memory controller support on Nvidia and Renesas" * tag 'soc-drivers-6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (114 commits) memory: tegra186-emc: Fix missing put_bpmp Documentation: reset: Remove reset_controller_add_lookup() reset: fix BIT macro reference reset: rzg2l-usbphy-ctrl: Fix a NULL vs IS_ERR() bug in probe reset: th1520: Support reset controllers in more subsystems reset: th1520: Prepare for supporting multiple controllers dt-bindings: reset: thead,th1520-reset: Add controllers for more subsys dt-bindings: reset: thead,th1520-reset: Remove non-VO-subsystem resets reset: remove legacy reset lookup code clk: davinci: psc: drop unused reset lookup reset: rzg2l-usbphy-ctrl: Add support for RZ/G3S SoC reset: rzg2l-usbphy-ctrl: Add support for USB PWRRDY dt-bindings: reset: renesas,rzg2l-usbphy-ctrl: Document RZ/G3S support reset: eswin: Add eic7700 reset driver dt-bindings: reset: eswin: Documentation for eic7700 SoC reset: sparx5: add LAN969x support dt-bindings: reset: microchip: Add LAN969x support soc: rockchip: grf: Add select correct PWM implementation on RK3368 soc/tegra: pmc: Add USB wake events for Tegra234 amba: tegra-ahb: Fix device leak on SMMU enable ...
2025-12-05Merge tag 'mm-stable-2025-12-03-21-26' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Pull MM updates from Andrew Morton: "__vmalloc()/kvmalloc() and no-block support" (Uladzislau Rezki) Rework the vmalloc() code to support non-blocking allocations (GFP_ATOIC, GFP_NOWAIT) "ksm: fix exec/fork inheritance" (xu xin) Fix a rare case where the KSM MMF_VM_MERGE_ANY prctl state is not inherited across fork/exec "mm/zswap: misc cleanup of code and documentations" (SeongJae Park) Some light maintenance work on the zswap code "mm/page_owner: add debugfs files 'show_handles' and 'show_stacks_handles'" (Mauricio Faria de Oliveira) Enhance the /sys/kernel/debug/page_owner debug feature by adding unique identifiers to differentiate the various stack traces so that userspace monitoring tools can better match stack traces over time "mm/page_alloc: pcp->batch cleanups" (Joshua Hahn) Minor alterations to the page allocator's per-cpu-pages feature "Improve UFFDIO_MOVE scalability by removing anon_vma lock" (Lokesh Gidra) Address a scalability issue in userfaultfd's UFFDIO_MOVE operation "kasan: cleanups for kasan_enabled() checks" (Sabyrzhan Tasbolatov) "drivers/base/node: fold node register and unregister functions" (Donet Tom) Clean up the NUMA node handling code a little "mm: some optimizations for prot numa" (Kefeng Wang) Cleanups and small optimizations to the NUMA allocation hinting code "mm/page_alloc: Batch callers of free_pcppages_bulk" (Joshua Hahn) Address long lock hold times at boot on large machines. These were causing (harmless) softlockup warnings "optimize the logic for handling dirty file folios during reclaim" (Baolin Wang) Remove some now-unnecessary work from page reclaim "mm/damon: allow DAMOS auto-tuned for per-memcg per-node memory usage" (SeongJae Park) Enhance the DAMOS auto-tuning feature "mm/damon: fixes for address alignment issues in DAMON_LRU_SORT and DAMON_RECLAIM" (Quanmin Yan) Fix DAMON_LRU_SORT and DAMON_RECLAIM with certain userspace configuration "expand mmap_prepare functionality, port more users" (Lorenzo Stoakes) Enhance the new(ish) file_operations.mmap_prepare() method and port additional callsites from the old ->mmap() over to ->mmap_prepare() "Fix stale IOTLB entries for kernel address space" (Lu Baolu) Fix a bug (and possible security issue on non-x86) in the IOMMU code. In some situations the IOMMU could be left hanging onto a stale kernel pagetable entry "mm/huge_memory: cleanup __split_unmapped_folio()" (Wei Yang) Clean up and optimize the folio splitting code "mm, swap: misc cleanup and bugfix" (Kairui Song) Some cleanups and a minor fix in the swap discard code "mm/damon: misc documentation fixups" (SeongJae Park) "mm/damon: support pin-point targets removal" (SeongJae Park) Permit userspace to remove a specific monitoring target in the middle of the current targets list "mm: MISC follow-up patches for linux/pgalloc.h" (Harry Yoo) A couple of cleanups related to mm header file inclusion "mm/swapfile.c: select swap devices of default priority round robin" (Baoquan He) improve the selection of swap devices for NUMA machines "mm: Convert memory block states (MEM_*) macros to enums" (Israel Batista) Change the memory block labels from macros to enums so they will appear in kernel debug info "ksm: perform a range-walk to jump over holes in break_ksm" (Pedro Demarchi Gomes) Address an inefficiency when KSM unmerges an address range "mm/damon/tests: fix memory bugs in kunit tests" (SeongJae Park) Fix leaks and unhandled malloc() failures in DAMON userspace unit tests "some cleanups for pageout()" (Baolin Wang) Clean up a couple of minor things in the page scanner's writeback-for-eviction code "mm/hugetlb: refactor sysfs/sysctl interfaces" (Hui Zhu) Move hugetlb's sysfs/sysctl handling code into a new file "introduce VM_MAYBE_GUARD and make it sticky" (Lorenzo Stoakes) Make the VMA guard regions available in /proc/pid/smaps and improves the mergeability of guarded VMAs "mm: perform guard region install/remove under VMA lock" (Lorenzo Stoakes) Reduce mmap lock contention for callers performing VMA guard region operations "vma_start_write_killable" (Matthew Wilcox) Start work on permitting applications to be killed when they are waiting on a read_lock on the VMA lock "mm/damon/tests: add more tests for online parameters commit" (SeongJae Park) Add additional userspace testing of DAMON's "commit" feature "mm/damon: misc cleanups" (SeongJae Park) "make VM_SOFTDIRTY a sticky VMA flag" (Lorenzo Stoakes) Address the possible loss of a VMA's VM_SOFTDIRTY flag when that VMA is merged with another "mm: support device-private THP" (Balbir Singh) Introduce support for Transparent Huge Page (THP) migration in zone device-private memory "Optimize folio split in memory failure" (Zi Yan) "mm/huge_memory: Define split_type and consolidate split support checks" (Wei Yang) Some more cleanups in the folio splitting code "mm: remove is_swap_[pte, pmd]() + non-swap entries, introduce leaf entries" (Lorenzo Stoakes) Clean up our handling of pagetable leaf entries by introducing the concept of 'software leaf entries', of type softleaf_t "reparent the THP split queue" (Muchun Song) Reparent the THP split queue to its parent memcg. This is in preparation for addressing the long-standing "dying memcg" problem, wherein dead memcg's linger for too long, consuming memory resources "unify PMD scan results and remove redundant cleanup" (Wei Yang) A little cleanup in the hugepage collapse code "zram: introduce writeback bio batching" (Sergey Senozhatsky) Improve zram writeback efficiency by introducing batched bio writeback support "memcg: cleanup the memcg stats interfaces" (Shakeel Butt) Clean up our handling of the interrupt safety of some memcg stats "make vmalloc gfp flags usage more apparent" (Vishal Moola) Clean up vmalloc's handling of incoming GFP flags "mm: Add soft-dirty and uffd-wp support for RISC-V" (Chunyan Zhang) Teach soft dirty and userfaultfd write protect tracking to use RISC-V's Svrsw60t59b extension "mm: swap: small fixes and comment cleanups" (Youngjun Park) Fix a small bug and clean up some of the swap code "initial work on making VMA flags a bitmap" (Lorenzo Stoakes) Start work on converting the vma struct's flags to a bitmap, so we stop running out of them, especially on 32-bit "mm/swapfile: fix and cleanup swap list iterations" (Youngjun Park) Address a possible bug in the swap discard code and clean things up a little [ This merge also reverts commit ebb9aeb980e5 ("vfio/nvgrace-gpu: register device memory for poison handling") because it looks broken to me, I've asked for clarification - Linus ] * tag 'mm-stable-2025-12-03-21-26' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: (321 commits) mm: fix vma_start_write_killable() signal handling mm/swapfile: use plist_for_each_entry in __folio_throttle_swaprate mm/swapfile: fix list iteration when next node is removed during discard fs/proc/task_mmu.c: fix make_uffd_wp_huge_pte() huge pte handling mm/kfence: add reboot notifier to disable KFENCE on shutdown memcg: remove inc/dec_lruvec_kmem_state helpers selftests/mm/uffd: initialize char variable to Null mm: fix DEBUG_RODATA_TEST indentation in Kconfig mm: introduce VMA flags bitmap type tools/testing/vma: eliminate dependency on vma->__vm_flags mm: simplify and rename mm flags function for clarity mm: declare VMA flags by bit zram: fix a spelling mistake mm/page_alloc: optimize lowmem_reserve max lookup using its semantic monotonicity mm/vmscan: skip increasing kswapd_failures when reclaim was boosted pagemap: update BUDDY flag documentation mm: swap: remove scan_swap_map_slots() references from comments mm: swap: change swap_alloc_slow() to void mm, swap: remove redundant comment for read_swap_cache_async mm, swap: use SWP_SOLIDSTATE to determine if swap is rotational ...
generated by cgit v1.2.3 (git 2.39.1) at 2026-09-20 17:50:27 +0000