linux-kernel - Re: Applied "regulator: max8973: add support for junction thermal warning" to the regulator tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <56DD217E.4090302@nvidia.com>
Date:	Mon, 7 Mar 2016 12:06:46 +0530
From:	Laxman Dewangan <ldewangan@...dia.com>
To:	Mark Brown <broonie@...nel.org>
CC:	<linux-kernel@...r.kernel.org>, <edubezval@...il.com>,
	<rui.zhang@...el.com>
Subject: Re: Applied "regulator: max8973: add support for junction thermal
 warning" to the regulator tree


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?