linux-stable.git/drivers/devfreq/devfreq.c, branch v4.19.98

PM / devfreq: Check NULL governor in available_governors_show

2020-01-09T09:19:03+00:00

commit d68adc8f85cd757bd33c8d7b2660ad6f16f7f3dc upstream.

The governor is initialized after sysfs attributes become visible so in
theory the governor field can be NULL here.

Fixes: bcf23c79c4e46 ("PM / devfreq: Fix available_governor sysfs")
Signed-off-by: Leonard Crestez 
Reviewed-by: Matthias Kaehlcke 
Reviewed-by: Chanwoo Choi 
Signed-off-by: Chanwoo Choi 
Signed-off-by: Greg Kroah-Hartman

PM / devfreq: Don't fail devfreq_dev_release if not in list

2020-01-09T09:18:55+00:00

[ Upstream commit 42a6b25e67df6ee6675e8d1eaf18065bd73328ba ]

Right now devfreq_dev_release will print a warning and abort the rest of
the cleanup if the devfreq instance is not part of the global
devfreq_list. But this is a valid scenario, for example it can happen if
the governor can't be found or on any other init error that happens
after device_register.

Initialize devfreq->node to an empty list head in devfreq_add_device so
that list_del becomes a safe noop inside devfreq_dev_release and we can
continue the rest of the cleanup.

Signed-off-by: Leonard Crestez 
Reviewed-by: Matthias Kaehlcke 
Reviewed-by: Chanwoo Choi 
Signed-off-by: Chanwoo Choi 
Signed-off-by: Sasha Levin

PM / devfreq: Set scaling_max_freq to max on OPP notifier error

2020-01-09T09:18:55+00:00

[ Upstream commit e7cc792d00049c874010b398a27c3cc7bc8fef34 ]

The devfreq_notifier_call functions will update scaling_min_freq and
scaling_max_freq when the OPP table is updated.

If fetching the maximum frequency fails then scaling_max_freq remains
set to zero which is confusing. Set to ULONG_MAX instead so we don't
need special handling for this case in other places.

Signed-off-by: Leonard Crestez 
Reviewed-by: Matthias Kaehlcke 
Reviewed-by: Chanwoo Choi 
Signed-off-by: Chanwoo Choi 
Signed-off-by: Sasha Levin

PM / devfreq: Fix devfreq_notifier_call returning errno

2020-01-09T09:18:55+00:00

[ Upstream commit e876e710ede23f670494331e062d643928e4142a ]

Notifier callbacks shouldn't return negative errno but one of the
NOTIFY_OK/DONE/BAD values.

The OPP core will ignore return values from notifiers but returning a
value that matches NOTIFY_STOP_MASK will stop the notification chain.

Fix by always returning NOTIFY_OK.

Signed-off-by: Leonard Crestez 
Reviewed-by: Matthias Kaehlcke 
Reviewed-by: Chanwoo Choi 
Signed-off-by: Chanwoo Choi 
Signed-off-by: Sasha Levin

PM / devfreq: Lock devfreq in trans_stat_show

2019-12-17T19:35:03+00:00

commit 2abb0d5268ae7b5ddf82099b1f8d5aa8414637d4 upstream.

There is no locking in this sysfs show function so stats printing can
race with a devfreq_update_status called as part of freq switching or
with initialization.

Also add an assert in devfreq_update_status to make it clear that lock
must be held by caller.

Fixes: 39688ce6facd ("PM / devfreq: account suspend/resume for stats")
Cc: stable@vger.kernel.org
Signed-off-by: Leonard Crestez 
Reviewed-by: Matthias Kaehlcke 
Reviewed-by: Chanwoo Choi 
Signed-off-by: Chanwoo Choi 
Signed-off-by: Greg Kroah-Hartman

PM / devfreq: Fix kernel oops on governor module load

2019-12-01T08:17:46+00:00

commit 7544fd7f384591038646d3cd9efb311ab4509e24 upstream.

A bit unexpectedly (but still documented), request_module may
return a positive value, in case of a modprobe error.
This is currently causing issues in the devfreq framework.

When a request_module exits with a positive value, we currently
return that via ERR_PTR. However, because the value is positive,
it's not a ERR_VALUE proper, and is therefore treated as a
valid struct devfreq_governor pointer, leading to a kernel oops.

Fix this by returning -EINVAL if request_module returns a positive
value.

Fixes: b53b0128052ff ("PM / devfreq: Fix static checker warning in try_then_request_governor")
Signed-off-by: Ezequiel Garcia 
Reviewed-by: Chanwoo Choi 
Signed-off-by: MyungJoo Ham 
Cc: Nobuhiro Iwamatsu 
Signed-off-by: Greg Kroah-Hartman

PM / devfreq: Fix static checker warning in try_then_request_governor

2019-11-24T07:21:07+00:00

[ Upstream commit b53b0128052ffd687797d5f4deeb76327e7b5711 ]

The patch 23c7b54ca1cd: "PM / devfreq: Fix devfreq_add_device() when
drivers are built as modules." leads to the following static checker
warning:

    drivers/devfreq/devfreq.c:1043 governor_store()
    warn: 'governor' can also be NULL

The reason is that the try_then_request_governor() function returns both
error pointers and NULL. It should just return error pointers, so fix
this by returning a ERR_PTR to the error intead of returning NULL.

Fixes: 23c7b54ca1cd ("PM / devfreq: Fix devfreq_add_device() when drivers are built as modules.")
Reported-by: Dan Carpenter 
Signed-off-by: Enric Balletbo i Serra 
Reviewed-by: Chanwoo Choi 
Signed-off-by: MyungJoo Ham 
Signed-off-by: Sasha Levin

PM / devfreq: stopping the governor before device_unregister()

2019-11-24T07:19:36+00:00

[ Upstream commit 2f061fd0c2d852e32e03a903fccd810663c5c31e ]

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 
Signed-off-by: Sasha Levin

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

2019-11-24T07:19:35+00:00

[ Upstream commit df5cf4a36178c5d4f2b8b9469cb2f722e64cd102 ]

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 
Signed-off-by: Sasha Levin

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

2019-11-24T07:19:34+00:00

[ Upstream commit 23c7b54ca1cd1797ef39169ab85e6d46f1c2d061 ]

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 
Signed-off-by: Sasha Levin