Re: [PATCH] cpufreq-dt: register cooling device after validating cpufreq table

[Eduardo Valentin <edubezval@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1945 bytes --]


Hello Viresh, Rafael,

On Wed, Nov 26, 2014 at 11:27:42AM +0530, Viresh Kumar wrote:
> On 26 November 2014 at 03:35, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > And what bad things are going to happen if this is not pushed for 3.18?
> 
> This is what Eduardo reported in one of the mails:
> 
> ---
> 
> As an example, I am taking the ti-soc-thermal, but we already have other
> of-thermal based drivers. Booting with this patch ti-soc-thermal
> (of-based boot) loads fine, but the cpu_cooling never gets bound to the
> thermal zone.
> 
> The thing is that the bind may happen before cpufreq-dt code loads the
> cpufreq driver, and when cpu_cooling is checking what is the max freq,
> by using cpufreq table, it won't be able to do it, as there is no table.
> 
> While, without the patch, it will use wrong in the binding, but after
> it gets bound, and cpufreq loads, the max will be used correctly.
> 
> ----
> 
> And so it looked like things aren't going to work smoothly in 3.18
> and so I thought we should get it in.
> 

The bug exists, it is there for 3.18. But also, as I explained in that
thread, the current code is able to initialize the of cooling device and
to register it in its thermal zone. But that works by lucky because we
do not have the proper return code checks in thermal core.

> But probably the problem will be worst only after applying Lukasz
> patchset?

The bug gets exposed by his patch.

> 
> @Eduardo: Do you want Rafael to apply this for 3.18? or 3.19 will
> work as well ?


I believe, for this case, 3.19 is best option. Looks like we have a
possible API massage coming, so, targetting 3.18 would be rushy. I'd
rather think of a proper way to fix this, scalable and that makes
sense to everybody, even if takes extra merge window, than rushing for a
fix that we may need to revisit it again in near future.


BR,

Eduardo Valentin
> 
> --
> viresh

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]