[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.02.1208010708140.1931@localhost6.localdomain6>
Date: Wed, 1 Aug 2012 07:13:33 +0200 (CEST)
From: Julia Lawall <julia.lawall@...6.fr>
To: Jingoo Han <jg1.han@...sung.com>
cc: 'Sachin Kamat' <sachin.kamat@...aro.org>,
'Damien Cassou' <damien.cassou@...l.fr>,
kernel-janitors@...r.kernel.org,
'Florian Tobias Schandinat' <FlorianSchandinat@....de>,
linux-fbdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: RE: [PATCH 5/5] drivers/video/exynos/exynos_dp_core.c: use devm_
functions
On Wed, 1 Aug 2012, Jingoo Han wrote:
> On Wednesday, August 01, 2012 1:38 PM Sachin Kamat wrote:
>>
>> On 1 August 2012 10:00, Jingoo Han <jg1.han@...sung.com> wrote:
>>> On Wednesday, August 01, 2012 1:00 PMSachin Kamat wrote:
>>>>
>>>> On 1 August 2012 04:51, Jingoo Han <jg1.han@...sung.com> wrote:
>>>>> On Wednesday, August 01, 2012 1:39 AM Damien Cassou wrote:
>>>>>>
>>>>>> From: Damien Cassou <damien.cassou@...l.fr>
>>>>>>
>>>>>> The various devm_ functions allocate memory that is released when a driver
>>>>>> detaches. This patch uses these functions for data that is allocated in
>>>>>> the probe function of a platform device and is only freed in the remove
>>>>>> function.
>>>>>>
>>>>>> Signed-off-by: Damien Cassou <damien.cassou@...l.fr>
>>>>>>
>>>>>> ---
>>>>>> drivers/video/exynos/exynos_dp_core.c | 27 +++++++--------------------
>>>>>> 1 file changed, 7 insertions(+), 20 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/video/exynos/exynos_dp_core.c b/drivers/video/exynos/exynos_dp_core.c
>>>>>> index c6c016a..00fe4f0 100644
>>>>>> --- a/drivers/video/exynos/exynos_dp_core.c
>>>>>> +++ b/drivers/video/exynos/exynos_dp_core.c
>>>>>> @@ -872,7 +872,7 @@ static int __devinit exynos_dp_probe(struct platform_device *pdev)
>>>>>>
>>>>>> dp->dev = &pdev->dev;
>>>>>>
>>>>>> - dp->clock = clk_get(&pdev->dev, "dp");
>>>>>> + dp->clock = devm_clk_get(&pdev->dev, "dp");
>>>>>> if (IS_ERR(dp->clock)) {
>>>>>> dev_err(&pdev->dev, "failed to get clock\n");
>>>>>> return PTR_ERR(dp->clock);
>>>>>> @@ -881,31 +881,24 @@ static int __devinit exynos_dp_probe(struct platform_device *pdev)
>>>>>> clk_enable(dp->clock);
>>>>>>
>>>>>> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>>>>> - if (!res) {
>>>>>> - dev_err(&pdev->dev, "failed to get registers\n");
>>>>>> - ret = -EINVAL;
>>>>>> - goto err_clock;
>>>>>> - }
>>>>>
>>>>> Why do you remove this return check?
>>>>> If there is no reason, please, do it as follows:
>>>>>
>>>>> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>>>> if (!res) {
>>>>> dev_err(&pdev->dev, "failed to get registers\n");
>>>>> - ret = -EINVAL;
>>>>> - goto err_clock;
>>>>> + return -EINVAL;
>>>>> }
>>>>>
>>>>>
>>>>
>>>> devm_request_and_ioremap function checks the validity of res. Hence
>>>> this check above is redundant and can be removed.
>>>
>>>
>>> I don't think so.
>>> Even though function called next checks the NULL value,
>>> for robustness, the return value of platform_get_resource() should be
>>> checked.
>>>
>>> It is possible that devm_request_and_ioremap() can be changed in the future,
>>> as request_mem_region() & ioremap() were changed to devm_request_and_ioremap().
>>
>> They are not changed. They still exist. devm_request_and_ioremap() is
>> an additional function provided for device managed resources.
>
>
> OK, I see. I accept it.
> Anyway it is simpler.
This thread contains a discussion about the issue
http://lkml.org/lkml/2012/1/28/10
Look for the comments by Wolfram Sang, who
implemented devm_request_and_ioremap, and who suggests that the NULL test
be removed.
I rather agree with the desire to be safe and uniform, but these
initialization functions are really large, and with error handling code
(although not in this case) there is always the danger of jumping to the
wrong place, and thus making more of a mess. It would be nice if the
platform_get_resource could be merged with devm_request_and_ioremap, but I
think that I looked once and there were not enough calls that were similar
enough to make that compelling.
julia
--
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/
Powered by blists - more mailing lists