> 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
