[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141117114341.GF25699@ulmo>
Date: Mon, 17 Nov 2014 12:43:42 +0100
From: Thierry Reding <thierry.reding@...il.com>
To: Mikko Perttunen <mikko.perttunen@...si.fi>
Cc: Lukasz Majewski <l.majewski@...sung.com>,
Eduardo Valentin <edubezval@...il.com>,
Zhang Rui <rui.zhang@...el.com>,
Ezequiel Garcia <ezequiel.garcia@...e-electrons.com>,
Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>,
Linux PM list <linux-pm@...r.kernel.org>,
Vincenzo Frascino <vincenzo.frascino@...com>,
Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
Lukasz Majewski <l.majewski@...ess.pl>,
Nobuhiro Iwamatsu <iwamatsu@...auri.org>,
Mikko Perttunen <mperttunen@...dia.com>,
Stephen Warren <swarren@...dotorg.org>,
Alexandre Courbot <gnurou@...il.com>,
linux-tegra@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 5/8] thermal:cpu cooling:tegra: Provide deferred probing
for tegra driver
On Fri, Nov 14, 2014 at 12:47:33PM +0200, Mikko Perttunen wrote:
> Tested-by: Mikko Perttunen <mikko.perttunen@...si.fi>
>
> One potential issue I can see is that if the cpufreq driver fails to probe
> then you'll never get the thermal driver either. For example, Tegra124
> currently has no cpufreq driver, so if CONFIG_CPU_THERMAL was enabled, then
> the soctherm driver would never be able to probe. But I don't really have a
> solution for this either.
It doesn't seem like there's any code whatsoever to deal with cpufreq
within the soctherm driver, so deferring probe based on something we're
not using anyway seems rather useless.
Thierry
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists