From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752189AbcCGGt6 (ORCPT ); Mon, 7 Mar 2016 01:49:58 -0500 Received: from hqemgate14.nvidia.com ([216.228.121.143]:2968 "EHLO hqemgate14.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751641AbcCGGtj (ORCPT ); Mon, 7 Mar 2016 01:49:39 -0500 X-PGP-Universal: processed; by hqnvupgp07.nvidia.com on Sun, 06 Mar 2016 22:48:20 -0800 Message-ID: <56DD217E.4090302@nvidia.com> Date: Mon, 7 Mar 2016 12:06:46 +0530 From: Laxman Dewangan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Mark Brown CC: , , Subject: Re: Applied "regulator: max8973: add support for junction thermal warning" to the regulator tree References: <20160306023536.GK18327@sirena.org.uk> <56DBE099.9080408@nvidia.com> <20160306113550.GM18327@sirena.org.uk> In-Reply-To: <20160306113550.GM18327@sirena.org.uk> X-Originating-IP: [10.19.65.30] X-ClientProxiedBy: DRUKMAIL102.nvidia.com (10.25.59.20) To bgmail102.nvidia.com (10.25.59.11) Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sunday 06 March 2016 05:05 PM, Mark Brown wrote: > * PGP Signed by an unknown key > > On Sun, Mar 06, 2016 at 01:17:37PM +0530, Laxman Dewangan wrote: > >> Here driver is built in binary and THERMAL is the loadable module. >> Do we really have THERMAL as module i.e. basic framework? > If randconfig can generate it it's valid. > >> -#ifdef CONFIG_THERMAL_OF >> +#ifdef CONFIG_THERMAL >> static int max8973_thermal_read_temp(void *data, int *temp) >> { >> struct max8973_chip *mchip = data; > That looks like a hack that might break, I'd not expect it to help here > and probably has some other config that can generate issues. What I > think should be happening here is something like > > depends on THERMAL_OF if THERMAL_OF > > or similar (ie, there's a direct dependency once the config is enabled). > 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 failure rand config then REGULATOR_MAX8973 automatically become "m". This may break some existing platform. 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?