linux-kernel - Re: Re: [PATCH] ASoC: codecs: Fix rumtime PM imbalance in tas2552

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <8ef359a.40bbb.178b0024d3e.Coremail.dinghao.liu@zju.edu.cn>
Date:   Thu, 8 Apr 2021 13:44:04 +0800 (GMT+08:00)
From:   dinghao.liu@....edu.cn
To:     "Mark Brown" <broonie@...nel.org>
Cc:     kjlu@....edu, "Liam Girdwood" <lgirdwood@...il.com>,
        "Jaroslav Kysela" <perex@...ex.cz>,
        "Takashi Iwai" <tiwai@...e.com>,
        "Kuninori Morimoto" <kuninori.morimoto.gx@...esas.com>,
        "Peter Ujfalusi" <peter.ujfalusi@...com>,
        "Rob Herring" <robh@...nel.org>,
        "Alexander A. Klimov" <grandmaster@...klimov.de>,
        "Gustavo A. R. Silva" <gustavoars@...nel.org>,
        alsa-devel@...a-project.org, linux-kernel@...r.kernel.org
Subject: Re: Re: [PATCH] ASoC: codecs: Fix rumtime PM imbalance in
 tas2552_probe

> 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