kernel/linux.git/drivers/acpi/thermal.c, branch linux-7.1.y

ACPI: driver: Check ACPI_COMPANION() against NULL during probe

2026-05-11T16:50:06+00:00

Since every platform driver can be forced to match a device that doesn't match its list of device IDs because of device_match_driver_override(), platform drivers that rely on the existence of a device's ACPI companion object should verify its presence. Accordingly, add requisite ACPI_COMPANION() or ACPI_HANDLE() checks against NULL to 13 platform drivers handling core ACPI devices. Also change the value returned by the ACPI thermal zone driver when the device's ACPI companion is not present to -ENODEV for consistency with the other drivers. Signed-off-by: Rafael J. Wysocki Reviewed-by: Hans de Goede Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/4516068.ejJDZkT8p0@rafael.j.wysocki Cc: 7.0+ # 7.0+

ACPI: driver: Do not set acpi_device_class() unnecessarily

2026-03-13T15:48:26+00:00

Several core ACPI device drivers set acpi_device_class() for the given struct acpi_device to whatever they like, but that value is never used unless the driver itself uses it and, sadly, they neglect to clear it on remove. Since the only one of them still using acpi_device_class() after previous changes is the button driver, update the others to stop setting it in vain. Also drop the related device class sybmols that become redundant. Since the ACPI button driver continues to use acpi_device_class(), make it clear the struct field represented by acpi_device_class() in its remove callback. No intentional functional impact. Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/3706295.iIbC2pHGDl@rafael.j.wysocki

ACPI: driver: Avoid using pnp.device_class for netlink handling

2026-03-13T15:48:25+00:00

Update several core ACPI device drivers that use acpi_bus_generate_netlink_event() for generating netlink messages to pass a string literal as its first argument instead of a pointer to pnp.device_class in a given struct acpi_device, which will allow them to avoid initializing the pnp.device_class field in the future. The ACPI button driver that uses different acpi_device_class() values for different button types will still pass it to acpi_bus_generate_netlink_event(), but update it to use the acpi_device_class() macro instead of open coding the pointer access path. No intentional functional impact. Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/7944022.EvYhyI6sBW@rafael.j.wysocki

ACPI: driver: Do not set acpi_device_name() unnecessarily

2026-03-13T15:48:23+00:00

ACPI drivers usually set acpi_device_name() for the given struct acpi_device to whatever they like, but that value is never used unless the driver itself uses it and, quite unfortunately, drivers neglect to clear it on remove. Some drivers use it for printing messages or initializing the names of subordinate devices, but it is better to use string literals for that, especially if the given one is used just once. To eliminate unnecessary overhead related to acpi_device_name() handling, rework multiple core ACPI device drivers to stop setting acpi_device_name() for struct acpi_device objects manipulated by them and use a string literal instead of it where applicable. No intentional functional impact. Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/10840483.nUPlyArG6x@rafael.j.wysocki

Convert 'alloc_obj' family to use the new default GFP_KERNEL argument

2026-02-22T01:09:51+00:00

This was done entirely with mindless brute force, using git grep -l '\

treewide: Replace kmalloc with kmalloc_obj for non-scalar types

2026-02-21T09:02:28+00:00

This is the result of running the Coccinelle script from scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to avoid scalar types (which need careful case-by-case checking), and instead replace kmalloc-family calls that allocate struct or union object instances: Single allocations: kmalloc(sizeof(TYPE), ...) are replaced with: kmalloc_obj(TYPE, ...) Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...) are replaced with: kmalloc_objs(TYPE, COUNT, ...) Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...) are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...) (where TYPE may also be *VAR) The resulting allocations no longer return "void *", instead returning "TYPE *". Signed-off-by: Kees Cook

ACPI: thermal: Rework system suspend and resume handling

2025-12-26T14:09:35+00:00

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 Acked-by: lihuisong@huawei.com Link: https://patch.msgid.link/3024049.e9J7NaK4W3@rafael.j.wysocki

ACPI: thermal: Convert the driver to a platform one

2025-12-26T14:09:35+00:00

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 Tested-by: lihuisong@huawei.com Link: https://patch.msgid.link/2249483.irdbgypaU6@rafael.j.wysocki

ACPI: thermal: Adjust event notification routine

2025-12-26T14:09:35+00:00

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 Acked-by: lihuisong@huawei.com Link: https://patch.msgid.link/5035876.GXAFRqVoOG@rafael.j.wysocki

ACPI: thermal: Add WQ_PERCPU to alloc_workqueue() users

2025-11-03T17:45:42+00:00

Currently if a user enqueue a work item using schedule_delayed_work() the used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to schedule_work() that is using system_wq and queue_work(), that makes use again of WORK_CPU_UNBOUND. This lack of consistentcy cannot be addressed without refactoring the API. alloc_workqueue() treats all queues as per-CPU by default, while unbound workqueues must opt-in via WQ_UNBOUND. This default is suboptimal: most workloads benefit from unbound queues, allowing the scheduler to place worker threads where they’re needed and reducing noise when CPUs are isolated. This change adds a new WQ_PERCPU flag to explicitly request alloc_workqueue() to be per-cpu when WQ_UNBOUND has not been specified. With the introduction of the WQ_PERCPU flag (equivalent to !WQ_UNBOUND), any alloc_workqueue() caller that doesn’t explicitly specify WQ_UNBOUND must now use WQ_PERCPU. Once migration is complete, WQ_UNBOUND can be removed and unbound will become the implicit default. Suggested-by: Tejun Heo Signed-off-by: Marco Crivellari [ rjw: Subject adjustment ] Link: https://patch.msgid.link/20251030154739.262582-6-marco.crivellari@suse.com Signed-off-by: Rafael J. Wysocki