aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/tools/perf/scripts/python/export-to-postgresql.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2020-07-31thermal: mediatek: Prepare to add support for other platformsHenry Yen1-52/+62
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: 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: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/1588238074-19338-2-git-send-email-henry.yen@mediatek.com
2020-07-30thermal: Update power allocator and devfreq cooling to SPDX licensingLukasz Luba3-25/+3
Update the license to the SPDX licensing format. Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20200730165117.13998-1-lukasz.luba@arm.com
2020-07-29MAINTAINERS: update entry to thermal governors file name prefixingLukas Bulwahn1-1/+1
Commit 0015d9a2a727 ("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 <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20200728045850.22661-1-lukas.bulwahn@gmail.com
2020-07-29thermal: core: Add thermal zone enable/disable notificationDaniel Lezcano1-0/+5
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: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Zhang Rui <rui.zhang@intel.com> Reviewed-by: Amit Kucheria <amit.kucheria@linaro.org> Link: https://lore.kernel.org/r/20200727231033.26512-1-daniel.lezcano@linaro.org
2020-07-27thermal: qcom: tsens-v0_1: Add support for MSM8939Shawn Guo3-2/+147
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: Amit Kucheria <amit.kucheria@linaro.org> Tested-by: Konrad Dybcio <konradybcio@gmail.com> /* on Asus Z00T smartphone */ Acked-by: Konrad Dybcio <konradybcio@gmail.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20200629144926.665-3-shawn.guo@linaro.org
2020-07-27dt-bindings: tsens: qcom: Document MSM8939 compatibleKonrad Dybcio1-0/+1
It adds compatible for MSM8939 TSENS device. Signed-off-by: Konrad Dybcio <konradybcio@gmail.com> Reviewed-by: Amit Kucheria <amit.kucheria@linaro.org> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Tested-by: Konrad Dybcio <konradybcio@gmail.com> /* on Asus Z00T smartphone */ Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20200629144926.665-2-shawn.guo@linaro.org
2020-07-24thermal: core: Fix thermal zone lookup by IDThierry Reding1-3/+5
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: 329b064fbd13 ("thermal: core: Get thermal zone by id") Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20200724170105.2705467-1-thierry.reding@gmail.com
2020-07-24thermal: int340x: processor_thermal: fix: update Jasper Lake PCI idSumeet Pawnikar1-1/+1
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: f64a6583d3f5 ("thermal: int340x: processor_thermal: Add Jasper Lake support") 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/1595577146-1221-1-git-send-email-sumeet.r.pawnikar@intel.com
2020-07-21thermal: imx8mm: Support module autoloadingAnson Huang1-0/+1
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: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/1592380074-19222-1-git-send-email-Anson.Huang@nxp.com
2020-07-21thermal: ti-soc-thermal: Fix reversed condition in ti_thermal_expose_sensor()Dan Carpenter1-1/+1
This condition is reversed and will cause breakage. Fixes: 7440f518dad9 ("thermal/drivers/ti-soc-thermal: Avoid dereferencing ERR_PTR") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20200616091949.GA11940@mwanda
2020-07-21MAINTAINERS: Add maintenance information for IPALukasz Luba1-0/+8
Add entry for ARM Intelligent Power Allocation - thermal governor. Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20200603141420.15274-1-lukasz.luba@arm.com
2020-07-21thermal: rcar_gen3_thermal: Do not shadow thcode variableNiklas Söderlund1-3/+3
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: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20200610003300.884258-1-niklas.soderlund+renesas@ragnatech.se
2020-07-21dt-bindings: thermal: Get rid of thermal.txt and replace referencesAmit Kucheria24-616/+34
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: Amit Kucheria <amit.kucheria@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/e9aacd33071a00568b67e110fa3bcc4d86d3e1e4.1595245166.git.amit.kucheria@linaro.org
2020-07-21thermal: core: Move initialization after core initcallDaniel Lezcano1-1/+1
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 <daniel.lezcano@linaro.org> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Amit Kucheria <amit.kucheria@linaro.org> Link: https://lore.kernel.org/r/20200717164217.18819-2-daniel.lezcano@linaro.org
2020-07-21thermal: netlink: Improve the initcall orderingDaniel Lezcano3-2/+11
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: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Amit Kucheria <amit.kucheria@linaro.org> Link: https://lore.kernel.org/r/20200717164217.18819-1-daniel.lezcano@linaro.org
2020-07-21net: genetlink: Move initialization to core_initcallDaniel Lezcano1-1/+1
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: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: David S. Miller <davem@davemloft.net> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Amit Kucheria <amit.kucheria@linaro.org> Link: https://lore.kernel.org/r/20200715074120.8768-1-daniel.lezcano@linaro.org
2020-07-21thermal: rcar_gen3_thermal: Add r8a774e1 supportMarian-Cristian Rotariu1-0/+4
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: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/1594811350-14066-4-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com
2020-07-21thermal/drivers/clock_cooling: Remove clock_cooling codeAmit Kucheria4-515/+0
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: Amit Kucheria <amit.kucheria@linaro.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/aa5d5ac2589cf7b14ece882130731b4a916849a6.1593619943.git.amit.kucheria@linaro.org
2020-07-21thermal: core: remove redundant initialization of variable retColin Ian King1-1/+1
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: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20200706140747.489075-1-colin.king@canonical.com
2020-07-21thermal: netlink: Fix compilation error when CONFIG_NET=nDaniel Lezcano4-19/+114
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: Daniel Lezcano <daniel.lezcano@linaro.org> Reviewed-by: Amit Kucheria <amit.kucheria@linaro.org> Link: https://lore.kernel.org/r/20200707090159.1018-1-daniel.lezcano@linaro.org
2020-07-07thermal: core: Add notifications call in the frameworkDaniel Lezcano3-3/+46
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: Amit Kucheria <amit.kucheria@linaro.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Zhang Rui <rui.zhang@intel.com> Link: https://lore.kernel.org/r/20200706105538.2159-4-daniel.lezcano@linaro.org
2020-07-07thermal: core: genetlink support for events/cmd/samplingDaniel Lezcano5-35/+739
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: Amit Kucheria <amit.kucheria@linaro.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Zhang Rui <rui.zhang@intel.com> Link: https://lore.kernel.org/r/20200706105538.2159-3-daniel.lezcano@linaro.org
2020-07-07thermal: core: Get thermal zone by idDaniel Lezcano2-0/+16
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 <daniel.lezcano@linaro.org> Reviewed-by: Amit Kucheria <amit.kucheria@linaro.org> Acked-by: Zhang Rui <rui.zhang@intel.com> Link: https://lore.kernel.org/r/20200706105538.2159-2-daniel.lezcano@linaro.org
2020-07-07thermal: core: Add helpers to browse the cdev, tz and governor listDaniel Lezcano2-0/+60
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: Zhang Rui <rui.zhang@intel.com> Reviewed-by: Amit Kucheria <amit.kucheria@linaro.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20200706105538.2159-1-daniel.lezcano@linaro.org
2020-07-07thermal: Make thermal_zone_device_is_enabled() available to core onlyAndrzej Pietrasiewicz3-6/+2
This function is not needed by drivers. Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20200703104354.19657-4-andrzej.p@collabora.com
2020-07-07thermal: imx: Use driver's local data to decide whether to run a measurementAndrzej Pietrasiewicz1-3/+4
Use driver's local data to evaluate the need to run or not to run a measurement. Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20200703104354.19657-3-andrzej.p@collabora.com
2020-07-07acpi: thermal: Don't call thermal_zone_device_is_enabled()Andrzej Pietrasiewicz1-3/+0
thermal_zone_device_update() can now handle disabled thermal zones, so the check here is not needed. Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20200703104354.19657-2-andrzej.p@collabora.com
2020-06-29thermal: Rename set_mode() to change_mode()Andrzej Pietrasiewicz6-16/+16
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: Andrzej Pietrasiewicz <andrzej.p@collabora.com> [for acerhdf] Acked-by: Peter Kaestle <peter@piie.net> Reviewed-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Reviewed-by: Amit Kucheria <amit.kucheria@linaro.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20200629122925.21729-12-andrzej.p@collabora.com
2020-06-29thermal: Simplify or eliminate unnecessary set_mode() methodsAndrzej Pietrasiewicz6-87/+0
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 <andrzej.p@collabora.com> [for acerhdf] Acked-by: Peter Kaestle <peter@piie.net> Reviewed-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Reviewed-by: Amit Kucheria <amit.kucheria@linaro.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20200629122925.21729-11-andrzej.p@collabora.com
2020-06-29thermal: core: Stop polling DISABLED thermal devicesAndrzej Pietrasiewicz1-2/+14
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 <andrzej.p@collabora.com> Reviewed-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Reviewed-by: Amit Kucheria <amit.kucheria@linaro.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20200629122925.21729-10-andrzej.p@collabora.com
2020-06-29thermal: Explicitly enable non-changing thermal zone devicesAndrzej Pietrasiewicz14-4/+87
Some thermal zone devices never change their state, so they should be always enabled. Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com> Reviewed-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20200629122925.21729-9-andrzej.p@collabora.com
2020-06-29thermal: Use mode helpers in driversAndrzej Pietrasiewicz13-98/+80
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 <andrzej.p@collabora.com> [for acerhdf] Acked-by: Peter Kaestle <peter@piie.net> Reviewed-by: Amit Kucheria <amit.kucheria@linaro.org> Reviewed-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20200629122925.21729-8-andrzej.p@collabora.com
2020-06-29thermal: Add mode helpersAndrzej Pietrasiewicz2-0/+66
Prepare for making the drivers not access tzd's private members. Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com> Reviewed-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> [staticize thermal_zone_device_set_mode()] Signed-off-by: kernel test robot <lkp@intel.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20200629122925.21729-7-andrzej.p@collabora.com
2020-06-29thermal: remove get_mode() operation of driversAndrzej Pietrasiewicz11-119/+3
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 <andrzej.p@collabora.com> [for acerhdf] Acked-by: Peter Kaestle <peter@piie.net> Reviewed-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Reviewed-by: Amit Kucheria <amit.kucheria@linaro.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20200629122925.21729-6-andrzej.p@collabora.com
2020-06-29thermal: Store device mode in struct thermal_zone_deviceAndrzej Pietrasiewicz8-71/+44
Prepare for eliminating get_mode(). Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com> [for acerhdf] Acked-by: Peter Kaestle <peter@piie.net> Reviewed-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Reviewed-by: Amit Kucheria <amit.kucheria@linaro.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20200629122925.21729-5-andrzej.p@collabora.com
2020-06-29thermal: Add current mode to thermal zone deviceAndrzej Pietrasiewicz1-0/+2
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: Andrzej Pietrasiewicz <andrzej.p@collabora.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Reviewed-by: Amit Kucheria <amit.kucheria@linaro.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20200629122925.21729-4-andrzej.p@collabora.com
2020-06-29thermal: Store thermal mode in a dedicated enumAndrzej Pietrasiewicz3-28/+25
Prepare for storing mode in struct thermal_zone_device. Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> [for acerhdf] Acked-by: Peter Kaestle <peter@piie.net> Reviewed-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Reviewed-by: Amit Kucheria <amit.kucheria@linaro.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20200629122925.21729-3-andrzej.p@collabora.com
2020-06-29acpi: thermal: Fix error handling in the register functionAndrzej Pietrasiewicz1-4/+16
The acpi_thermal_register_thermal_zone() is missing any error handling. This needs to be fixed. Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Reviewed-by: Amit Kucheria <amit.kucheria@linaro.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20200629122925.21729-2-andrzej.p@collabora.com
2020-06-28Linux 5.8-rc3Linus Torvalds1-1/+1
2020-06-28sched/cfs: change initial value of runnable_avgVincent Guittot1-1/+1
Some performance regression on reaim benchmark have been raised with commit 070f5e860ee2 ("sched/fair: Take into account runnable_avg to classify group") The problem comes from the init value of runnable_avg which is initialized with max value. This can be a problem if the newly forked task is finally a short task because the group of CPUs is wrongly set to overloaded and tasks are pulled less agressively. Set initial value of runnable_avg equals to util_avg to reflect that there is no waiting time so far. Fixes: 070f5e860ee2 ("sched/fair: Take into account runnable_avg to classify group") Reported-by: kernel test robot <rong.a.chen@intel.com> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/20200624154422.29166-1-vincent.guittot@linaro.org
2020-06-28smp, irq_work: Continue smp_call_function*() and irq_work*() integrationPeter Zijlstra6-58/+86
Instead of relying on BUG_ON() to ensure the various data structures line up, use a bunch of horrible unions to make it all automatic. Much of the union magic is to ensure irq_work and smp_call_function do not (yet) see the members of their respective data structures change name. Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: Frederic Weisbecker <frederic@kernel.org> Link: https://lkml.kernel.org/r/20200622100825.844455025@infradead.org
2020-06-28sched/core: s/WF_ON_RQ/WQ_ON_CPU/Peter Zijlstra2-3/+3
Use a better name for this poorly named flag, to avoid confusion... Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Acked-by: Mel Gorman <mgorman@suse.de> Link: https://lkml.kernel.org/r/20200622100825.785115830@infradead.org
2020-06-28sched/core: Fix ttwu() racePeter Zijlstra1-5/+28
Paul reported rcutorture occasionally hitting a NULL deref: sched_ttwu_pending() ttwu_do_wakeup() check_preempt_curr() := check_preempt_wakeup() find_matching_se() is_same_group() if (se->cfs_rq == pse->cfs_rq) <-- *BOOM* Debugging showed that this only appears to happen when we take the new code-path from commit: 2ebb17717550 ("sched/core: Offload wakee task activation if it the wakee is descheduling") and only when @cpu == smp_processor_id(). Something which should not be possible, because p->on_cpu can only be true for remote tasks. Similarly, without the new code-path from commit: c6e7bd7afaeb ("sched/core: Optimize ttwu() spinning on p->on_cpu") this would've unconditionally hit: smp_cond_load_acquire(&p->on_cpu, !VAL); and if: 'cpu == smp_processor_id() && p->on_cpu' is possible, this would result in an instant live-lock (with IRQs disabled), something that hasn't been reported. The NULL deref can be explained however if the task_cpu(p) load at the beginning of try_to_wake_up() returns an old value, and this old value happens to be smp_processor_id(). Further assume that the p->on_cpu load accurately returns 1, it really is still running, just not here. Then, when we enqueue the task locally, we can crash in exactly the observed manner because p->se.cfs_rq != rq->cfs_rq, because p's cfs_rq is from the wrong CPU, therefore we'll iterate into the non-existant parents and NULL deref. The closest semi-plausible scenario I've managed to contrive is somewhat elaborate (then again, actual reproduction takes many CPU hours of rcutorture, so it can't be anything obvious): X->cpu = 1 rq(1)->curr = X CPU0 CPU1 CPU2 // switch away from X LOCK rq(1)->lock smp_mb__after_spinlock dequeue_task(X) X->on_rq = 9 switch_to(Z) X->on_cpu = 0 UNLOCK rq(1)->lock // migrate X to cpu 0 LOCK rq(1)->lock dequeue_task(X) set_task_cpu(X, 0) X->cpu = 0 UNLOCK rq(1)->lock LOCK rq(0)->lock enqueue_task(X) X->on_rq = 1 UNLOCK rq(0)->lock // switch to X LOCK rq(0)->lock smp_mb__after_spinlock switch_to(X) X->on_cpu = 1 UNLOCK rq(0)->lock // X goes sleep X->state = TASK_UNINTERRUPTIBLE smp_mb(); // wake X ttwu() LOCK X->pi_lock smp_mb__after_spinlock if (p->state) cpu = X->cpu; // =? 1 smp_rmb() // X calls schedule() LOCK rq(0)->lock smp_mb__after_spinlock dequeue_task(X) X->on_rq = 0 if (p->on_rq) smp_rmb(); if (p->on_cpu && ttwu_queue_wakelist(..)) [*] smp_cond_load_acquire(&p->on_cpu, !VAL) cpu = select_task_rq(X, X->wake_cpu, ...) if (X->cpu != cpu) switch_to(Y) X->on_cpu = 0 UNLOCK rq(0)->lock However I'm having trouble convincing myself that's actually possible on x86_64 -- after all, every LOCK implies an smp_mb() there, so if ttwu observes ->state != RUNNING, it must also observe ->cpu != 1. (Most of the previous ttwu() races were found on very large PowerPC) Nevertheless, this fully explains the observed failure case. Fix it by ordering the task_cpu(p) load after the p->on_cpu load, which is easy since nothing actually uses @cpu before this. Fixes: c6e7bd7afaeb ("sched/core: Optimize ttwu() spinning on p->on_cpu") Reported-by: Paul E. McKenney <paulmck@kernel.org> Tested-by: Paul E. McKenney <paulmck@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lkml.kernel.org/r/20200622125649.GC576871@hirez.programming.kicks-ass.net
2020-06-28sched/core: Fix PI boosting between RT and DEADLINE tasksJuri Lelli1-1/+2
syzbot reported the following warning: WARNING: CPU: 1 PID: 6351 at kernel/sched/deadline.c:628 enqueue_task_dl+0x22da/0x38a0 kernel/sched/deadline.c:1504 At deadline.c:628 we have: 623 static inline void setup_new_dl_entity(struct sched_dl_entity *dl_se) 624 { 625 struct dl_rq *dl_rq = dl_rq_of_se(dl_se); 626 struct rq *rq = rq_of_dl_rq(dl_rq); 627 628 WARN_ON(dl_se->dl_boosted); 629 WARN_ON(dl_time_before(rq_clock(rq), dl_se->deadline)); [...] } Which means that setup_new_dl_entity() has been called on a task currently boosted. This shouldn't happen though, as setup_new_dl_entity() is only called when the 'dynamic' deadline of the new entity is in the past w.r.t. rq_clock and boosted tasks shouldn't verify this condition. Digging through the PI code I noticed that what above might in fact happen if an RT tasks blocks on an rt_mutex hold by a DEADLINE task. In the first branch of boosting conditions we check only if a pi_task 'dynamic' deadline is earlier than mutex holder's and in this case we set mutex holder to be dl_boosted. However, since RT 'dynamic' deadlines are only initialized if such tasks get boosted at some point (or if they become DEADLINE of course), in general RT 'dynamic' deadlines are usually equal to 0 and this verifies the aforementioned condition. Fix it by checking that the potential donor task is actually (even if temporary because in turn boosted) running at DEADLINE priority before using its 'dynamic' deadline value. Fixes: 2d3d891d3344 ("sched/deadline: Add SCHED_DEADLINE inheritance logic") Reported-by: syzbot+119ba87189432ead09b4@syzkaller.appspotmail.com Signed-off-by: Juri Lelli <juri.lelli@redhat.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: Daniel Bristot de Oliveira <bristot@redhat.com> Tested-by: Daniel Wagner <dwagner@suse.de> Link: https://lkml.kernel.org/r/20181119153201.GB2119@localhost.localdomain
2020-06-28sched/deadline: Initialize ->dl_boostedJuri Lelli1-0/+1
syzbot reported the following warning triggered via SYSC_sched_setattr(): WARNING: CPU: 0 PID: 6973 at kernel/sched/deadline.c:593 setup_new_dl_entity /kernel/sched/deadline.c:594 [inline] WARNING: CPU: 0 PID: 6973 at kernel/sched/deadline.c:593 enqueue_dl_entity /kernel/sched/deadline.c:1370 [inline] WARNING: CPU: 0 PID: 6973 at kernel/sched/deadline.c:593 enqueue_task_dl+0x1c17/0x2ba0 /kernel/sched/deadline.c:1441 This happens because the ->dl_boosted flag is currently not initialized by __dl_clear_params() (unlike the other flags) and setup_new_dl_entity() rightfully complains about it. Initialize dl_boosted to 0. Fixes: 2d3d891d3344 ("sched/deadline: Add SCHED_DEADLINE inheritance logic") Reported-by: syzbot+5ac8bac25f95e8b221e7@syzkaller.appspotmail.com Signed-off-by: Juri Lelli <juri.lelli@redhat.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Tested-by: Daniel Wagner <dwagner@suse.de> Link: https://lkml.kernel.org/r/20200617072919.818409-1-juri.lelli@redhat.com
2020-06-28sched/core: Check cpus_mask, not cpus_ptr in __set_cpus_allowed_ptr(), to fix mask corruptionScott Wood1-1/+1
This function is concerned with the long-term CPU mask, not the transitory mask the task might have while migrate disabled. Before this patch, if a task was migrate-disabled at the time __set_cpus_allowed_ptr() was called, and the new mask happened to be equal to the CPU that the task was running on, then the mask update would be lost. Signed-off-by: Scott Wood <swood@redhat.com> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lkml.kernel.org/r/20200617121742.cpxppyi7twxmpin7@linutronix.de
2020-06-28sched/core: Fix CONFIG_GCC_PLUGIN_RANDSTRUCT build failPeter Zijlstra1-2/+4
As a temporary build fix, the proper cleanup needs more work. Reported-by: Guenter Roeck <linux@roeck-us.net> Reported-by: Eric Biggers <ebiggers@kernel.org> Suggested-by: Eric Biggers <ebiggers@kernel.org> Suggested-by: Kees Cook <keescook@chromium.org> Fixes: a148866489fb ("sched: Replace rq::wake_list") Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Ingo Molnar <mingo@kernel.org>
2020-06-28Revert "ARM: sti: Implement dummy L2 cache's write_sec"Patrice Chotard1-9/+0
This reverts commit 7b8e0188fa717cd9abc4fb52587445b421835c2a. Initially, STiH410-B2260 was supposed to be secured, that's why l2c_write_sec was stubbed to avoid secure register access from non secure world. But by default, STiH410-B2260 is running in non secure mode, so L2 cache register accesses are authorized, l2c_write_sec stub is not needed. With this patch, L2 cache is configured and performance are enhanced. Link: https://lore.kernel.org/r/20200618172456.29475-1-patrice.chotard@st.com Signed-off-by: Patrice Chotard <patrice.chotard@st.com> Cc: Alain Volmat <alain.volmat@st.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2020-06-27afs: Fix storage of cell namesDavid Howells2-1/+10
The cell name stored in the afs_cell struct is a 64-char + NUL buffer - when it needs to be able to handle up to AFS_MAXCELLNAME (256 chars) + NUL. Fix this by changing the array to a pointer and allocating the string. Found using Coverity. Fixes: 989782dcdc91 ("afs: Overhaul cell database management") Reported-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-06-26kgdb: Avoid suspicious RCU usage warningDouglas Anderson1-0/+4
At times when I'm using kgdb I see a splat on my console about suspicious RCU usage. I managed to come up with a case that could reproduce this that looked like this: WARNING: suspicious RCU usage 5.7.0-rc4+ #609 Not tainted ----------------------------- kernel/pid.c:395 find_task_by_pid_ns() needs rcu_read_lock() protection! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 3 locks held by swapper/0/1: #0: ffffff81b6b8e988 (&dev->mutex){....}-{3:3}, at: __device_attach+0x40/0x13c #1: ffffffd01109e9e8 (dbg_master_lock){....}-{2:2}, at: kgdb_cpu_enter+0x20c/0x7ac #2: ffffffd01109ea90 (dbg_slave_lock){....}-{2:2}, at: kgdb_cpu_enter+0x3ec/0x7ac stack backtrace: CPU: 7 PID: 1 Comm: swapper/0 Not tainted 5.7.0-rc4+ #609 Hardware name: Google Cheza (rev3+) (DT) Call trace: dump_backtrace+0x0/0x1b8 show_stack+0x1c/0x24 dump_stack+0xd4/0x134 lockdep_rcu_suspicious+0xf0/0x100 find_task_by_pid_ns+0x5c/0x80 getthread+0x8c/0xb0 gdb_serial_stub+0x9d4/0xd04 kgdb_cpu_enter+0x284/0x7ac kgdb_handle_exception+0x174/0x20c kgdb_brk_fn+0x24/0x30 call_break_hook+0x6c/0x7c brk_handler+0x20/0x5c do_debug_exception+0x1c8/0x22c el1_sync_handler+0x3c/0xe4 el1_sync+0x7c/0x100 rpmh_rsc_probe+0x38/0x420 platform_drv_probe+0x94/0xb4 really_probe+0x134/0x300 driver_probe_device+0x68/0x100 __device_attach_driver+0x90/0xa8 bus_for_each_drv+0x84/0xcc __device_attach+0xb4/0x13c device_initial_probe+0x18/0x20 bus_probe_device+0x38/0x98 device_add+0x38c/0x420 If I understand properly we should just be able to blanket kgdb under one big RCU read lock and the problem should go away. We'll add it to the beast-of-a-function known as kgdb_cpu_enter(). With this I no longer get any splats and things seem to work fine. Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20200602154729.v2.1.I70e0d4fd46d5ed2aaf0c98a355e8e1b7a5bb7e4e@changeid Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.