kernel/drivers/cpufreq/cpufreq.c, branch linux-5.1.y

cpufreq: Fix kobject memleak

2019-05-31T13:43:18Z

[ Upstream commit 4ebe36c94aed95de71a8ce6a6762226d31c938ee ] Currently the error return path from kobject_init_and_add() is not followed by a call to kobject_put() - which means we are leaking the kobject. Fix it by adding a call to kobject_put() in the error path of kobject_init_and_add(). Signed-off-by: Viresh Kumar Reviewed-by: Tobin C. Harding Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

cpufreq: Improve kerneldoc comments for cpufreq_cpu_get/put()

2019-03-07T09:55:29Z

Fix the formatting of the cpufreq_cpu_get() and cpufreq_cpu_put() kerneldoc comments and rework them to be somewhat easier to follow. Signed-off-by: Rafael J. Wysocki Acked-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki

cpufreq: Pass updated policy to driver ->setpolicy() callback

2019-02-20T09:18:37Z

The invocation of the ->setpolicy() cpufreq driver callback should be equivalent to calling cpufreq_governor_limits(policy) for drivers with internal governors, but in fact it isn't so, because the temporary new_policy object is passed to it instead of the updated policy. That is a bit confusing, so make cpufreq_set_policy() pass the updated policy to the driver ->setpolicy() callback. No intentional changes of behavior. Signed-off-by: Rafael J. Wysocki Acked-by: Viresh Kumar

cpufreq: Fix two debug messages in cpufreq_set_policy()

2019-02-20T09:18:37Z

Remove the redundant "cpufreq:" prefix from two debug messages in cpufreq_set_policy(). Signed-off-by: Rafael J. Wysocki Acked-by: Viresh Kumar

cpufreq: Reorder and simplify cpufreq_update_policy()

2019-02-20T09:18:37Z

In cpufreq_update_policy(), instead of updating new_policy.cur separately, which is kind of confusing, because cpufreq_set_policy() doesn't take that value into account directly anyway, make the copy of the existing policy after calling cpufreq_update_current_freq(). No intentional changes of behavior. Signed-off-by: Rafael J. Wysocki Acked-by: Viresh Kumar

cpufreq: Add kerneldoc comments for two core functions

2019-02-20T09:18:37Z

Add kerneldoc comments describing cpufreq_set_policy() and cpufreq_update_policy() as they have not been properly documented so far and they really need to be documented. While at it, fix white space around the cpufreq_set_policy() header. Signed-off-by: Rafael J. Wysocki Acked-by: Viresh Kumar

cpufreq: Replace double NOT (!!) with single NOT (!)

2019-02-14T11:06:38Z

Double NOT (!!) operation is normally done to convert a non-zero value to 1 and keep zero as is, but that isn't the requirement in this case. All we wanted was to make sure that only one of the two routines isn't set, i.e. either both function pointers are set or both are unset. This can be done with a single NOT (!) operation as well. Signed-off-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki

cpufreq: Allow light-weight tear down and bring up of CPUs

2019-02-12T22:47:42Z

The cpufreq core doesn't remove the cpufreq policy anymore on CPU offline operation, rather that happens when the CPU device gets unregistered from the kernel. This allows faster recovery when the CPU comes back online. This is also very useful during system wide suspend/resume where we offline all non-boot CPUs during suspend and then bring them back on resume. This commit takes the same idea a step ahead to allow drivers to do light weight tear-down and bring-up during CPU offline and online operations. A new set of callbacks is introduced, online/offline(). online() gets called when the first CPU of an inactive policy is brought up and offline() gets called when all the CPUs of a policy are offlined. The existing init/exit() callback get called on policy creation/destruction. They also get called instead of online/offline() callbacks if the online/offline() callbacks aren't provided. This also moves around some code to get executed only for the new-policy case going forward. Signed-off-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki

cpufreq: Auto-register the driver as a thermal cooling device if asked

2019-01-30T22:02:26Z

All cpufreq drivers do similar things to register as a cooling device. Provide a cpufreq driver flag so drivers can just ask the cpufreq core to register the cooling device on their behalf. This allows us to get rid of duplicated code in the drivers. In order to allow this, we add a struct thermal_cooling_device pointer to struct cpufreq_policy so that drivers don't need to store it in a private data structure. Suggested-by: Stephen Boyd Suggested-by: Viresh Kumar Signed-off-by: Amit Kucheria Reviewed-by: Matthias Kaehlcke Tested-by: Matthias Kaehlcke Acked-by: Viresh Kumar Reviewed-by: Daniel Lezcano Signed-off-by: Rafael J. Wysocki

cpufreq: Use struct kobj_attribute instead of struct global_attr

2019-01-29T10:44:30Z

The cpufreq_global_kobject is created using kobject_create_and_add() helper, which assigns the kobj_type as dynamic_kobj_ktype and show/store routines are set to kobj_attr_show() and kobj_attr_store(). These routines pass struct kobj_attribute as an argument to the show/store callbacks. But all the cpufreq files created using the cpufreq_global_kobject expect the argument to be of type struct attribute. Things work fine currently as no one accesses the "attr" argument. We may not see issues even if the argument is used, as struct kobj_attribute has struct attribute as its first element and so they will both get same address. But this is logically incorrect and we should rather use struct kobj_attribute instead of struct global_attr in the cpufreq core and drivers and the show/store callbacks should take struct kobj_attribute as argument instead. This bug is caught using CFI CLANG builds in android kernel which catches mismatch in function prototypes for such callbacks. Reported-by: Donghee Han Reported-by: Sangkyu Kim Signed-off-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki