[lkml]   [2019]   [Apr]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 1/7] thermal/drivers/core: Remove the module Kconfig's option
On Tue, Apr 23, 2019 at 9:22 PM Eduardo Valentin <> wrote:
> Hello,
> On Tue, Apr 02, 2019 at 06:12:44PM +0200, Daniel Lezcano wrote:
> > The module support for the thermal subsystem makes little sense:
> > - some subsystems relying on it are not modules, thus forcing the
> > framework to be compiled in
> > - it is compiled in for almost every configs, the remaining ones
> > are a few platforms where I don't see why we can not switch the thermal
> > to 'y'. The drivers can stay in tristate.
> > - platforms need the thermal to be ready as soon as possible at boot time
> > in order to mitigate
> >
> > Usually the subsystems framework are compiled-in and the plugs are as module.
> >
> > Remove the module option. The removal of the module related dead code will
> > come after this patch gets in or is acked.
> I remember some buzilla entry around this some time back.
> Rui, do you remember why you made this to be module?
> I dont have strong opinion here, but I would like to see
> a better description why we are going this direction rather
> than "most people dont use it as module". Was there any particular
> specific technical motivation?

Speaking for Qualcomm platforms, we want the thermal subsystem
available as soon as possible for boot time thermal mitigation since
faster boot times equals hotter cpus. Also the dependency on cpufreq
subsystem due to the cpufreq cooling device would be simplified with

In fact, I now have a follow on patch to move thermal init earlier
than fs_initcall since we'd now not wait on modules to be available.


 \ /
  Last update: 2019-04-24 07:46    [W:0.189 / U:1.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site