On Wednesday, November 26, 2014 11:10:32 AM Eduardo Valentin wrote:
--T4sUOijqQbZv57TR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable
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?
=20 This is what Eduardo reported in one of the mails: =20
=20 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. =20 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. =20 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. =20
=20 And so it looked like things aren't going to work smoothly in 3.18 and so I thought we should get it in. =20
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.
=20 @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.
That's my view as well.