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

Laxman Dewangan
2016-03-07T06:49:58Z

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?