linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] staging: media: atomisp: Fix error path in lm3554_probe()
@ 2020-09-02 18:41 Alex Dewar
  2020-09-03 12:11 ` Dan Carpenter
  0 siblings, 1 reply; 8+ messages in thread
From: Alex Dewar @ 2020-09-02 18:41 UTC (permalink / raw)
  Cc: Alex Dewar, Mauro Carvalho Chehab, Sakari Ailus,
	Greg Kroah-Hartman, Linus Walleij, Alan Cox, linux-media, devel,
	linux-kernel

The error path for lm3554_probe() contains a number of bugs, including:
 * resource leaks
 * jumping to error labels out of sequence
 * not setting the return value appropriately

Fix it up and give the labels more memorable names.

This issue has existed since the code was originally contributed in
commit a49d25364dfb ("staging/atomisp: Add support for the Intel IPU v2"),
although the code was subsequently removed altogether and then
reinstated with commit ad85094b293e ("Revert "media: staging: atomisp: Remove driver"").

Addresses-Coverity: ("Resource leak")
Fixes: a49d25364dfb ("staging/atomisp: Add support for the Intel IPU v2")
Signed-off-by: Alex Dewar <alex.dewar90@gmail.com>
---
 .../media/atomisp/i2c/atomisp-lm3554.c        | 47 ++++++++++---------
 1 file changed, 25 insertions(+), 22 deletions(-)

diff --git a/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c b/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c
index 7ca7378b1859..9aad6721fc84 100644
--- a/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c
+++ b/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c
@@ -833,7 +833,6 @@ static void *lm3554_platform_data_func(struct i2c_client *client)
 
 static int lm3554_probe(struct i2c_client *client)
 {
-	int err = 0;
 	struct lm3554 *flash;
 	unsigned int i;
 	int ret;
@@ -843,36 +842,38 @@ static int lm3554_probe(struct i2c_client *client)
 		return -ENOMEM;
 
 	flash->pdata = lm3554_platform_data_func(client);
-	if (IS_ERR(flash->pdata))
-		return PTR_ERR(flash->pdata);
+	if (IS_ERR(flash->pdata)) {
+		ret = PTR_ERR(flash->pdata);
+		goto err_free_flash;
+	}
 
 	v4l2_i2c_subdev_init(&flash->sd, client, &lm3554_ops);
 	flash->sd.internal_ops = &lm3554_internal_ops;
 	flash->sd.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
 	flash->mode = ATOMISP_FLASH_MODE_OFF;
 	flash->timeout = LM3554_MAX_TIMEOUT / LM3554_TIMEOUT_STEPSIZE - 1;
-	ret =
-	    v4l2_ctrl_handler_init(&flash->ctrl_handler,
-				   ARRAY_SIZE(lm3554_controls));
+	ret = v4l2_ctrl_handler_init(&flash->ctrl_handler,
+				     ARRAY_SIZE(lm3554_controls));
 	if (ret) {
-		dev_err(&client->dev, "error initialize a ctrl_handler.\n");
-		goto fail2;
+		dev_err(&client->dev, "error initializing ctrl_handler");
+		goto err_unregister_sd;
 	}
 
 	for (i = 0; i < ARRAY_SIZE(lm3554_controls); i++)
 		v4l2_ctrl_new_custom(&flash->ctrl_handler, &lm3554_controls[i],
 				     NULL);
 
-	if (flash->ctrl_handler.error) {
-		dev_err(&client->dev, "ctrl_handler error.\n");
-		goto fail2;
+	ret = flash->ctrl_handler.error;
+	if (ret) {
+		dev_err(&client->dev, "ctrl_handler error");
+		goto err_free_ctrl_handler;
 	}
 
 	flash->sd.ctrl_handler = &flash->ctrl_handler;
-	err = media_entity_pads_init(&flash->sd.entity, 0, NULL);
-	if (err) {
-		dev_err(&client->dev, "error initialize a media entity.\n");
-		goto fail1;
+	ret = media_entity_pads_init(&flash->sd.entity, 0, NULL);
+	if (ret) {
+		dev_err(&client->dev, "error initializing media entity");
+		goto err_free_ctrl_handler;
 	}
 
 	flash->sd.entity.function = MEDIA_ENT_F_FLASH;
@@ -881,20 +882,22 @@ static int lm3554_probe(struct i2c_client *client)
 
 	timer_setup(&flash->flash_off_delay, lm3554_flash_off_delay, 0);
 
-	err = lm3554_gpio_init(client);
-	if (err) {
+	ret = lm3554_gpio_init(client);
+	if (ret) {
 		dev_err(&client->dev, "gpio request/direction_output fail");
-		goto fail2;
+		goto err_cleanup_entity;
 	}
 	return atomisp_register_i2c_module(&flash->sd, NULL, LED_FLASH);
-fail2:
+
+err_cleanup_entity:
 	media_entity_cleanup(&flash->sd.entity);
+err_free_ctrl_handler:
 	v4l2_ctrl_handler_free(&flash->ctrl_handler);
-fail1:
+err_unregister_sd:
 	v4l2_device_unregister_subdev(&flash->sd);
+err_free_flash:
 	kfree(flash);
-
-	return err;
+	return ret;
 }
 
 static int lm3554_remove(struct i2c_client *client)
-- 
2.28.0


^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: [PATCH] staging: media: atomisp: Fix error path in lm3554_probe()
  2020-09-02 18:41 [PATCH] staging: media: atomisp: Fix error path in lm3554_probe() Alex Dewar
@ 2020-09-03 12:11 ` Dan Carpenter
  2020-09-03 15:48   ` Alex Dewar
  0 siblings, 1 reply; 8+ messages in thread
From: Dan Carpenter @ 2020-09-03 12:11 UTC (permalink / raw)
  To: Alex Dewar
  Cc: devel, Greg Kroah-Hartman, Linus Walleij, linux-media,
	linux-kernel, Sakari Ailus, Mauro Carvalho Chehab, Alan Cox

On Wed, Sep 02, 2020 at 07:41:50PM +0100, Alex Dewar wrote:
> The error path for lm3554_probe() contains a number of bugs, including:
>  * resource leaks
>  * jumping to error labels out of sequence
>  * not setting the return value appropriately
> 
> Fix it up and give the labels more memorable names.
> 
> This issue has existed since the code was originally contributed in
> commit a49d25364dfb ("staging/atomisp: Add support for the Intel IPU v2"),
> although the code was subsequently removed altogether and then
> reinstated with commit ad85094b293e ("Revert "media: staging: atomisp: Remove driver"").
> 

Almost perfect!  Just a couple other leaks we should fix as well.

> +	ret = media_entity_pads_init(&flash->sd.entity, 0, NULL);
> +	if (ret) {
> +		dev_err(&client->dev, "error initializing media entity");
> +		goto err_free_ctrl_handler;
>  	}
>  
>  	flash->sd.entity.function = MEDIA_ENT_F_FLASH;
> @@ -881,20 +882,22 @@ static int lm3554_probe(struct i2c_client *client)
>  
>  	timer_setup(&flash->flash_off_delay, lm3554_flash_off_delay, 0);

We need to delete this timer.

>  
> -	err = lm3554_gpio_init(client);
> -	if (err) {
> +	ret = lm3554_gpio_init(client);
> +	if (ret) {
>  		dev_err(&client->dev, "gpio request/direction_output fail");
> -		goto fail2;
> +		goto err_cleanup_entity;
>  	}
>  	return atomisp_register_i2c_module(&flash->sd, NULL, LED_FLASH);

If atomisp_register_i2c_module() fails then we need to call
lm3554_gpio_uninit(client) and do other cleanup.

> -fail2:
> +
> +err_cleanup_entity:
>  	media_entity_cleanup(&flash->sd.entity);
> +err_free_ctrl_handler:
>  	v4l2_ctrl_handler_free(&flash->ctrl_handler);

regards,
dan carpenter


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] staging: media: atomisp: Fix error path in lm3554_probe()
  2020-09-03 12:11 ` Dan Carpenter
@ 2020-09-03 15:48   ` Alex Dewar
  2020-09-03 17:38     ` Dan Carpenter
  0 siblings, 1 reply; 8+ messages in thread
From: Alex Dewar @ 2020-09-03 15:48 UTC (permalink / raw)
  To: Dan Carpenter
  Cc: Alex Dewar, devel, Greg Kroah-Hartman, Linus Walleij,
	linux-media, linux-kernel, Sakari Ailus, Mauro Carvalho Chehab,
	Alan Cox

Good point about the timer!

> >  
> > -	err = lm3554_gpio_init(client);
> > -	if (err) {
> > +	ret = lm3554_gpio_init(client);
> > +	if (ret) {
> >  		dev_err(&client->dev, "gpio request/direction_output fail");
> > -		goto fail2;
> > +		goto err_cleanup_entity;
> >  	}
> >  	return atomisp_register_i2c_module(&flash->sd, NULL, LED_FLASH);
> 
> If atomisp_register_i2c_module() fails then we need to call
> lm3554_gpio_uninit(client) and do other cleanup.

I'm probably showing my ignorance here, but I can't see what cleanup we
need. Inside lm3554_gpio_init we have:

	ret = gpiod_direction_output(pdata->gpio_reset, 0);
	if (ret < 0)
		return ret;
	dev_info(&client->dev, "flash led reset successfully\n");

	if (!pdata->gpio_strobe)
		return -EINVAL;

	ret = gpiod_direction_output(pdata->gpio_strobe, 0);
	if (ret < 0)
		return ret;

I'm not sure how you "undo" a call to gpiod_direction_output, but I'm
thinking you won't need to do anything because it should be ok to leave
a gpio to output 0... right?

Alex

> 
> > -fail2:
> > +
> > +err_cleanup_entity:
> >  	media_entity_cleanup(&flash->sd.entity);
> > +err_free_ctrl_handler:
> >  	v4l2_ctrl_handler_free(&flash->ctrl_handler);
> 
> regards,
> dan carpenter
> 

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] staging: media: atomisp: Fix error path in lm3554_probe()
  2020-09-03 15:48   ` Alex Dewar
@ 2020-09-03 17:38     ` Dan Carpenter
  2020-09-03 18:21       ` Alex Dewar
  2020-09-03 18:24       ` [PATCH v2] " Alex Dewar
  0 siblings, 2 replies; 8+ messages in thread
From: Dan Carpenter @ 2020-09-03 17:38 UTC (permalink / raw)
  To: Alex Dewar
  Cc: devel, Alan Cox, Greg Kroah-Hartman, Linus Walleij, linux-kernel,
	Sakari Ailus, Mauro Carvalho Chehab, linux-media

On Thu, Sep 03, 2020 at 04:48:41PM +0100, Alex Dewar wrote:
> Good point about the timer!
> 
> > >  
> > > -	err = lm3554_gpio_init(client);
> > > -	if (err) {
> > > +	ret = lm3554_gpio_init(client);
> > > +	if (ret) {
> > >  		dev_err(&client->dev, "gpio request/direction_output fail");
> > > -		goto fail2;
> > > +		goto err_cleanup_entity;
> > >  	}
> > >  	return atomisp_register_i2c_module(&flash->sd, NULL, LED_FLASH);
> > 
> > If atomisp_register_i2c_module() fails then we need to call
> > lm3554_gpio_uninit(client) and do other cleanup.
> 
> I'm probably showing my ignorance here, but I can't see what cleanup we
> need. Inside lm3554_gpio_init we have:
> 
> 	ret = gpiod_direction_output(pdata->gpio_reset, 0);
> 	if (ret < 0)
> 		return ret;
> 	dev_info(&client->dev, "flash led reset successfully\n");
> 
> 	if (!pdata->gpio_strobe)
> 		return -EINVAL;
> 
> 	ret = gpiod_direction_output(pdata->gpio_strobe, 0);
> 	if (ret < 0)
> 		return ret;
> 
> I'm not sure how you "undo" a call to gpiod_direction_output, but I'm
> thinking you won't need to do anything because it should be ok to leave
> a gpio to output 0... right?

You're right.  I wonder if there is really any need for the
lm3554_gpio_uninit() function at all?  It's basically the same as
lm3554_gpio_init() except for the order of function calls.  Probably
we could just rename lm3554_gpio_init() to something like
lm3554_gpio_set_default() and use it in both the probe() and remove
functions()...

But I don't know the code and can't test it so let's leave that for
another day.

We still do need to clean up if atomisp_register_i2c_module() fails
though, and the timer as well so could you resend a v2?

regards,
dan carpenter


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] staging: media: atomisp: Fix error path in lm3554_probe()
  2020-09-03 17:38     ` Dan Carpenter
@ 2020-09-03 18:21       ` Alex Dewar
  2020-09-03 18:24       ` [PATCH v2] " Alex Dewar
  1 sibling, 0 replies; 8+ messages in thread
From: Alex Dewar @ 2020-09-03 18:21 UTC (permalink / raw)
  To: Dan Carpenter
  Cc: Alex Dewar, devel, Alan Cox, Greg Kroah-Hartman, Linus Walleij,
	linux-kernel, Sakari Ailus, Mauro Carvalho Chehab, linux-media

> You're right.  I wonder if there is really any need for the
> lm3554_gpio_uninit() function at all?  It's basically the same as
> lm3554_gpio_init() except for the order of function calls.  Probably
> we could just rename lm3554_gpio_init() to something like
> lm3554_gpio_set_default() and use it in both the probe() and remove
> functions()...

I think you probably also don't want to return error values from
lm3554_gpio_uninit() as it is only called on module removal, so it'd
probably make more sense to just print a warning and carry on. I'll do
this as a separate patch and send it to the list, though.

v2 to follow...

> 
> But I don't know the code and can't test it so let's leave that for
> another day.
> 
> We still do need to clean up if atomisp_register_i2c_module() fails
> though, and the timer as well so could you resend a v2?
> 
> regards,
> dan carpenter
> 

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [PATCH v2] staging: media: atomisp: Fix error path in lm3554_probe()
  2020-09-03 17:38     ` Dan Carpenter
  2020-09-03 18:21       ` Alex Dewar
@ 2020-09-03 18:24       ` Alex Dewar
  2020-09-04  6:35         ` Dan Carpenter
  2020-09-19 19:50         ` Alex Dewar
  1 sibling, 2 replies; 8+ messages in thread
From: Alex Dewar @ 2020-09-03 18:24 UTC (permalink / raw)
  To: dan.carpenter
  Cc: Alex Dewar, Mauro Carvalho Chehab, Sakari Ailus,
	Greg Kroah-Hartman, Linus Walleij, Alan Cox, linux-media, devel,
	linux-kernel

The error path for lm3554_probe() contains a number of bugs, including:
 * resource leaks
 * jumping to error labels out of sequence
 * not setting the return value appropriately

Fix it up and give the labels more memorable names.

This issue has existed since the code was originally contributed in
commit a49d25364dfb ("staging/atomisp: Add support for the Intel IPU v2"),
although the code was subsequently removed altogether and then
reinstated with commit ad85094b293e ("Revert "media: staging: atomisp: Remove driver"").

Addresses-Coverity: 1496802 ("Resource leaks")
Fixes: a49d25364dfb ("staging/atomisp: Add support for the Intel IPU v2")
Signed-off-by: Alex Dewar <alex.dewar90@gmail.com>
---
 .../media/atomisp/i2c/atomisp-lm3554.c        | 53 +++++++++++--------
 1 file changed, 30 insertions(+), 23 deletions(-)

diff --git a/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c b/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c
index 7ca7378b1859..cca10a4c2db0 100644
--- a/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c
+++ b/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c
@@ -833,7 +833,6 @@ static void *lm3554_platform_data_func(struct i2c_client *client)
 
 static int lm3554_probe(struct i2c_client *client)
 {
-	int err = 0;
 	struct lm3554 *flash;
 	unsigned int i;
 	int ret;
@@ -843,36 +842,38 @@ static int lm3554_probe(struct i2c_client *client)
 		return -ENOMEM;
 
 	flash->pdata = lm3554_platform_data_func(client);
-	if (IS_ERR(flash->pdata))
-		return PTR_ERR(flash->pdata);
+	if (IS_ERR(flash->pdata)) {
+		ret = PTR_ERR(flash->pdata);
+		goto err_free_flash;
+	}
 
 	v4l2_i2c_subdev_init(&flash->sd, client, &lm3554_ops);
 	flash->sd.internal_ops = &lm3554_internal_ops;
 	flash->sd.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
 	flash->mode = ATOMISP_FLASH_MODE_OFF;
 	flash->timeout = LM3554_MAX_TIMEOUT / LM3554_TIMEOUT_STEPSIZE - 1;
-	ret =
-	    v4l2_ctrl_handler_init(&flash->ctrl_handler,
-				   ARRAY_SIZE(lm3554_controls));
+	ret = v4l2_ctrl_handler_init(&flash->ctrl_handler,
+				     ARRAY_SIZE(lm3554_controls));
 	if (ret) {
-		dev_err(&client->dev, "error initialize a ctrl_handler.\n");
-		goto fail2;
+		dev_err(&client->dev, "error initializing ctrl_handler");
+		goto err_unregister_sd;
 	}
 
 	for (i = 0; i < ARRAY_SIZE(lm3554_controls); i++)
 		v4l2_ctrl_new_custom(&flash->ctrl_handler, &lm3554_controls[i],
 				     NULL);
 
-	if (flash->ctrl_handler.error) {
-		dev_err(&client->dev, "ctrl_handler error.\n");
-		goto fail2;
+	ret = flash->ctrl_handler.error;
+	if (ret) {
+		dev_err(&client->dev, "ctrl_handler error");
+		goto err_free_ctrl_handler;
 	}
 
 	flash->sd.ctrl_handler = &flash->ctrl_handler;
-	err = media_entity_pads_init(&flash->sd.entity, 0, NULL);
-	if (err) {
-		dev_err(&client->dev, "error initialize a media entity.\n");
-		goto fail1;
+	ret = media_entity_pads_init(&flash->sd.entity, 0, NULL);
+	if (ret) {
+		dev_err(&client->dev, "error initializing media entity");
+		goto err_free_ctrl_handler;
 	}
 
 	flash->sd.entity.function = MEDIA_ENT_F_FLASH;
@@ -881,20 +882,26 @@ static int lm3554_probe(struct i2c_client *client)
 
 	timer_setup(&flash->flash_off_delay, lm3554_flash_off_delay, 0);
 
-	err = lm3554_gpio_init(client);
-	if (err) {
+	ret = lm3554_gpio_init(client);
+	if (ret) {
 		dev_err(&client->dev, "gpio request/direction_output fail");
-		goto fail2;
+		goto err_del_timer;
 	}
-	return atomisp_register_i2c_module(&flash->sd, NULL, LED_FLASH);
-fail2:
+
+	ret = atomisp_register_i2c_module(&flash->sd, NULL, LED_FLASH);
+	if (!ret)
+		return 0;
+
+err_del_timer:
+	del_timer_sync(&flash->flash_off_delay);
 	media_entity_cleanup(&flash->sd.entity);
+err_free_ctrl_handler:
 	v4l2_ctrl_handler_free(&flash->ctrl_handler);
-fail1:
+err_unregister_sd:
 	v4l2_device_unregister_subdev(&flash->sd);
+err_free_flash:
 	kfree(flash);
-
-	return err;
+	return ret;
 }
 
 static int lm3554_remove(struct i2c_client *client)
-- 
2.28.0


^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: [PATCH v2] staging: media: atomisp: Fix error path in lm3554_probe()
  2020-09-03 18:24       ` [PATCH v2] " Alex Dewar
@ 2020-09-04  6:35         ` Dan Carpenter
  2020-09-19 19:50         ` Alex Dewar
  1 sibling, 0 replies; 8+ messages in thread
From: Dan Carpenter @ 2020-09-04  6:35 UTC (permalink / raw)
  To: Alex Dewar
  Cc: Mauro Carvalho Chehab, Sakari Ailus, Greg Kroah-Hartman,
	Linus Walleij, Alan Cox, linux-media, devel, linux-kernel

On Thu, Sep 03, 2020 at 07:24:51PM +0100, Alex Dewar wrote:
> +
> +	ret = atomisp_register_i2c_module(&flash->sd, NULL, LED_FLASH);
> +	if (!ret)
> +		return 0;

Ugh!!!  This is a a special case of the "success handling instead of
failure handling" anti-pattern where the last condition in the function
is different.  I just fixed a bug caused by this on Wed.

https://www.spinics.net/lists/netdev/msg680226.html

But it doesn't cause any problems here so whatever...

Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>

regards,
dan carpenter


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH v2] staging: media: atomisp: Fix error path in lm3554_probe()
  2020-09-03 18:24       ` [PATCH v2] " Alex Dewar
  2020-09-04  6:35         ` Dan Carpenter
@ 2020-09-19 19:50         ` Alex Dewar
  1 sibling, 0 replies; 8+ messages in thread
From: Alex Dewar @ 2020-09-19 19:50 UTC (permalink / raw)
  To: dan.carpenter
  Cc: Mauro Carvalho Chehab, Sakari Ailus, Greg Kroah-Hartman,
	Linus Walleij, Alan Cox, linux-media, devel, linux-kernel

On 2020-09-03 19:24, Alex Dewar wrote:
> The error path for lm3554_probe() contains a number of bugs, including:
>   * resource leaks
>   * jumping to error labels out of sequence
>   * not setting the return value appropriately
Ping?
>
> Fix it up and give the labels more memorable names.
>
> This issue has existed since the code was originally contributed in
> commit a49d25364dfb ("staging/atomisp: Add support for the Intel IPU v2"),
> although the code was subsequently removed altogether and then
> reinstated with commit ad85094b293e ("Revert "media: staging: atomisp: Remove driver"").
>
> Addresses-Coverity: 1496802 ("Resource leaks")
> Fixes: a49d25364dfb ("staging/atomisp: Add support for the Intel IPU v2")
> Signed-off-by: Alex Dewar <alex.dewar90@gmail.com>
> ---
>   .../media/atomisp/i2c/atomisp-lm3554.c        | 53 +++++++++++--------
>   1 file changed, 30 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c b/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c
> index 7ca7378b1859..cca10a4c2db0 100644
> --- a/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c
> +++ b/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c
> @@ -833,7 +833,6 @@ static void *lm3554_platform_data_func(struct i2c_client *client)
>   
>   static int lm3554_probe(struct i2c_client *client)
>   {
> -	int err = 0;
>   	struct lm3554 *flash;
>   	unsigned int i;
>   	int ret;
> @@ -843,36 +842,38 @@ static int lm3554_probe(struct i2c_client *client)
>   		return -ENOMEM;
>   
>   	flash->pdata = lm3554_platform_data_func(client);
> -	if (IS_ERR(flash->pdata))
> -		return PTR_ERR(flash->pdata);
> +	if (IS_ERR(flash->pdata)) {
> +		ret = PTR_ERR(flash->pdata);
> +		goto err_free_flash;
> +	}
>   
>   	v4l2_i2c_subdev_init(&flash->sd, client, &lm3554_ops);
>   	flash->sd.internal_ops = &lm3554_internal_ops;
>   	flash->sd.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
>   	flash->mode = ATOMISP_FLASH_MODE_OFF;
>   	flash->timeout = LM3554_MAX_TIMEOUT / LM3554_TIMEOUT_STEPSIZE - 1;
> -	ret =
> -	    v4l2_ctrl_handler_init(&flash->ctrl_handler,
> -				   ARRAY_SIZE(lm3554_controls));
> +	ret = v4l2_ctrl_handler_init(&flash->ctrl_handler,
> +				     ARRAY_SIZE(lm3554_controls));
>   	if (ret) {
> -		dev_err(&client->dev, "error initialize a ctrl_handler.\n");
> -		goto fail2;
> +		dev_err(&client->dev, "error initializing ctrl_handler");
> +		goto err_unregister_sd;
>   	}
>   
>   	for (i = 0; i < ARRAY_SIZE(lm3554_controls); i++)
>   		v4l2_ctrl_new_custom(&flash->ctrl_handler, &lm3554_controls[i],
>   				     NULL);
>   
> -	if (flash->ctrl_handler.error) {
> -		dev_err(&client->dev, "ctrl_handler error.\n");
> -		goto fail2;
> +	ret = flash->ctrl_handler.error;
> +	if (ret) {
> +		dev_err(&client->dev, "ctrl_handler error");
> +		goto err_free_ctrl_handler;
>   	}
>   
>   	flash->sd.ctrl_handler = &flash->ctrl_handler;
> -	err = media_entity_pads_init(&flash->sd.entity, 0, NULL);
> -	if (err) {
> -		dev_err(&client->dev, "error initialize a media entity.\n");
> -		goto fail1;
> +	ret = media_entity_pads_init(&flash->sd.entity, 0, NULL);
> +	if (ret) {
> +		dev_err(&client->dev, "error initializing media entity");
> +		goto err_free_ctrl_handler;
>   	}
>   
>   	flash->sd.entity.function = MEDIA_ENT_F_FLASH;
> @@ -881,20 +882,26 @@ static int lm3554_probe(struct i2c_client *client)
>   
>   	timer_setup(&flash->flash_off_delay, lm3554_flash_off_delay, 0);
>   
> -	err = lm3554_gpio_init(client);
> -	if (err) {
> +	ret = lm3554_gpio_init(client);
> +	if (ret) {
>   		dev_err(&client->dev, "gpio request/direction_output fail");
> -		goto fail2;
> +		goto err_del_timer;
>   	}
> -	return atomisp_register_i2c_module(&flash->sd, NULL, LED_FLASH);
> -fail2:
> +
> +	ret = atomisp_register_i2c_module(&flash->sd, NULL, LED_FLASH);
> +	if (!ret)
> +		return 0;
> +
> +err_del_timer:
> +	del_timer_sync(&flash->flash_off_delay);
>   	media_entity_cleanup(&flash->sd.entity);
> +err_free_ctrl_handler:
>   	v4l2_ctrl_handler_free(&flash->ctrl_handler);
> -fail1:
> +err_unregister_sd:
>   	v4l2_device_unregister_subdev(&flash->sd);
> +err_free_flash:
>   	kfree(flash);
> -
> -	return err;
> +	return ret;
>   }
>   
>   static int lm3554_remove(struct i2c_client *client)


^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2020-09-19 19:50 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-02 18:41 [PATCH] staging: media: atomisp: Fix error path in lm3554_probe() Alex Dewar
2020-09-03 12:11 ` Dan Carpenter
2020-09-03 15:48   ` Alex Dewar
2020-09-03 17:38     ` Dan Carpenter
2020-09-03 18:21       ` Alex Dewar
2020-09-03 18:24       ` [PATCH v2] " Alex Dewar
2020-09-04  6:35         ` Dan Carpenter
2020-09-19 19:50         ` Alex Dewar

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).