The devm_ functions allocate memory that is released when a driver
detaches. This patch uses devm_kzalloc of these functions.
Cc: Dmitry Baryshkov <[email protected]>
Cc: Richard Purdie <[email protected]>
Signed-off-by: Jingoo Han <[email protected]>
---
drivers/video/backlight/tosa_bl.c | 11 +++++------
1 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/video/backlight/tosa_bl.c b/drivers/video/backlight/tosa_bl.c
index 2b241ab..0d54e60 100644
--- a/drivers/video/backlight/tosa_bl.c
+++ b/drivers/video/backlight/tosa_bl.c
@@ -82,8 +82,11 @@ static int __devinit tosa_bl_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
struct backlight_properties props;
- struct tosa_bl_data *data = kzalloc(sizeof(struct tosa_bl_data), GFP_KERNEL);
+ struct tosa_bl_data *data;
int ret = 0;
+
+ data = devm_kzalloc(&client->dev, sizeof(struct tosa_bl_data),
+ GFP_KERNEL);
if (!data)
return -ENOMEM;
@@ -92,7 +95,7 @@ static int __devinit tosa_bl_probe(struct i2c_client *client,
ret = gpio_request(TOSA_GPIO_BL_C20MA, "backlight");
if (ret) {
dev_dbg(&data->bl->dev, "Unable to request gpio!\n");
- goto err_gpio_bl;
+ return ret;
}
ret = gpio_direction_output(TOSA_GPIO_BL_C20MA, 0);
if (ret)
@@ -122,8 +125,6 @@ err_reg:
data->bl = NULL;
err_gpio_dir:
gpio_free(TOSA_GPIO_BL_C20MA);
-err_gpio_bl:
- kfree(data);
return ret;
}
@@ -136,8 +137,6 @@ static int __devexit tosa_bl_remove(struct i2c_client *client)
gpio_free(TOSA_GPIO_BL_C20MA);
- kfree(data);
-
return 0;
}
--
1.7.1
On Fri, May 25, 2012 at 6:30 AM, Jingoo Han <[email protected]> wrote:
> The devm_ functions allocate memory that is released when a driver
> detaches. This patch uses devm_kzalloc of these functions.
Strictly speaking I see no point in this changes. There are no
'missing free' problems
in these drivers, the code path is clean enough. Is devm_kzalloc usage some kind
of policy, or it is just a future-proof change?
>
> Cc: Dmitry Baryshkov <[email protected]>
> Cc: Richard Purdie <[email protected]>
> Signed-off-by: Jingoo Han <[email protected]>
> ---
> ?drivers/video/backlight/tosa_bl.c | ? 11 +++++------
> ?1 files changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/video/backlight/tosa_bl.c b/drivers/video/backlight/tosa_bl.c
> index 2b241ab..0d54e60 100644
> --- a/drivers/video/backlight/tosa_bl.c
> +++ b/drivers/video/backlight/tosa_bl.c
> @@ -82,8 +82,11 @@ static int __devinit tosa_bl_probe(struct i2c_client *client,
> ? ? ? ? ? ? ? ?const struct i2c_device_id *id)
> ?{
> ? ? ? ?struct backlight_properties props;
> - ? ? ? struct tosa_bl_data *data = kzalloc(sizeof(struct tosa_bl_data), GFP_KERNEL);
> + ? ? ? struct tosa_bl_data *data;
> ? ? ? ?int ret = 0;
> +
> + ? ? ? data = devm_kzalloc(&client->dev, sizeof(struct tosa_bl_data),
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? GFP_KERNEL);
> ? ? ? ?if (!data)
> ? ? ? ? ? ? ? ?return -ENOMEM;
>
> @@ -92,7 +95,7 @@ static int __devinit tosa_bl_probe(struct i2c_client *client,
> ? ? ? ?ret = gpio_request(TOSA_GPIO_BL_C20MA, "backlight");
> ? ? ? ?if (ret) {
> ? ? ? ? ? ? ? ?dev_dbg(&data->bl->dev, "Unable to request gpio!\n");
> - ? ? ? ? ? ? ? goto err_gpio_bl;
> + ? ? ? ? ? ? ? return ret;
> ? ? ? ?}
> ? ? ? ?ret = gpio_direction_output(TOSA_GPIO_BL_C20MA, 0);
> ? ? ? ?if (ret)
> @@ -122,8 +125,6 @@ err_reg:
> ? ? ? ?data->bl = NULL;
> ?err_gpio_dir:
> ? ? ? ?gpio_free(TOSA_GPIO_BL_C20MA);
> -err_gpio_bl:
> - ? ? ? kfree(data);
> ? ? ? ?return ret;
> ?}
>
> @@ -136,8 +137,6 @@ static int __devexit tosa_bl_remove(struct i2c_client *client)
>
> ? ? ? ?gpio_free(TOSA_GPIO_BL_C20MA);
>
> - ? ? ? kfree(data);
> -
> ? ? ? ?return 0;
> ?}
>
> --
> 1.7.1
>
>
--
With best wishes
Dmitry
On Sat, May 26, 2012 at 10:43:07AM +0400, Dmitry Eremin-Solenikov wrote:
> On Fri, May 25, 2012 at 6:30 AM, Jingoo Han <[email protected]> wrote:
> > The devm_ functions allocate memory that is released when a driver
> > detaches. This patch uses devm_kzalloc of these functions.
> Strictly speaking I see no point in this changes. There are no
> 'missing free' problems
> in these drivers, the code path is clean enough. Is devm_kzalloc usage some kind
> of policy, or it is just a future-proof change?
It does provide robustness against future changes and it's also the more
current style; if nothing else it helps anyone who wants to go and audit
for leaks.