From: Julia Lawall <julia.lawall@lip6.fr>
To: Jingoo Han <jg1.han@samsung.com>
Cc: 'Sachin Kamat' <sachin.kamat@linaro.org>,
'Damien Cassou' <damien.cassou@lifl.fr>,
kernel-janitors@vger.kernel.org,
'Florian Tobias Schandinat' <FlorianSchandinat@gmx.de>,
linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: RE: [PATCH 5/5] drivers/video/exynos/exynos_dp_core.c: use devm_ functions
Date: Wed, 01 Aug 2012 05:13:33 +0000 [thread overview]
Message-ID: <alpine.DEB.2.02.1208010708140.1931@localhost6.localdomain6> (raw)
In-Reply-To: <003f01cd6fa2$36463bd0$a2d2b370$%han@samsung.com>
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@samsung.com> wrote:
>>> On Wednesday, August 01, 2012 1:00 PMSachin Kamat wrote:
>>>>
>>>> On 1 August 2012 04:51, Jingoo Han <jg1.han@samsung.com> wrote:
>>>>> On Wednesday, August 01, 2012 1:39 AM Damien Cassou wrote:
>>>>>>
>>>>>> From: Damien Cassou <damien.cassou@lifl.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@lifl.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
next prev parent reply other threads:[~2012-08-01 5:13 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-31 13:54 [PATCH 0/5] use devm_ functions Damien Cassou
2012-07-31 13:54 ` [PATCH 5/5] drivers/video/ep93xx-fb.c: " Damien Cassou
2012-08-23 20:35 ` Florian Tobias Schandinat
2012-07-31 13:54 ` [PATCH 4/5] drivers/video/da8xx-fb.c: " Damien Cassou
2012-07-31 15:59 ` Sachin Kamat
2012-07-31 16:01 ` Damien Cassou
2012-07-31 13:54 ` [PATCH 3/5] drivers/video/cobalt_lcdfb.c: " Damien Cassou
2012-08-23 20:36 ` Florian Tobias Schandinat
2012-07-31 13:54 ` [PATCH 2/5] drivers/video/bfin-t350mcqb-fb.c: " Damien Cassou
2012-07-31 13:57 ` Mike Frysinger
2012-07-31 16:18 ` Damien Cassou
2012-07-31 13:54 ` [PATCH 1/5] drivers/video/bf537-lq035.c: " Damien Cassou
2012-08-23 20:36 ` Florian Tobias Schandinat
2012-07-31 16:39 ` [PATCH 0/5] " Damien Cassou
2012-07-31 16:39 ` [PATCH 3/5] drivers/video/mbx/mbxfb.c: " Damien Cassou
2012-08-23 20:37 ` Florian Tobias Schandinat
2012-07-31 16:39 ` [PATCH 2/5] drivers/video/gbefb.c: " Damien Cassou
2012-08-23 20:37 ` Florian Tobias Schandinat
2012-09-13 19:06 ` Geert Uytterhoeven
2012-09-20 21:58 ` Florian Tobias Schandinat
2012-10-11 0:38 ` [PATCH] gbefb: fix compile error Florian Tobias Schandinat
2012-07-31 16:39 ` [PATCH 1/5] drivers/video/fsl-diu-fb.c: use devm_ functions Damien Cassou
2012-08-23 20:38 ` Florian Tobias Schandinat
2012-07-31 16:39 ` [PATCH 4/5] drivers/video/exynos/exynos_mipi_dsi.c: " Damien Cassou
2012-07-31 16:39 ` [PATCH 5/5] drivers/video/exynos/exynos_dp_core.c: " Damien Cassou
2012-07-31 23:21 ` Jingoo Han
2012-08-01 4:11 ` Sachin Kamat
2012-08-01 4:30 ` Jingoo Han
2012-08-01 4:50 ` Sachin Kamat
2012-08-01 4:57 ` Jingoo Han
2012-08-01 5:13 ` Julia Lawall [this message]
2012-08-01 5:08 ` Jingoo Han
2012-08-01 16:36 ` Damien Cassou
2012-08-03 15:40 ` [PATCH 0/5] " Damien Cassou
2012-08-03 15:40 ` [PATCH 1/5] drivers/video/epson1355fb.c: " Damien Cassou
2012-08-23 20:40 ` Florian Tobias Schandinat
2012-08-03 15:40 ` [PATCH 3/5] drivers/video/jz4740_fb.c: " Damien Cassou
2012-08-23 20:41 ` Florian Tobias Schandinat
2012-09-02 15:19 ` Lars-Peter Clausen
2012-08-03 15:40 ` [PATCH 2/5] drivers/video/bf54x-lq043fb.c: " Damien Cassou
2012-08-23 20:41 ` Florian Tobias Schandinat
2012-08-03 15:40 ` [PATCH 5/5] drivers/video/msm/mddi_client_nt35399.c: " Damien Cassou
2012-08-06 9:06 ` Dan Carpenter
2012-08-09 17:38 ` David Brown
2012-08-23 20:42 ` Florian Tobias Schandinat
2012-08-03 15:40 ` [PATCH 4/5] drivers/video/msm/mddi_client_dummy.c: " Damien Cassou
2012-08-09 17:39 ` David Brown
2012-08-09 17:57 ` David Brown
2012-08-28 8:42 ` Damien Cassou
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.02.1208010708140.1931@localhost6.localdomain6 \
--to=julia.lawall@lip6.fr \
--cc=FlorianSchandinat@gmx.de \
--cc=damien.cassou@lifl.fr \
--cc=jg1.han@samsung.com \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sachin.kamat@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox