From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752301AbcCGHoY (ORCPT ); Mon, 7 Mar 2016 02:44:24 -0500 Received: from mezzanine.sirena.org.uk ([106.187.55.193]:39882 "EHLO mezzanine.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752186AbcCGHoQ (ORCPT ); Mon, 7 Mar 2016 02:44:16 -0500 Date: Mon, 7 Mar 2016 14:44:10 +0700 From: Mark Brown To: Laxman Dewangan Cc: linux-kernel@vger.kernel.org, edubezval@gmail.com, rui.zhang@intel.com Message-ID: <20160307074409.GS18327@sirena.org.uk> References: <20160306023536.GK18327@sirena.org.uk> <56DBE099.9080408@nvidia.com> <20160306113550.GM18327@sirena.org.uk> <56DD217E.4090302@nvidia.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="MYnrjQCML8kMrkVg" Content-Disposition: inline In-Reply-To: <56DD217E.4090302@nvidia.com> X-Cookie: Adapt. Enjoy. Survive. User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: 110.170.137.3 X-SA-Exim-Mail-From: broonie@sirena.org.uk Subject: Re: Applied "regulator: max8973: add support for junction thermal warning" to the regulator tree X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on mezzanine.sirena.org.uk) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --MYnrjQCML8kMrkVg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Mar 07, 2016 at 12:06:46PM +0530, Laxman Dewangan wrote: > Following will not help > depends on THERMAL_OF if THERMAL_OF > because THERMAL_OF is always "y" even if THERMAL is "m". > Build error can by resolved by adding below in the Kconfig > depends on THERMAL > but the issue is if THERMAL is "m" and REGULATOR_MAX8973 is "y" as per the So that should be depends on THERMAL if THERMAL_OF > failure rand config then REGULATOR_MAX8973 automatically become "m". This > may break some existing platform. That's an inevitable consequence of adding this support, you can't get around it. > Also this driver does not need hard dependency in the thermal as max8973 > does not support thermal but max77621 supports it which is again optional. > Some of driver use > drivers/power/charger-manager.c:#ifdef CONFIG_THERMAL > drivers/power/power_supply_core.c:#ifdef CONFIG_THERMAL > So can we give the similar try here and test for build? This is still a hack; if this is causing real problems the thermal subsystem should be doing something to avoid the issue (for example providing an always built in stub) though I suspect in reality it's not a practical issue. --MYnrjQCML8kMrkVg Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJW3TFIAAoJECTWi3JdVIfQarAH/1ss+S1CdM7ZsknP18RdRfqY xVWb73+cBHN35ZbxoqTlem9mn7V0Moxh+HS1cpgTVoZ8xjbW8zryRvEG0oOwThJ1 aFvt1df70CQEnVDIEg8Xdxlal3vjiptJ3nr/BVpK/Nd7khbq2IVrnrsObD1KaAVz wpKTCRz++/uBIJ1snSB9vIbeKihAwyCF56E7y0/LKZJrmcd7qwi61vNyqqKsADnU TulE0hh7nMz81kOYYuFQosmhYXhtEQTn1muyqTpeNKMcfpryvULZg/xCAzt4US67 yffgyjP5u7nXjxq+jQF2ZVRt4ayoWGACqzGC77E8TPPit4hmYSKn2UOZPzUG/vc= =caPY -----END PGP SIGNATURE----- --MYnrjQCML8kMrkVg--