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 <[email protected]> > >> --- > >> 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 <[email protected]> > > 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
