Hi
Thank you for review.
On Mon, Jan 27, 2014 at 5:16 AM, Dmitry Eremin-Solenikov
<dbaryshkov@xxxxxxxxx> wrote:
> On Mon, Jan 27, 2014 at 3:14 AM, Dmitry Torokhov
> <dmitry.torokhov@xxxxxxxxx> wrote:
>> On Mon, Jan 27, 2014 at 02:31:59AM +0400, Dmitry Eremin-Solenikov wrote:
>>> On Mon, Jan 27, 2014 at 1:49 AM, Tomasz Figa <tomasz.figa@xxxxxxxxx> wrote:
>>> > 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@xxxxxxxxx>
>>> >>> 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@xxxxxxxxx>
>>> >>>>> ---
>>> >>>>> :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.
>>>
>>> Hmm. Judging from the code, max8925_power_dt_init() function follows exactly
>>> opposite strategy - it uses platform_data if of_node is not populated/available.
>>> So (if dt_init will compile with CONFIG_OF disabled) one can always
>>> use _dt_init()
>>> function to retrieve pdata.
>>
>> Right, and I question whether this is good behavior or if it should be
>> corrected.
>
> I'd say, correct it.
Okay, I will update code as per Dmitry's feedback.
Regards
Manish Badarkhe
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
