From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id C0F281A04B8 for ; Sat, 27 Feb 2016 10:22:02 +1100 (AEDT) From: Arnd Bergmann To: Li Yang Cc: linuxppc-dev , devicetree@vger.kernel.org, "linux-pm@vger.kernel.org" , "Rafael J. Wysocki" , Jia Hongtao , Eduardo Valentin , Viresh Kumar , Scott Wood Subject: Re: [PATCH V3] cpufreq: qoriq: Register cooling device based on device tree Date: Sat, 27 Feb 2016 00:16:35 +0100 Message-ID: <3593471.QAyZdAuTcW@wuerfel> In-Reply-To: References: <1448529671-48216-1-git-send-email-hongtao.jia@freescale.com> <2396230.MApG9VTrxr@wuerfel> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Friday 26 February 2016 17:07:09 Li Yang wrote: > > I don't have a perfect solution either. But I think this is still > better than making cpufreq not usable. The cpufreq driver will print > out an error message if thermal is not reachable. Maybe this can > relief the confusion a little bit? With my patch, the configuration will just force the cpufreq driver to be a loadable module as well if thermal is a module, so the dependency can be resolved by loading the thermal module first. I think that is really the best way around the problem, and it matches what other platforms do for the same problem. Arnd