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

[Laxman Dewangan]

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?