- 04 Aug, 2020 1 commit
-
-
Sumeet Pawnikar authored
Add LP (Low Power) PCH id for Cannon Lake (CNL) based platforms. Signed-off-by:
Sumeet Pawnikar <sumeet.r.pawnikar@intel.com> Signed-off-by:
Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/1596097503-27924-1-git-send-email-sumeet.r.pawnikar@intel.com
-
- 31 Jul, 2020 2 commits
-
-
Henry Yen authored
This patch adds full support for ver 2 thermal system (e.g., MT7622 SoC). The new changes include reading calibration data, converting temperature and hardware initialization which are specific for version 2 system. Each platform decides which function to call according to its version. Fixes: 3966be3c ("thermal: mediatek: add support for MT7622 SoC") Signed-off-by:
Henry Yen <henry.yen@mediatek.com> Reviewed-by:
Matthias Brugger <matthias.bgg@gmail.com> Tested-By:
Frank Wunderlich <frank-w@public-files.de> Signed-off-by:
-
Henry Yen authored
It is known that Mediatek owns two thermal systems, which only differ in the way of reading calibration data and converting temperature. MT8173, MT8183, MT2701 and MT2712 belongs to version 1 thermal system, and MT7622 belongs to version 2. In order to handle both systems, the suffix _V1 is appended to the current code, and then the second patch will add _V2 functions with the same purpose but different implementation. Signed-off-by:
-
- 30 Jul, 2020 1 commit
-
-
Lukasz Luba authored
Update the license to the SPDX licensing format. Signed-off-by:
Lukasz Luba <lukasz.luba@arm.com> Signed-off-by:
-
- 29 Jul, 2020 2 commits
-
-
Lukas Bulwahn authored
Commit 0015d9a2 ("thermal/governors: Prefix all source files with gov_") renamed power_allocator.c to gov_power_allocator.c in ./drivers/thermal amongst some other file renames, but missed to adjust the MAINTAINERS entry. Hence, ./scripts/get_maintainer.pl --self-test=patterns complains: warning: no file matches F: drivers/thermal/power_allocator.c Update the file entry in MAINTAINERS to the new file name. Signed-off-by:
Lukas Bulwahn <lukas.bulwahn@gmail.com> Acked-by:
Amit Kucheria <amit.kucheria@linaro.org> Signed-off-by:
-
Daniel Lezcano authored
Now the calls to enable/disable a thermal zone are centralized in a call to a function, we can add in these the corresponding netlink notifications. Signed-off-by:
Zhang Rui <rui.zhang@intel.com> Reviewed-by:
-
- 27 Jul, 2020 2 commits
-
-
Shawn Guo authored
The TSENS integrated on MSM8939 is a v0_1 device with 10 sensors. Different from its predecessor MSM8916, where 'calib_sel' bits sit in separate qfprom word, MSM8939 has 'cailb' and 'calib_sel' bits mixed and spread on discrete offsets. That's why all qfprom bits are read as one go and later mapped to calibration data for MSM8939. Signed-off-by:
Shawn Guo <shawn.guo@linaro.org> Acked-by:
Konrad Dybcio <konradybcio@gmail.com> Signed-off-by:
-
Konrad Dybcio authored
It adds compatible for MSM8939 TSENS device. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
- 24 Jul, 2020 2 commits
-
-
Thierry Reding authored
When a thermal zone is looked up by an ID and no zone is found matching that ID, the thermal_zone_get_by_id() function will return a pointer to the thermal zone list head which isn't actually a valid thermal zone. This can lead to a subsequent crash because a valid pointer is returned to the called, but dereferencing that pointer as struct thermal_zone is not safe. Fixes: 329b064f ("thermal: core: Get thermal zone by id") Signed-off-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
-
Sumeet Pawnikar authored
Update PCI device id for Jasper Lake processor thermal device. With this proc_thermal driver is getting loaded and processor thermal functionality works on Jasper Lake system. Fixes: f64a6583 ("thermal: int340x: processor_thermal: Add Jasper Lake support") Signed-off-by:
-
- 21 Jul, 2020 12 commits
-
-
Anson Huang authored
Add a missing MODULE_DEVICE_TABLE entry to support module autoloading. Signed-off-by:
Anson Huang <Anson.Huang@nxp.com> Reviewed-by:
Dong Aisheng <aisheng.dong@nxp.com> Signed-off-by:
-
Dan Carpenter authored
This condition is reversed and will cause breakage. Fixes: 7440f518 ("thermal/drivers/ti-soc-thermal: Avoid dereferencing ERR_PTR") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Lukasz Luba authored
Add entry for ARM Intelligent Power Allocation - thermal governor. Signed-off-by:
-
Niklas Söderlund authored
The function rcar_gen3_thermal_calc_coefs() takes an argument called 'thcode' which shadows the static global 'thcode' variable. This is not harmful but bad for readability and is harmful for planned changes to the driver. The THCODE values should be read from hardware fuses if they are available and only fallback to the global 'thcode' variable if they are not fused. Rename the global 'thcode' variable to 'thcodes' to avoid shadowing the symbol in functions that take it as an argument. Signed-off-by:
Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
-
Amit Kucheria authored
Now that we have yaml bindings for the thermal subsystem, get rid of the old bindings (thermal.txt). Replace all references to thermal.txt in the Documentation with a link to the appropriate YAML bindings using the following search and replace pattern: - If the reference is specific to the thermal-sensor-cells property, replace with a pointer to thermal-sensor.yaml - If the reference is to the cooling-cells property, replace with a pointer to thermal-cooling-devices.yaml - If the reference is generic thermal bindings, replace with a reference to thermal*.yaml. Signed-off-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
-
Daniel Lezcano authored
The generic netlink is initialized at subsys_initcall, so far after the thermal init routine and the thermal generic netlink family initialization. On ŝome platforms, that leads to a memory corruption. The fix was sent to netdev@ to move the genetlink framework initialization at core_initcall. Move the thermal core initialization to postcore level which is very close to core level. Reported-by:
Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by:
-
Daniel Lezcano authored
The initcalls like to play joke. In our case, the thermal-netlink initcall is called after the thermal-core initcall but this one sends a notification before the former is initialized. No issue was spotted, but it could lead to a memory corruption, so instead of relying on the core_initcall for the thermal-netlink, let's initialize directly from the thermal-core init routine, so we have full control of the init ordering. Reported-by:
-
Daniel Lezcano authored
The generic netlink is initialized far after the netlink protocol itself at subsys_initcall. The devlink is initialized at the same level, but after, as shown by a disassembly of the vmlinux: [ ... ] 374 ffff8000115f22c0 <__initcall_devlink_init4>: 375 ffff8000115f22c4 <__initcall_genl_init4>: [ ... ] The function devlink_init() calls genl_register_family() before the generic netlink subsystem is initialized. As the generic netlink initcall level is set since 2005, it seems that was not a problem, but now we have the thermal framework initialized at the core_initcall level which creates the generic netlink family and sends a notification which leads to a subtle memory corruption only detectable when the CONFIG_INIT_ON_ALLOC_DEFAULT_ON option is set with the earlycon at init time. The thermal framework needs to be initialized early in order to begin the mitigation as soon as possible. Moving it to postcore_initcall is acceptable. This patch changes the initialization level for the generic netlink family to the core_initcall and comes after the netlink protocol initialization. Signed-off-by:
David S. Miller <davem@davemloft.net> Tested-by:
-
Marian-Cristian Rotariu authored
Add r8a774e1 specific compatible string. Signed-off-by:
Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com> Signed-off-by:
Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by:
-
Amit Kucheria authored
clock_cooling has no in-kernel users. It has never found any use in drivers as far as I can tell. Remove the code. Signed-off-by:
-
Colin Ian King authored
The variable ret is being initialized with a value that is never read and it is being updated later with a new value. The initialization is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by:Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Daniel Lezcano authored
When the network is not configured, the netlink is disabled on all the system. The thermal framework assumed the netlink is always opt-in. Fix this by adding a Kconfig option for the netlink notification, defaulting to yes and depending on CONFIG_NET. As the change implies multiple stubs and in order to not pollute the internal thermal header, the thermal_nelink.h has been added and included in the thermal_core.h, so this one regain some kind of clarity. Reported-by:
Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
-
- 07 Jul, 2020 4 commits
-
-
Daniel Lezcano authored
The generic netlink protocol is implemented but the different notification functions are not yet connected to the core code. These changes add the notification calls in the different corresponding places. Reviewed-by:
-
Daniel Lezcano authored
Initially the thermal framework had a very simple notification mechanism to send generic netlink messages to the userspace. The notification function was never called from anywhere and the corresponding dead code was removed. It was probably a first attempt to introduce the netlink notification. At LPC2018, the presentation "Linux thermal: User kernel interface", proposed to create the notifications to the userspace via a kfifo. The advantage of the kfifo is the performance. It is usually used from a 1:1 communication channel where a driver captures data and sends it as fast as possible to a userspace process. The drawback is that only one process uses the notification channel exclusively, thus no other process is allowed to use the channel to get temperature or notifications. This patch defines a generic netlink API to discover the current thermal setup and adds event notifications as well as temperature sampling. As any genetlink protocol, it can evolve and the versioning allows to keep the backward compatibility. In order to prevent the user from getting flooded with data on a single channel, there are two multicast channels, one for the temperature sampling when the thermal zone is updated and another one for the events, so the user can get the events only without the thermal zone temperature sampling. Also, a list of commands to discover the thermal setup is added and can be extended when needed. Reviewed-by:
-
Daniel Lezcano authored
The next patch will introduce the generic netlink protocol to handle events, sampling and command from the thermal framework. In order to deal with the thermal zone, it uses its unique identifier to characterize it in the message. Passing an integer is more efficient than passing an entire string. This change provides a function returning back a thermal zone pointer corresponding to the identifier passed as parameter. Signed-off-by:
-
Daniel Lezcano authored
The cdev, tz and governor list, as well as their respective locks are statically defined in the thermal_core.c file. In order to give a sane access to these list, like browsing all the thermal zones or all the cooling devices, let's define a set of helpers where we pass a callback as a parameter to be called for each thermal entity. We keep the self-encapsulation and ensure the locks are correctly taken when looking at the list. Acked-by:
-
- 06 Jul, 2020 3 commits
-
-
Andrzej Pietrasiewicz authored
This function is not needed by drivers. Signed-off-by:
Andrzej Pietrasiewicz <andrzej.p@collabora.com> Signed-off-by:
-
Andrzej Pietrasiewicz authored
Use driver's local data to evaluate the need to run or not to run a measurement. Signed-off-by:
-
Andrzej Pietrasiewicz authored
thermal_zone_device_update() can now handle disabled thermal zones, so the check here is not needed. Signed-off-by:
-
- 29 Jun, 2020 11 commits
-
-
Andrzej Pietrasiewicz authored
set_mode() is only called when tzd's mode is about to change. Actual setting is performed in thermal_core, in thermal_zone_device_set_mode(). The meaning of set_mode() callback is actually to notify the driver about the mode being changed and giving the driver a chance to oppose such change. To better reflect the purpose of the method rename it to change_mode() Signed-off-by:
Peter Kaestle <peter@piie.net> Reviewed-by:
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Reviewed-by:
-
Andrzej Pietrasiewicz authored
Setting polling_delay is now done at thermal_core level (by not polling DISABLED devices), so no need to repeat this code. int340x: Checking for an impossible enum value is unnecessary. acpi/thermal: It only prints debug messages. Signed-off-by:
-
Andrzej Pietrasiewicz authored
Polling DISABLED devices is not desired, as all such "disabled" devices are meant to be handled by userspace. This patch introduces and uses should_stop_polling() to decide whether the device should be polled or not. Signed-off-by:
-
Andrzej Pietrasiewicz authored
Some thermal zone devices never change their state, so they should be always enabled. Signed-off-by:
-
Andrzej Pietrasiewicz authored
Use thermal_zone_device_{en|dis}able() and thermal_zone_device_is_enabled(). Consequently, all set_mode() implementations in drivers: - can stop modifying tzd's "mode" member, - shall stop taking tzd's lock, as it is taken in the helpers - shall stop calling thermal_zone_device_update() as it is called in the helpers - can assume they are called when the mode truly changes, so checks to verify that can be dropped Not providing set_mode() by a driver no longer prevents the core from being able to set tzd's mode, so the relevant check in mode_store() is removed. Other comments: - acpi/thermal.c: tz->thermal_zone->mode will be updated only after we return from set_mode(), so use function parameter in thermal_set_mode() instead, no need to call acpi_thermal_check() in set_mode() - thermal/imx_thermal.c: regmap writes and mode assignment are done in thermal_zone_device_{en|dis}able() and set_mode() callback - thermal/intel/intel_quark_dts_thermal.c: soc_dts_{en|dis}able() are a part of set_mode() callback, so they don't need to modify tzd->mode, and don't need to fall back to the opposite mode if unsuccessful, as the return value will be propagated to thermal_zone_device_{en|dis}able() and ultimately tzd's member will not be changed in thermal_zone_device_set_mode(). - thermal/of-thermal.c: no need to set zone->mode to DISABLED in of_parse_thermal_zones() as a tzd is kzalloc'ed so mode is DISABLED anyway Signed-off-by: -
Andrzej Pietrasiewicz authored
Prepare for making the drivers not access tzd's private members. Signed-off-by:
kernel test robot <lkp@intel.com> Signed-off-by:
-
Andrzej Pietrasiewicz authored
get_mode() is now redundant, as the state is stored in struct thermal_zone_device. Consequently the "mode" attribute in sysfs can always be visible, because it is always possible to get the mode from struct tzd. Signed-off-by:
-
Andrzej Pietrasiewicz authored
Prepare for eliminating get_mode(). Signed-off-by:
-
Andrzej Pietrasiewicz authored
Prepare for changing the place where the mode is stored: now it is in drivers, which might or might not implement get_mode()/set_mode() methods. A lot of cleanup can be done thanks to storing it in struct tzd. The get_mode() methods will become redundant. Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Reviewed-by:
-
Andrzej Pietrasiewicz authored
Prepare for storing mode in struct thermal_zone_device. Signed-off-by:
-
Andrzej Pietrasiewicz authored
The acpi_thermal_register_thermal_zone() is missing any error handling. This needs to be fixed. Signed-off-by:
-
