linux-kernel - Re: [PATCH] max8925_power: Use "IS_ENABLED(CONFIG

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]

Date:	Sun, 26 Jan 2014 22:49:04 +0100
From:	Tomasz Figa <tomasz.figa@...il.com>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Manish Badarkhe <badarkhe.manish@...il.com>
CC:	"linux-samsung-soc@...r.kernel.org" 
	<linux-samsung-soc@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Dmitry Eremin-Solenikov <dbaryshkov@...il.com>,
	David Woodhouse <dwmw2@...radead.org>
Subject: Re: [PATCH] max8925_power: Use "IS_ENABLED(CONFIG_OF)" for DT code.

On 26.01.2014 22:45, Dmitry Torokhov wrote:
> On Sun, Jan 26, 2014 at 07:31:50PM +0530, Manish Badarkhe wrote:
>> Hi Tomasz,
>>
>> Thank you for your review comments.
>>
>> On Sun, Jan 26, 2014 at 6:52 PM, Tomasz Figa <tomasz.figa@...il.com> wrote:
>>>
>>> Hi Manish,
>>>
>>>
>>> On 26.01.2014 08:15, Manish Badarkhe wrote:
>>>>
>>>> Instead of "#if define CONFIG_OF" use "IS_ENABLED(CONFIG_OF)"
>>>> option for DT code to avoid if-deffery in code.
>>>>
>>>> Signed-off-by: Manish Badarkhe <badarkhe.manish@...il.com>
>>>> ---
>>>> :100644 100644 b4513f2... d353fbc... M  drivers/power/max8925_power.c
>>>>    drivers/power/max8925_power.c |   14 +++++---------
>>>>    1 file changed, 5 insertions(+), 9 deletions(-)
>>>>
>>>> diff --git a/drivers/power/max8925_power.c b/drivers/power/max8925_power.c
>>>> index b4513f2..d353fbc 100644
>>>> --- a/drivers/power/max8925_power.c
>>>> +++ b/drivers/power/max8925_power.c
>>>> @@ -427,7 +427,6 @@ static int max8925_deinit_charger(struct max8925_power_info *info)
>>>>          return 0;
>>>>    }
>>>>
>>>> -#ifdef CONFIG_OF
>>>>    static struct max8925_power_pdata *
>>>>    max8925_power_dt_init(struct platform_device *pdev)
>>>>    {
>>>> @@ -468,13 +467,6 @@ max8925_power_dt_init(struct platform_device *pdev)
>>>>
>>>>          return pdata;
>>>>    }
>>>> -#else
>>>> -static struct max8925_power_pdata *
>>>> -max8925_power_dt_init(struct platform_device *pdev)
>>>> -{
>>>> -       return pdev->dev.platform_data;
>>>> -}
>>>> -#endif
>>>>
>>>>    static int max8925_power_probe(struct platform_device *pdev)
>>>>    {
>>>> @@ -483,7 +475,11 @@ static int max8925_power_probe(struct platform_device *pdev)
>>>>          struct max8925_power_info *info;
>>>>          int ret;
>>>>
>>>> -       pdata = max8925_power_dt_init(pdev);
>>>> +       if (IS_ENABLED(CONFIG_OF))
>>>> +               pdata = max8925_power_dt_init(pdev);
>>>> +       else
>>>> +               pdata = pdev->dev.platform_data;
>>>> +
>>>
>>>
>>> This does not look much better than before this patch. Instead of "if-deffery" outside function bodies you are adding "iffery" (if there is such a word) inside a function.
>>> What about adding
>>>
>>>          if (!IS_ENABLED(CONFIG_OF))
>>>                  return pdev->dev.platform_data;
>>>
>>> on top of max8925_power_dt_init() instead or maybe also renaming this function to max8925_get_pdata()?
>>
>> Okay, I will rename function "max8925_power_dt_init()" to "max8925_get_pdata()".
>> As you suggested, in the body of this function  will add a logic to
>> retrieve  data in case
>> of DT and non-DT platforms.
>
> Should we not always favor platform-supplied data regardless of
> CONFIG_OF state and fall back to DT (firmware) supplied data if platform
> data is absent? This way one can tweak kernel behavior without needing
> to change firmware.

I guess we should, but apparently this was not the original behavior 
before this patch, so I'm not sure if we should be squashing such 
semantic change with this simple refactor.

Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/