lkml.org 
[lkml]   [2019]   [Jun]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 2/6] thermal/drivers/cpu_cooling: Unregister with the policy
On 24-06-19, 09:30, Daniel Lezcano wrote:
> On 24/06/2019 08:03, Viresh Kumar wrote:
> > On 21-06-19, 15:22, Daniel Lezcano wrote:
> >> Currently the function cpufreq_cooling_register() returns a cooling
> >> device pointer which is used back as a pointer to call the function
> >> cpufreq_cooling_unregister(). Even if it is correct, it would make
> >> sense to not leak the structure inside a cpufreq driver and keep the
> >> code thermal code self-encapsulate. Moreover, that forces to add an
> >> extra variable in each driver using this function.
> >>
> >> Instead of passing the cooling device to unregister, pass the policy.
> >>
> >> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> >> ---
> >> drivers/cpufreq/arm_big_little.c | 2 +-
> >> drivers/cpufreq/cpufreq.c | 2 +-
> >> drivers/thermal/cpu_cooling.c | 18 ++++++++++--------
> >> drivers/thermal/imx_thermal.c | 4 ++--
> >> .../thermal/ti-soc-thermal/ti-thermal-common.c | 2 +-
> >> include/linux/cpu_cooling.h | 6 +++---
> >> 6 files changed, 18 insertions(+), 16 deletions(-)
> >
> > Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
>
> Just a side note, does it make sense to have the function called from
> imx_thermal.c and ti-thermal-common.c? Sounds like also a leakage from
> cpufreq to thermal drivers, no?

I am not sure what you are proposing here :)

--
viresh

\
 
 \ /
  Last update: 2019-06-24 09:38    [W:0.088 / U:23.344 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site