linux/drivers/devfreq/devfreq.c, branch v5.1

PM / devfreq: add devfreq_suspend/resume() functions

2018-12-11T02:40:13Z

This patch adds implementation for global suspend/resume for devfreq framework. System suspend will next use these functions. Suggested-by: Tobias Jakobi Suggested-by: Chanwoo Choi Signed-off-by: Lukasz Luba Reviewed-by: Chanwoo Choi Signed-off-by: MyungJoo Ham

PM / devfreq: add support for suspend/resume of a devfreq device

2018-12-11T02:09:47Z

The patch prepares devfreq device for handling suspend/resume functionality. The new fields will store needed information during this process. Devfreq framework handles opp-suspend DT entry and there is no need of modyfications in the drivers code. It uses atomic variables to make sure no race condition affects the process. Suggested-by: Tobias Jakobi Suggested-by: Chanwoo Choi Signed-off-by: Lukasz Luba Reviewed-by: Chanwoo Choi Signed-off-by: MyungJoo Ham

PM / devfreq: refactor set_target frequency function

2018-12-11T02:09:44Z

The refactoring is needed for the new client in devfreq: suspend. To avoid code duplication, move it to the new local function devfreq_set_target. Suggested-by: Tobias Jakobi Suggested-by: Chanwoo Choi Reviewed-by: Chanwoo Choi Signed-off-by: Lukasz Luba Signed-off-by: MyungJoo Ham

PM / devfreq: remove redundant null pointer check before kfree

2018-10-02T01:16:41Z

kfree has taken the null pointer into account. hence it is safe to remove the redundant null pointer check before kfree. Signed-off-by: zhong jiang Signed-off-by: MyungJoo Ham

PM / devfreq: stopping the governor before device_unregister()

2018-10-02T01:16:41Z

device_release() is freeing the resources before calling the device specific release callback which is, in the case of devfreq, stopping the governor. It is a problem as some governors are using the device resources. e.g. simpleondemand which is using the devfreq deferrable monitoring work. If it is not stopped before the resources are freed, it might lead to a use after free. Signed-off-by: Vincent Donnefort Reviewed-by: John Einar Reitan [cw00.choi: Fix merge conflict] Reviewed-by: Chanwoo Choi Signed-off-by: MyungJoo Ham

PM / devfreq: Fix handling of min/max_freq == 0

2018-10-02T01:16:41Z

Commit ab8f58ad72c4 ("PM / devfreq: Set min/max_freq when adding the devfreq device") initializes df->min/max_freq with the min/max OPP when the device is added. Later commit f1d981eaecf8 ("PM / devfreq: Use the available min/max frequency") adds df->scaling_min/max_freq and the following to the frequency adjustment code: max_freq = MIN(devfreq->scaling_max_freq, devfreq->max_freq); With the current handling of min/max_freq this is incorrect: Even though df->max_freq is now initialized to a value != 0 user space can still set it to 0, in this case max_freq would be 0 instead of df->scaling_max_freq as intended. In consequence the frequency adjustment is not performed: if (max_freq && freq > max_freq) { freq = max_freq; To fix this set df->min/max freq to the min/max OPP in max/max_freq_store, when the user passes a value of 0. This also prevents df->max_freq from being set below the min OPP when df->min_freq is 0, and similar for min_freq. Since it is now guaranteed that df->min/max_freq can't be 0 the checks for this case can be removed. Fixes: f1d981eaecf8 ("PM / devfreq: Use the available min/max frequency") Signed-off-by: Matthias Kaehlcke Reviewed-by: Brian Norris Reviewed-by: Chanwoo Choi Signed-off-by: MyungJoo Ham

PM / devfreq: Drop custom MIN/MAX macros

2018-10-02T01:16:41Z

Drop the custom MIN/MAX macros in favour of the standard min/max from kernel.h Signed-off-by: Bjorn Andersson Reviewed-by: Chanwoo Choi Signed-off-by: MyungJoo Ham

PM / devfreq: Fix devfreq_add_device() when drivers are built as modules.

2018-10-02T01:16:41Z

When the devfreq driver and the governor driver are built as modules, the call to devfreq_add_device() or governor_store() fails because the governor driver is not loaded at the time the devfreq driver loads. The devfreq driver has a build dependency on the governor but also should have a runtime dependency. We need to make sure that the governor driver is loaded before the devfreq driver. This patch fixes this bug by adding a try_then_request_governor() function. First tries to find the governor, and then, if it is not found, it requests the module and tries again. Fixes: 1b5c1be2c88e (PM / devfreq: map devfreq drivers to governor using name) Signed-off-by: Enric Balletbo i Serra Reviewed-by: Chanwoo Choi Signed-off-by: MyungJoo Ham

PM / devfreq: Init user limits from OPP limits, not viceversa

2018-07-18T04:58:38Z

Commit ab8f58ad72c4 ("PM / devfreq: Set min/max_freq when adding the devfreq device") introduced the initialization of the user limits min/max_freq from the lowest/highest available OPPs. Later commit f1d981eaecf8 ("PM / devfreq: Use the available min/max frequency") added scaling_min/max_freq, which actually represent the frequencies of the lowest/highest available OPP. scaling_min/ max_freq are initialized with the values from min/max_freq, which is totally correct in the context, but a bit awkward to read. Swap the initialization and assign scaling_min/max_freq with the OPP freqs and then the user limts min/max_freq with scaling_min/ max_freq. Needless to say that this change is a NOP, intended to improve readability. Signed-off-by: Matthias Kaehlcke Reviewed-by: Chanwoo Choi Reviewed-by: Brian Norris Signed-off-by: MyungJoo Ham

PM / devfreq: use put_device() instead of kfree()

2018-07-18T04:56:49Z

Never directly free @dev after calling device_register() or device_unregister(), even if device_register() returned an error. Always use put_device() to give up the reference initialized. Signed-off-by: Arvind Yadav Reviewed-by: Chanwoo Choi Signed-off-by: MyungJoo Ham