[PATCH] ASoC: codecs: Fix rumtime PM imbalance in tas2552_probe

[PATCH] ASoC: codecs: Fix rumtime PM imbalance in tas2552_probe

[Dinghao Liu]

There is a rumtime PM imbalance between the error handling path
after devm_snd_soc_register_component() and all other error
handling paths. Fix this by moving PM runtime decrement to the
end of the function.

Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
---
 sound/soc/codecs/tas2552.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/sound/soc/codecs/tas2552.c b/sound/soc/codecs/tas2552.c
index bd00c35116cd..52de6f7b4227 100644
--- a/sound/soc/codecs/tas2552.c
+++ b/sound/soc/codecs/tas2552.c
@@ -718,13 +718,6 @@ static int tas2552_probe(struct i2c_client *client,
 		return ret;
 	}
 
-	pm_runtime_set_active(&client->dev);
-	pm_runtime_set_autosuspend_delay(&client->dev, 1000);
-	pm_runtime_use_autosuspend(&client->dev);
-	pm_runtime_enable(&client->dev);
-	pm_runtime_mark_last_busy(&client->dev);
-	pm_runtime_put_sync_autosuspend(&client->dev);
-
 	dev_set_drvdata(&client->dev, data);
 
 	ret = devm_snd_soc_register_component(&client->dev,
@@ -733,6 +726,13 @@ static int tas2552_probe(struct i2c_client *client,
 	if (ret < 0)
 		dev_err(&client->dev, "Failed to register component: %d\n", ret);
 
+	pm_runtime_set_active(&client->dev);
+	pm_runtime_set_autosuspend_delay(&client->dev, 1000);
+	pm_runtime_use_autosuspend(&client->dev);
+	pm_runtime_enable(&client->dev);
+	pm_runtime_mark_last_busy(&client->dev);
+	pm_runtime_put_sync_autosuspend(&client->dev);
+
 	return ret;
 }
 
-- 
2.17.1

Re: [PATCH] ASoC: codecs: Fix rumtime PM imbalance in tas2552_probe

[Mark Brown]

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

On Wed, Apr 07, 2021 at 02:54:00PM +0800, Dinghao Liu wrote:

> -	pm_runtime_set_active(&client->dev);
> -	pm_runtime_set_autosuspend_delay(&client->dev, 1000);
> -	pm_runtime_use_autosuspend(&client->dev);
> -	pm_runtime_enable(&client->dev);
> -	pm_runtime_mark_last_busy(&client->dev);
> -	pm_runtime_put_sync_autosuspend(&client->dev);
> -
>  	dev_set_drvdata(&client->dev, data);
>  
>  	ret = devm_snd_soc_register_component(&client->dev,
> @@ -733,6 +726,13 @@ static int tas2552_probe(struct i2c_client *client,
>  	if (ret < 0)
>  		dev_err(&client->dev, "Failed to register component: %d\n", ret);
>  
> +	pm_runtime_set_active(&client->dev);
> +	pm_runtime_set_autosuspend_delay(&client->dev, 1000);
> +	pm_runtime_use_autosuspend(&client->dev);

It's not clear to me that just moving the operations after the
registration is a good fix - once the component is registered we could
start trying to do runtime PM operations with it which AFAIR won't count
references and so on properly if runtime PM isn't enabled so if we later
enable runtime PM we might have the rest of the code in a confused state
about what's going on.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Re: [PATCH] ASoC: codecs: Fix rumtime PM imbalance in tas2552_probe

[dinghao.liu]

> On Wed, Apr 07, 2021 at 02:54:00PM +0800, Dinghao Liu wrote:
> 
> > -	pm_runtime_set_active(&client->dev);
> > -	pm_runtime_set_autosuspend_delay(&client->dev, 1000);
> > -	pm_runtime_use_autosuspend(&client->dev);
> > -	pm_runtime_enable(&client->dev);
> > -	pm_runtime_mark_last_busy(&client->dev);
> > -	pm_runtime_put_sync_autosuspend(&client->dev);
> > -
> >  	dev_set_drvdata(&client->dev, data);
> >  
> >  	ret = devm_snd_soc_register_component(&client->dev,
> > @@ -733,6 +726,13 @@ static int tas2552_probe(struct i2c_client *client,
> >  	if (ret < 0)
> >  		dev_err(&client->dev, "Failed to register component: %d\n", ret);
> >  
> > +	pm_runtime_set_active(&client->dev);
> > +	pm_runtime_set_autosuspend_delay(&client->dev, 1000);
> > +	pm_runtime_use_autosuspend(&client->dev);
> 
> It's not clear to me that just moving the operations after the
> registration is a good fix - once the component is registered we could
> start trying to do runtime PM operations with it which AFAIR won't count
> references and so on properly if runtime PM isn't enabled so if we later
> enable runtime PM we might have the rest of the code in a confused state
> about what's going on.

Thanks for your advice. I checked the use of devm_snd_soc_register_component() 
in the kernel and found sometimes runtime PM is enabled before registration 
and sometimes after registration. To be on the safe side, I will send a new
patch to fix this in error handling path.

Regards,
Dinghao