[PATCH] ASoC: ti: omap-mcbsp: Fix an error handling path in 'asoc_mcbsp_probe()'

[PATCH] ASoC: ti: omap-mcbsp: Fix an error handling path in 'asoc_mcbsp_probe()'

[Christophe JAILLET]

If an error occurs after the call to 'omap_mcbsp_init()', the reference to
'mcbsp->fclk' must be decremented, as already done in the remove function.

This can be achieved easily by using the devm_ variant of 'clk_get()'
when the reference is taken in 'omap_mcbsp_init()'

This fixes the leak in the probe and has the side effect to simplify both
the error handling path of 'omap_mcbsp_init()' and the remove function.

Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
I've not been able to identify the when the issue has been introduced, so
no Fixes: tag.
---
 sound/soc/ti/omap-mcbsp.c | 8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/sound/soc/ti/omap-mcbsp.c b/sound/soc/ti/omap-mcbsp.c
index 0348963f4df7..6c83b9888467 100644
--- a/sound/soc/ti/omap-mcbsp.c
+++ b/sound/soc/ti/omap-mcbsp.c
@@ -686,7 +686,7 @@ static int omap_mcbsp_init(struct platform_device *pdev)
 	mcbsp->dma_data[1].addr = omap_mcbsp_dma_reg_params(mcbsp,
 						SNDRV_PCM_STREAM_CAPTURE);
 
-	mcbsp->fclk = clk_get(&pdev->dev, "fck");
+	mcbsp->fclk = devm_clk_get(&pdev->dev, "fck");
 	if (IS_ERR(mcbsp->fclk)) {
 		ret = PTR_ERR(mcbsp->fclk);
 		dev_err(mcbsp->dev, "unable to get fck: %d\n", ret);
@@ -711,7 +711,7 @@ static int omap_mcbsp_init(struct platform_device *pdev)
 		if (ret) {
 			dev_err(mcbsp->dev,
 				"Unable to create additional controls\n");
-			goto err_thres;
+			return ret;
 		}
 	}
 
@@ -724,8 +724,6 @@ static int omap_mcbsp_init(struct platform_device *pdev)
 err_st:
 	if (mcbsp->pdata->buffer_size)
 		sysfs_remove_group(&mcbsp->dev->kobj, &additional_attr_group);
-err_thres:
-	clk_put(mcbsp->fclk);
 	return ret;
 }
 
@@ -1442,8 +1440,6 @@ static int asoc_mcbsp_remove(struct platform_device *pdev)
 
 	omap_mcbsp_st_cleanup(pdev);
 
-	clk_put(mcbsp->fclk);
-
 	return 0;
 }
 
-- 
2.25.1

Re: [PATCH] ASoC: ti: omap-mcbsp: Fix an error handling path in 'asoc_mcbsp_probe()'

[Peter Ujfalusi]

[-- Attachment #1: Type: text/plain, Size: 2429 bytes --]



On 12/05/2020 16.43, Christophe JAILLET wrote:
> If an error occurs after the call to 'omap_mcbsp_init()', the reference to
> 'mcbsp->fclk' must be decremented, as already done in the remove function.
> 
> This can be achieved easily by using the devm_ variant of 'clk_get()'
> when the reference is taken in 'omap_mcbsp_init()'
> 
> This fixes the leak in the probe and has the side effect to simplify both
> the error handling path of 'omap_mcbsp_init()' and the remove function.

Acked-by: Peter Ujfalusi <peter.ujflausi@ti.com>

> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> ---
> I've not been able to identify the when the issue has been introduced, so
> no Fixes: tag.

I think this is there for a long-long time. It is a theoretical bug, in
practice it never happen (at least never faced with it over the years).

Thanks for the fix!

- Péter

> ---
>  sound/soc/ti/omap-mcbsp.c | 8 ++------
>  1 file changed, 2 insertions(+), 6 deletions(-)
> 
> diff --git a/sound/soc/ti/omap-mcbsp.c b/sound/soc/ti/omap-mcbsp.c
> index 0348963f4df7..6c83b9888467 100644
> --- a/sound/soc/ti/omap-mcbsp.c
> +++ b/sound/soc/ti/omap-mcbsp.c
> @@ -686,7 +686,7 @@ static int omap_mcbsp_init(struct platform_device *pdev)
>  	mcbsp->dma_data[1].addr = omap_mcbsp_dma_reg_params(mcbsp,
>  						SNDRV_PCM_STREAM_CAPTURE);
>  
> -	mcbsp->fclk = clk_get(&pdev->dev, "fck");
> +	mcbsp->fclk = devm_clk_get(&pdev->dev, "fck");
>  	if (IS_ERR(mcbsp->fclk)) {
>  		ret = PTR_ERR(mcbsp->fclk);
>  		dev_err(mcbsp->dev, "unable to get fck: %d\n", ret);
> @@ -711,7 +711,7 @@ static int omap_mcbsp_init(struct platform_device *pdev)
>  		if (ret) {
>  			dev_err(mcbsp->dev,
>  				"Unable to create additional controls\n");
> -			goto err_thres;
> +			return ret;
>  		}
>  	}
>  
> @@ -724,8 +724,6 @@ static int omap_mcbsp_init(struct platform_device *pdev)
>  err_st:
>  	if (mcbsp->pdata->buffer_size)
>  		sysfs_remove_group(&mcbsp->dev->kobj, &additional_attr_group);
> -err_thres:
> -	clk_put(mcbsp->fclk);
>  	return ret;
>  }
>  
> @@ -1442,8 +1440,6 @@ static int asoc_mcbsp_remove(struct platform_device *pdev)
>  
>  	omap_mcbsp_st_cleanup(pdev);
>  
> -	clk_put(mcbsp->fclk);
> -
>  	return 0;
>  }
>  
> 

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

[-- Attachment #2: pEpkey.asc --]
[-- Type: application/pgp-keys, Size: 1783 bytes --]

Re: [PATCH] ASoC: ti: omap-mcbsp: Fix an error handling path in 'asoc_mcbsp_probe()'

[Mark Brown]

On Tue, 12 May 2020 15:43:25 +0200, Christophe JAILLET wrote:
> If an error occurs after the call to 'omap_mcbsp_init()', the reference to
> 'mcbsp->fclk' must be decremented, as already done in the remove function.
> 
> This can be achieved easily by using the devm_ variant of 'clk_get()'
> when the reference is taken in 'omap_mcbsp_init()'
> 
> This fixes the leak in the probe and has the side effect to simplify both
> the error handling path of 'omap_mcbsp_init()' and the remove function.

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.8

Thanks!

[1/1] ASoC: ti: omap-mcbsp: Fix an error handling path in 'asoc_mcbsp_probe()'
      commit: 03990fd58d2b7c8f7d53e514ba9b8749fac260f9

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark