summaryrefslogtreecommitdiff
path: root/drivers/thermal
AgeCommit message (Collapse)Author
2024-10-24thermal: core: Relocate functions that update trip pointsRafael J. Wysocki
In preparation for subsequent changes, move two functions used for updating trip points, thermal_zone_set_trip_temp() and thermal_zone_set_trip_hyst(), to thermal_core.c. No functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Link: https://patch.msgid.link/3248558.5fSG56mABF@rjwysocki.net
2024-10-24thermal: core: Move some trip processing to thermal_trip_crossed()Rafael J. Wysocki
Notice that some processing related to trip point crossing carried out in handle_thermal_trip() and thermal_zone_set_trip_temp() may as well be done in thermal_trip_crossed(), which allows code duplication to be reduced, so change the code accordingly. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Link: https://patch.msgid.link/1982859.PYKUYFuaPT@rjwysocki.net
2024-10-24thermal: core: Pass trip descriptor to thermal_trip_crossed()Rafael J. Wysocki
In preparation for subsequent changes, modify thermal_trip_crossed() to take a trip descriptor pointer instead of a pointer to struct thermal_trip and propagate this change to thermal_zone_trip_down(). No functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Link: https://patch.msgid.link/10547668.nUPlyArG6x@rjwysocki.net
2024-10-24thermal: core: Rearrange __thermal_zone_device_update()Rafael J. Wysocki
In preparation for subsequent changes, move the invocations of thermal_thresholds_handle() and thermal_zone_set_trips() in __thermal_zone_device_update() after the processing of the temporary trip lists. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Link: https://patch.msgid.link/3323276.44csPzL39Z@rjwysocki.net
2024-10-24thermal: core: Prepare for moving trips between sorted listsRafael J. Wysocki
Subsequently, trips will be moved between sorted lists in multiple places, so replace add_trip_to_sorted_list() with an analogous function, move_trip_to_sorted_list(), that will move a given trip to a given sorted list. To allow list_del() used in the new function to work, initialize the list_node fields in trip descriptors where applicable so they are always valid. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Link: https://patch.msgid.link/2960197.e9J7NaK4W3@rjwysocki.net
2024-10-24thermal: core: Rename trip list node in struct thermal_trip_descRafael J. Wysocki
Since the list node field in struct thermal_trip_desc is going to be used for purposes other than trip crossing notification, rename it to list_node. No functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Link: https://patch.msgid.link/2201558.irdbgypaU6@rjwysocki.net
2024-10-24thermal: core: Build sorted lists instead of sorting them laterRafael J. Wysocki
Since it is not expected that multiple trip points will be crossed in one go very often (if this happens, there are too many trip points in the given thermal zone or they are checked too rarely), quite likely it is more efficient to build a sorted list of crossed trip points than to put them on an unsorted list and sort it later. Moreover, trip points are often sorted in ascending temperature order during thermal zone registration, so building a sorted list out of them is quite straightforward and relatively inexpensive. Accordingly, make handle_thermal_trip() maintain list ordering when adding trip points to the lists and get rid of separate list sorting in __thermal_zone_device_update(). No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Link: https://patch.msgid.link/4930656.GXAFRqVoOG@rjwysocki.net
2024-10-24thermal: thresholds: Fix thermal lock annotation issueDaniel Lezcano
When the thermal zone is unregistered (thermal sensor module being unloaded), no lock is held when flushing the thresholds. That results in a WARN when the lockdep validation is set in the kernel config. This has been reported by syzbot. As the thermal zone is in the process of being destroyed, there is no need to send a notification about purging the thresholds to the userspace as this one will receive a thermal zone deletion notification which imply the deletion of all the associated resources like the trip points or the user thresholds. Split the function thermal_thresholds_flush() into a lockless one without notification and its call with the lock annotation followed with the thresholds flushing notification. Please note this scenario is unlikely to happen, as the sensor drivers are usually compiled-in in order to have the thermal framework to be able to kick in at boot time if needed. Fixes: 445936f9e258 ("thermal: core: Add user thresholds support") Link: https://lore.kernel.org/all/67124175.050a0220.10f4f4.0012.GAE@google.com Reported-by: syzbot+f24dd060c1911fe54c85@syzkaller.appspotmail.com Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://patch.msgid.link/20241024102303.1086147-1-daniel.lezcano@linaro.org [ rjw: Subject edit, added Fixes tag ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-10-24thermal: netlink: Add the commands and the events for the thresholdsDaniel Lezcano
The thresholds exist but there is no notification neither action code related to them yet. These changes implement the netlink for the notifications when the thresholds are crossed, added, deleted or flushed as well as the commands which allows to get the list of the thresholds, flush them, add and delete. Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Link: https://patch.msgid.link/20241022155147.463475-3-daniel.lezcano@linaro.org [ rjw: Use the thermal_zone guard for locking, subject edit ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-10-24thermal: core: Manage thermal_governor_lock using a mutex guardRafael J. Wysocki
Switch over the thermal core to using a mutex guard for thermal_governor_lock management. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/3679429.R56niFO833@rjwysocki.net Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
2024-10-24thermal: core: Separate thermal zone governor initializationRafael J. Wysocki
In preparation for a subsequent change that will switch over the thermal core to using a mutex guard for managing thermal_governor_lock, move the code running in thermal_zone_device_register_with_trips() under that lock into a separate function called thermal_zone_init_governor(). While at it, drop a useless comment. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/4408795.ejJDZkT8p0@rjwysocki.net Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
2024-10-24thermal: core: Add and use cooling device guardRafael J. Wysocki
Add and use a special guard for cooling devices. This allows quite a few error code paths to be simplified among other things and brings in code size reduction for a good measure. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/5837621.DvuYhMxLoT@rjwysocki.net Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
2024-10-23thermal: core: Introduce thermal_cdev_update_nocheck()Rafael J. Wysocki
Three thermal governors call __thermal_cdev_update() under the cdev lock without doing any checks, so in order to reduce the related code duplication, introduce a new helper function called thermal_cdev_update_nocheck() for them and make them use it. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/1835097.VLH7GnMWUR@rjwysocki.net Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
2024-10-23thermal: core: Introduce thermal_instance_delete()Rafael J. Wysocki
It is not necessary to walk the thermal_instances list in a trip descriptor under a cooling device lock, so acquire that lock only for deleting the given thermal instance from the list of thermal instances in the given cdev. Moreover, in analogy with the previous change that introduced thermal_instance_add(), put the code deleting the given thermal instance from the lists it is on into a separate new function called thermal_instance_delete(). No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/3275745.5fSG56mABF@rjwysocki.net Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
2024-10-23thermal: core: Introduce thermal_instance_add()Rafael J. Wysocki
To reduce the number of redundant result checks in thermal_bind_cdev_to_trip() and make the code in it easier to follow, move some of it to a new function called thermal_instance_add() and make thermal_bind_cdev_to_trip() invoke that function. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/3618899.iIbC2pHGDl@rjwysocki.net Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
2024-10-23thermal: core: Call thermal_governor_update_tz() outside of cdev lockRafael J. Wysocki
Holding a cooling device lock under thermal_governor_update_tz() is not necessary and it may cause lockdep to complain if any governor's .update_tz() callback attempts to lock a cdev. For this reason, move the thermal_governor_update_tz() calls in thermal_bind_cdev_to_trip() and thermal_unbind_cdev_from_trip() from under the cdev lock. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/7749552.EvYhyI6sBW@rjwysocki.net Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
2024-10-23thermal: core: Manage thermal_list_lock using a mutex guardRafael J. Wysocki
Switch over the thermal core to using a mutex guard for thermal_list_lock management. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/2010397.PYKUYFuaPT@rjwysocki.net Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
2024-10-23thermal: core: Separate code running under thermal_list_lockRafael J. Wysocki
To prepare for a subsequent change that will switch over the thermal core to using a mutex guard for thermal_list_lock management, move the code running under thermal_list_lock during the initialization and unregistration of cooling devices into separate functions. While at it, drop some comments that do not add value. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/10572828.nUPlyArG6x@rjwysocki.net Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
2024-10-23thermal: core: Add and use a reverse thermal zone guardRafael J. Wysocki
Add a guard for unlocking a locked thermal zone temporarily and use it in thermal_zone_pm_prepare(). No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/3344086.aeNJFYEL58@rjwysocki.net Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
2024-10-23thermal: core: Add and use thermal zone guardRafael J. Wysocki
Add and use a guard for thermal zone locking. This allows quite a few error code paths to be simplified among other things and brings in a noticeable code size reduction for a good measure. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/1930069.tdWV9SEqCh@rjwysocki.net Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
2024-10-22thermal: core: Pass trip descriptors to trip bind/unbind functionsRafael J. Wysocki
The code is somewhat cleaner if struct thermal_trip_desc pointers are passed to thermal_bind_cdev_to_trip(), thermal_unbind_cdev_from_trip(), and print_bind_err_msg() instead of struct thermal_trip pointers, so modify it accordingly. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/2246211.NgBsaNRSFp@rjwysocki.net Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
2024-10-22thermal: core: Move lists of thermal instances to trip descriptorsRafael J. Wysocki
In almost all places where a thermal zone's list of thermal instances is walked, there is a check to match a specific trip point and it is walked in vain whenever there are no cooling devices associated with the given trip. To address this, store the lists of thermal instances in trip point descriptors instead of storing them in thermal zones and adjust all code using those lists accordingly. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/5522726.Sb9uPGUboI@rjwysocki.net Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
2024-10-22thermal: core: Drop need_update field from struct thermal_zone_deviceRafael J. Wysocki
After previous changes, the need_update field in struct thermal_zone_device is only set and never read, so drop it. No functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/2495061.jE0xQCEvom@rjwysocki.net Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
2024-10-22thermal: core: Update thermal zones after cooling device bindingRafael J. Wysocki
If a new cooling device is registered and it is bound to at least one trip point in a given thermal zone, that thermal zone needs to be updated via __thermal_zone_device_update(). Instead of doing this with the help of the need_update atomic field in struct thermal_zone_device, which is not particularly straightforward, make __thermal_zone_cdev_bind() return a bool value indicating whether or not the given thermal zone needs to be updated because a new cooling device has been bound to it and update thermal_zone_cdev_bind() to call __thermal_zone_device_update() when this value is "true". No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/2226302.Icojqenx9y@rjwysocki.net Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
2024-10-22thermal: core: Consolidate thermal zone locking in the exit pathRafael J. Wysocki
In analogy with a previous change in the thermal zone initialization path, to avoid acquiring the thermal zone lock and releasing it multiple times back and forth unnecessarily, move all of the code running under thermal_list_lock in thermal_zone_device_unregister() into a new function called thermal_zone_exit() and make the latter acquire the thermal zone lock only once and release it along with thermal_list_lock. For this purpose, provide an "unlocked" variant of thermal_zone_cdev_unbind() to be called by thermal_zone_exit() under the thermal zone lock. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/1963152.taCxCBeP46@rjwysocki.net Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
2024-10-22thermal: core: Mark thermal zones as exiting before unregistrationRafael J. Wysocki
In analogy with a previous change in the thermal zone registration code path, to ensure that __thermal_zone_device_update() will return early for thermal zones that are going away, introduce a thermal zone state flag representing the "exit" state and set it while deleting the thermal zone from thermal_tz_list. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/4394176.ejJDZkT8p0@rjwysocki.net Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
2024-10-22thermal: core: Consolidate thermal zone locking during initializationRafael J. Wysocki
The part of thermal zone initialization carried out under thermal_list_lock acquires the thermal zone lock and releases it multiple times back and forth which is not really necessary. Instead of doing this, make it acquire the thermal zone lock once after acquiring thermal_list_lock and release it along with that lock. For this purpose, move all of the code in question to thermal_zone_init_complete() introduced previously and provide an "unlocked" variant of thermal_zone_cdev_bind() to be invoked from there. Also notice that a thermal zone does not need to be added to thermal_tz_list under its own lock, so make the new code acquire the thermal zone lock after adding it to the list. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/1920382.CQOukoFCf9@rjwysocki.net Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> [ rjw: Rebase on top of recent thermal core changes ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-10-22thermal: core: Fix race between zone registration and system suspendRafael J. Wysocki
If the registration of a thermal zone takes place at the time when system suspend is started, thermal_pm_notify() can run before the new thermal zone is added to thermal_tz_list and its "suspended" flag will not be set. Consequently, if __thermal_zone_device_update() is called for that thermal zone, it will not return early as expected which may cause some destructive interference with the system suspend or resume flow to occur. To avoid that, make thermal_zone_init_complete() introduced previously set the "suspended" flag for new thermal zones if it runs during system suspend or resume. Fixes: 4e814173a8c4 ("thermal: core: Fix thermal zone suspend-resume synchronization") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/8490245.NyiUUSuA9g@rjwysocki.net Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
2024-10-22thermal: core: Mark thermal zones as initializing to start withRafael J. Wysocki
After thermal_zone_device_register_with_trips() has called device_register() and it has registered the new thermal zone device with the driver core, user space may access its sysfs attributes and, among other things, it may enable the thermal zone before it is ready. To address this, introduce a new thermal zone state flag for initialization and set it before calling device_register() in thermal_zone_device_register_with_trips(). This causes __thermal_zone_device_update() to return early until the new flag is cleared. To clear it when the thermal zone is ready, introduce a new function called thermal_zone_init_complete() that will also invoke __thermal_zone_device_update() after clearing that flag (both under the thernal zone lock) and make thermal_zone_device_register_with_trips() call the new function instead of checking need_update and calling thermal_zone_device_update() when it is set. After this change, if user space enables the thermal zone prematurely, __thermal_zone_device_update() will return early for it until thermal_zone_init_complete() is called. In turn, if the thermal zone is not enabled by user space before thermal_zone_init_complete() is called, the __thermal_zone_device_update() call in it will return early because the thermal zone has not been enabled yet, but that function will be invoked again by thermal_zone_device_set_mode() when the thermal zone is enabled and it will not return early this time. The checking of need_update is not necessary any more because the __thermal_zone_device_update() calls potentially triggered by cooling device binding take place before calling thermal_zone_init_complete(), so they all will return early, which means that thermal_zone_init_complete() must call __thermal_zone_device_update() in case the thermal zone is enabled prematurely by user space. Fixes: 203d3d4aa482 ("the generic thermal sysfs driver") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/9360231.CDJkKcVGEf@rjwysocki.net Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
2024-10-22thermal: core: Represent suspend-related thermal zone flags as bitsRafael J. Wysocki
Instead of using two separate fields in struct thermal_zone_device for representing flags related to thermal zone suspend, represent them explicitly as bits in one u8 "state" field. Subsequently, that field will be used for addressing race conditions related to thermal zone initialization and exit. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/7733910.EvYhyI6sBW@rjwysocki.net Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
2024-10-22thermal: core: Rearrange PM notification codeRafael J. Wysocki
Move the code run for each thermal zone by the thermal PM notify handler to separate functions. This will help to make some subsequent changes look somewhat more straightforward, among other things. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/2299090.iZASKD2KPV@rjwysocki.net Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
2024-10-22thermal: core: Initialize thermal zones before registering themRafael J. Wysocki
Since user space can start interacting with a new thermal zone as soon as device_register() called by thermal_zone_device_register_with_trips() returns, it is better to initialize the thermal zone before calling device_register() on it. Fixes: d0df264fbd3c ("thermal/core: Remove pointless thermal_zone_device_reset() function") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/3336146.44csPzL39Z@rjwysocki.net Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
2024-10-11Merge tag 'pm-6.12-rc3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull power management fixes from Rafael Wysocki: "These address two issues in the TPMI module of the Intel RAPL power capping driver and one issue in the processor part of the Intel int340x thermal driver, update a CPU ID list and register definitions needed for RAPL PL4 support and remove some unused code. Specifics: - Fix the TPMI_RAPL_REG_DOMAIN_INFO register offset in the TPMI part of the Intel RAPL power capping driver, make it ignore minor hardware version mismatches (which only indicate exposing additional features) and update register definitions in it to enable PL4 support (Zhang Rui) - Add Arrow Lake-U to the list of processors supporting PL4 in the MSR part of the Intel RAPL power capping driver (Sumeet Pawnikar) - Remove excess pci_disable_device() calls from the processor part of the int340x thermal driver to address a warning triggered during module unload and remove unused CPU hotplug code related to RAPL support from it (Zhang Rui)" * tag 'pm-6.12-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: thermal: intel: int340x: processor: Add MMIO RAPL PL4 support thermal: intel: int340x: processor: Remove MMIO RAPL CPU hotplug support powercap: intel_rapl_msr: Add PL4 support for Arrowlake-U powercap: intel_rapl_tpmi: Ignore minor version change thermal: intel: int340x: processor: Fix warning during module unload powercap: intel_rapl_tpmi: Fix bogus register reading
2024-10-11Merge tag 'thermal-6.12-rc3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull thermal control fixes from Rafael Wysocki: "Address possible use-after-free scenarios during the processing of thermal netlink commands and during thermal zone removal (Rafael Wysocki)" * tag 'thermal-6.12-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: thermal: core: Free tzp copy along with the thermal zone thermal: core: Reference count the zone in thermal_zone_get_by_id()
2024-10-10thermal: core: Connect the threshold with the coreDaniel Lezcano
Initialize, de-initialize and handle the threshold in the same place than the trip points. Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://patch.msgid.link/20240923100005.2532430-3-daniel.lezcano@linaro.org [ rjw: Subject edit ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-10-10thermal: core: Add user thresholds supportDaniel Lezcano
The user thresholds mechanism is a way to have the userspace to tell the thermal framework to send a notification when a temperature limit is crossed. There is no id, no hysteresis, just the temperature and the direction of the limit crossing. That means we can be notified when a threshold is crossed the way up only, or the way down only or both ways. That allows to create hysteresis values if it is needed. A threshold can be added, deleted or flushed. The latter means all thresholds belonging to a thermal zone will be deleted. When a threshold is added: - if the same threshold (temperature and direction) exists, an error is returned - if a threshold is specified with the same temperature but a different direction, the specified direction is added - if there is no threshold with the same temperature then it is created When a threshold is deleted: - if the same threshold (temperature and direction) exists, it is deleted - if a threshold is specified with the same temperature but a different direction, the specified direction is removed - if there is no threshold with the same temperature, then an error is returned When the threshold are flushed: - All thresholds related to a thermal zone are deleted When a threshold is crossed: - the userspace does not need to know which threshold(s) have been crossed, it will be notified with the current temperature and the previous temperature - if multiple thresholds have been crossed between two updates only one notification will be send to the userspace, it is pointless to send a notification per thresholds crossed as the userspace can handle that easily when it has the temperature delta information Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://patch.msgid.link/20240923100005.2532430-2-daniel.lezcano@linaro.org [ rjw: Subject edit, use BIT(0) and BIT(1) in symbol definitions ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-10-08thermal: intel: int340x: processor: Add MMIO RAPL PL4 supportZhang Rui
Similar to the MSR RAPL interface, MMIO RAPL supports PL4 too, so add MMIO RAPL PL4d support to the processor_thermal driver. As a result, the powercap sysfs for MMIO RAPL will show a new "peak power" constraint. Signed-off-by: Zhang Rui <rui.zhang@intel.com> Reviewed-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Link: https://patch.msgid.link/20240930081801.28502-7-rui.zhang@intel.com [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-10-08thermal: intel: int340x: processor: Remove MMIO RAPL CPU hotplug supportZhang Rui
CPU0/package0 is always online and the MMIO RAPL driver runs on single package systems only, so there is no need to handle CPU hotplug in it. Always register a RAPL package device for package 0 and remove the unnecessary CPU hotplug support. Signed-off-by: Zhang Rui <rui.zhang@intel.com> Reviewed-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Link: https://patch.msgid.link/20240930081801.28502-6-rui.zhang@intel.com [ rjw: Subject edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-10-07thermal: intel: int340x: processor: Fix warning during module unloadZhang Rui
The processor_thermal driver uses pcim_device_enable() to enable a PCI device, which means the device will be automatically disabled on driver detach. Thus there is no need to call pci_disable_device() again on it. With recent PCI device resource management improvements, e.g. commit f748a07a0b64 ("PCI: Remove legacy pcim_release()"), this problem is exposed and triggers the warining below. [ 224.010735] proc_thermal_pci 0000:00:04.0: disabling already-disabled device [ 224.010747] WARNING: CPU: 8 PID: 4442 at drivers/pci/pci.c:2250 pci_disable_device+0xe5/0x100 ... [ 224.010844] Call Trace: [ 224.010845] <TASK> [ 224.010847] ? show_regs+0x6d/0x80 [ 224.010851] ? __warn+0x8c/0x140 [ 224.010854] ? pci_disable_device+0xe5/0x100 [ 224.010856] ? report_bug+0x1c9/0x1e0 [ 224.010859] ? handle_bug+0x46/0x80 [ 224.010862] ? exc_invalid_op+0x1d/0x80 [ 224.010863] ? asm_exc_invalid_op+0x1f/0x30 [ 224.010867] ? pci_disable_device+0xe5/0x100 [ 224.010869] ? pci_disable_device+0xe5/0x100 [ 224.010871] ? kfree+0x21a/0x2b0 [ 224.010873] pcim_disable_device+0x20/0x30 [ 224.010875] devm_action_release+0x16/0x20 [ 224.010878] release_nodes+0x47/0xc0 [ 224.010880] devres_release_all+0x9f/0xe0 [ 224.010883] device_unbind_cleanup+0x12/0x80 [ 224.010885] device_release_driver_internal+0x1ca/0x210 [ 224.010887] driver_detach+0x4e/0xa0 [ 224.010889] bus_remove_driver+0x6f/0xf0 [ 224.010890] driver_unregister+0x35/0x60 [ 224.010892] pci_unregister_driver+0x44/0x90 [ 224.010894] proc_thermal_pci_driver_exit+0x14/0x5f0 [processor_thermal_device_pci] ... [ 224.010921] ---[ end trace 0000000000000000 ]--- Remove the excess pci_disable_device() calls. Fixes: acd65d5d1cf4 ("thermal/drivers/int340x/processor_thermal: Add PCI MMIO based thermal driver") Signed-off-by: Zhang Rui <rui.zhang@intel.com> Reviewed-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Link: https://patch.msgid.link/20240930081801.28502-3-rui.zhang@intel.com [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-10-04thermal/ti-soc-thermal: Fix typosAndrew Kreimer
Fix typos in comments. Reported-by: Matthew Wilcox <willy@infradead.org> Signed-off-by: Andrew Kreimer <algonell@gmail.com> Link: https://lore.kernel.org/r/20240913093713.12376-1-algonell@gmail.com Signed-off-by: Kevin Hilman <khilman@baylibre.com>
2024-10-04thermal: core: Free tzp copy along with the thermal zoneRafael J. Wysocki
The object pointed to by tz->tzp may still be accessed after being freed in thermal_zone_device_unregister(), so move the freeing of it to the point after the removal completion has been completed at which it cannot be accessed any more. Fixes: 3d439b1a2ad3 ("thermal/core: Alloc-copy-free the thermal zone parameters structure") Cc: 6.8+ <stable@vger.kernel.org> # 6.8+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Link: https://patch.msgid.link/4623516.LvFx2qVVIh@rjwysocki.net
2024-10-04thermal: core: Reference count the zone in thermal_zone_get_by_id()Rafael J. Wysocki
There are places in the thermal netlink code where nothing prevents the thermal zone object from going away while being accessed after it has been returned by thermal_zone_get_by_id(). To address this, make thermal_zone_get_by_id() get a reference on the thermal zone device object to be returned with the help of get_device(), under thermal_list_lock, and adjust all of its callers to this change with the help of the cleanup.h infrastructure. Fixes: 1ce50e7d408e ("thermal: core: genetlink support for events/cmd/sampling") Cc: 6.8+ <stable@vger.kernel.org> # 6.8+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Link: https://patch.msgid.link/6112242.lOV4Wx5bFT@rjwysocki.net
2024-10-02move asm/unaligned.h to linux/unaligned.hAl Viro
asm/unaligned.h is always an include of asm-generic/unaligned.h; might as well move that thing to linux/unaligned.h and include that - there's nothing arch-specific in that header. auto-generated by the following: for i in `git grep -l -w asm/unaligned.h`; do sed -i -e "s/asm\/unaligned.h/linux\/unaligned.h/" $i done for i in `git grep -l -w asm-generic/unaligned.h`; do sed -i -e "s/asm-generic\/unaligned.h/linux\/unaligned.h/" $i done git mv include/asm-generic/unaligned.h include/linux/unaligned.h git mv tools/include/asm-generic/unaligned.h tools/include/linux/unaligned.h sed -i -e "/unaligned.h/d" include/asm-generic/Kbuild sed -i -e "s/__ASM_GENERIC/__LINUX/" include/linux/unaligned.h tools/include/linux/unaligned.h
2024-09-27[tree-wide] finally take no_llseek outAl Viro
no_llseek had been defined to NULL two years ago, in commit 868941b14441 ("fs: remove no_llseek") To quote that commit, At -rc1 we'll need do a mechanical removal of no_llseek - git grep -l -w no_llseek | grep -v porting.rst | while read i; do sed -i '/\<no_llseek\>/d' $i done would do it. Unfortunately, that hadn't been done. Linus, could you do that now, so that we could finally put that thing to rest? All instances are of the form .llseek = no_llseek, so it's obviously safe. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2024-09-10Merge tag 'thermal-v6.12-rc1' of ↵Rafael J. Wysocki
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/thermal/linux into Merge thermal drivers changes for v6.12-rc1 from Daniel Lezcano: "- Add power domain DT bindings for new Amlogic SoCs (Georges Stark) - Switch from CONFIG_PM_SLEEP guards to pm_sleep_ptr() in the ST driver and add a Kconfig dependency on THERMAL_OF subsystem for the STi driver (Raphael Gallais-Pou) - Simplify with dev_err_probe() the error code path in the probe functions for the brcmstb driver (Yan Zhen) - Remove trailing space after \n newline in the Renesas driver (Colin Ian King) - Add DT binding compatible string for the SA8255p with the tsens driver (Nikunj Kela) - Use the devm_clk_get_enabled() helpers to simplify the init routine in the sprd driver (Huan Yang) - Remove __maybe_unused notations for the functions by using the new RUNTIME_PM_OPS() and SYSTEM_SLEEP_PM_OPS() macros on the IMx and Qoriq drivers (Fabio Estevam) - Remove unused declarations in the header file as the functions were removed in a previous change on the ti-soc-thermal driver (Zhang Zekun) - Simplify with dev_err_probe() the error code path in the probe functions for the imx_sc_thermal driver (Alexander Stein)" * tag 'thermal-v6.12-rc1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/thermal/linux: thermal/drivers/imx_sc_thermal: Use dev_err_probe thermal/drivers/ti-soc-thermal: Remove unused declarations thermal/drivers/imx: Remove __maybe_unused notations thermal/drivers/qoriq: Remove __maybe_unused notations thermal/drivers/sprd: Use devm_clk_get_enabled() helpers dt-bindings: thermal: tsens: document support on SA8255p thermal/drivers/renesas: Remove trailing space after \n newline thermal/drivers/brcmstb_thermal: Simplify with dev_err_probe() thermal/drivers/sti: Depend on THERMAL_OF subsystem thermal/drivers/st: Switch from CONFIG_PM_SLEEP guards to pm_sleep_ptr() dt-bindings: thermal: amlogic,thermal: add optional power-domains
2024-09-09Merge branch 'thermal-core'Rafael J. Wysocki
Merge thermal core fixes and cleanups for 6.12: - Refuse to accept trip point temperature or hysteresis that would lead to an invalid threshold value when setting them via sysfs (Rafael Wysocki). - Adjust states of all uninitialized instances in the .manage() callback of the Bang-bang thermal governor (Rafael Wysocki). - Drop a couple of redundant checks along with the code depending on them from the thermal core (Rafael Wysocki). - Rearrange the thermal core to avoid redundant checks and simplify control flow in a couple of code paths (Rafael Wysocki). * thermal-core: thermal: core: Drop thermal_zone_device_is_enabled() thermal: core: Check passive delay in monitor_thermal_zone() thermal: core: Drop dead code from monitor_thermal_zone() thermal: core: Drop redundant lockdep_assert_held() thermal: gov_bang_bang: Adjust states of all uninitialized instances thermal: sysfs: Add sanity checks for trip temperature and hysteresis
2024-09-05thermal: core: Drop thermal_zone_device_is_enabled()Rafael J. Wysocki
There are only two callers of thermal_zone_device_is_enabled() and one of them call is under the zone lock and the other one uses lockdep_assert_held() on that lock. Thus the lockdep_assert_held() in thermal_zone_device_is_enabled() is redundant and it could be dropped, but then the function would merely become a wrapper around a simple tz->mode check that is more convenient to do directly. Accordingly, drop thermal_zone_device_is_enabled() altogether and update its callers to check tz->mode directly as appropriate. While at it, combine the tz->mode and tz->suspended checks in __thermal_zone_device_update() because they are of a similar category and if any of them evaluates to "true", the outcome is the same. No intentinal functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/9353673.CDJkKcVGEf@rjwysocki.net
2024-09-05thermal: core: Check passive delay in monitor_thermal_zone()Rafael J. Wysocki
The only case in which thermal_zone_device_set_polling() is called with its second argument equal to zero is when passive cooling is under way and passive_delay_jiffies is 0, which only happens when the given thermal zone is not polled at all. If monitor_thermal_zone() is modified to check passive_delay_jiffies directly, the check of the thermal_zone_device_set_polling() second argument against 0 can be dropped and a passive_delay check can be dropped from thermal_zone_device_register_with_trips(), so change the code accordingly. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/2004353.PYKUYFuaPT@rjwysocki.net
2024-09-05thermal: core: Drop dead code from monitor_thermal_zone()Rafael J. Wysocki
Since monitor_thermal_zone() is only called when the given thermal zone has been enabled, as per the thermal_zone_device_is_enabled() check in __thermal_zone_device_update(), the tz->mode check in it always evaluates to "false" and the thermal_zone_device_set_polling() invocation depending on it is dead code, so drop it. No functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/10547425.nUPlyArG6x@rjwysocki.net
2024-09-05thermal: core: Drop redundant lockdep_assert_held()Rafael J. Wysocki
Along the lines of commit 24aad192c671 ("thermal: core: Drop redundant checks from thermal_bind_cdev_to_trip()") notice that thermal_unbind_cdev_from_trip() is only called by thermal_zone_cdev_unbind() under the thermal zone lock, so it need not use lockdep_assert_held() for that lock. No functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/3341369.44csPzL39Z@rjwysocki.net