diff mbox series

[09/21] ASoC: soc-core: remove unneeded snd_soc_tplg_component_remove()

Message ID 87ftk2ilqz.wl-kuninori.morimoto.gx@renesas.com (mailing list archive)
State New, archived
Headers show
Series ASoC: soc-core cleanup - step 4 | expand

Commit Message

Kuninori Morimoto Oct. 9, 2019, 4:30 a.m. UTC
From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

snd_soc_tplg_component_remove() is topology related cleanup function.
The driver which added topology needed cleanup it, not by soc-core.
Only topology user skl-pcm is calling it, there is no effect by
this patch.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
 sound/soc/soc-core.c | 2 --
 1 file changed, 2 deletions(-)

Comments

Pierre-Louis Bossart Oct. 10, 2019, 3:09 p.m. UTC | #1
On 10/8/19 11:30 PM, Kuninori Morimoto wrote:
> From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> 
> snd_soc_tplg_component_remove() is topology related cleanup function.
> The driver which added topology needed cleanup it, not by soc-core.
> Only topology user skl-pcm is calling it, there is no effect by
> this patch.

the SOF driver also calls snd_soc_tplg_component_remove(), so not sure 
what you meant by the comment?

> 
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> ---
>   sound/soc/soc-core.c | 2 --
>   1 file changed, 2 deletions(-)
> 
> diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
> index 283ac63..fa837c0 100644
> --- a/sound/soc/soc-core.c
> +++ b/sound/soc/soc-core.c
> @@ -2870,8 +2870,6 @@ static int __snd_soc_unregister_component(struct device *dev)
>   		if (dev != component->dev)
>   			continue;
>   
> -		snd_soc_tplg_component_remove(component,
> -					      SND_SOC_TPLG_INDEX_ALL);
>   		snd_soc_component_del_unlocked(component);
>   		found = 1;
>   		break;
>
Kuninori Morimoto Oct. 11, 2019, 1:30 a.m. UTC | #2
Hi Pierre-Louis

> > snd_soc_tplg_component_remove() is topology related cleanup function.
> > The driver which added topology needed cleanup it, not by soc-core.
> > Only topology user skl-pcm is calling it, there is no effect by
> > this patch.
(snip)
> > --- a/sound/soc/soc-core.c
> > +++ b/sound/soc/soc-core.c
> > @@ -2870,8 +2870,6 @@ static int __snd_soc_unregister_component(struct device *dev)
> >   		if (dev != component->dev)
> >   			continue;
> >   -		snd_soc_tplg_component_remove(component,
> > -					      SND_SOC_TPLG_INDEX_ALL);
> >   		snd_soc_component_del_unlocked(component);
(snip)
> the SOF driver also calls snd_soc_tplg_component_remove(), so not sure
> what you meant by the comment?

Ahh, yes indeed.

My opinion is that driver who called _load() need to call _remove()
under his responsibility.

Today, skl-pcm and topology are the user.
They are calling both _load() and_remove().
Thus, I think soc-core don't need to call it ?

If we want to keep it as robustness,
I want to have this comment, otherwise very confusable,
because soc-core never call _load() but calling _remove()

	/* For framework level robustness */
	snd_soc_tplg_component_remove(...);

Thank you for your help !!
Best regards
---
Kuninori Morimoto
Pierre-Louis Bossart Oct. 11, 2019, 1:40 p.m. UTC | #3
>>> snd_soc_tplg_component_remove() is topology related cleanup function.
>>> The driver which added topology needed cleanup it, not by soc-core.
>>> Only topology user skl-pcm is calling it, there is no effect by
>>> this patch.
> (snip)
>>> --- a/sound/soc/soc-core.c
>>> +++ b/sound/soc/soc-core.c
>>> @@ -2870,8 +2870,6 @@ static int __snd_soc_unregister_component(struct device *dev)
>>>    		if (dev != component->dev)
>>>    			continue;
>>>    -		snd_soc_tplg_component_remove(component,
>>> -					      SND_SOC_TPLG_INDEX_ALL);
>>>    		snd_soc_component_del_unlocked(component);
> (snip)
>> the SOF driver also calls snd_soc_tplg_component_remove(), so not sure
>> what you meant by the comment?
> 
> Ahh, yes indeed.
> 
> My opinion is that driver who called _load() need to call _remove()
> under his responsibility.
> 
> Today, skl-pcm and topology are the user.
> They are calling both _load() and_remove().
> Thus, I think soc-core don't need to call it ?
> 
> If we want to keep it as robustness,
> I want to have this comment, otherwise very confusable,
> because soc-core never call _load() but calling _remove()
> 
> 	/* For framework level robustness */
> 	snd_soc_tplg_component_remove(...);

I would need Ranjani's help here. I vaguely remember that at some point 
we relied on the topology being removed by the framework, then we did it 
on our own but can't recall the reason.

Ranjani, if you've got power now, can you chime in?
diff mbox series

Patch

diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index 283ac63..fa837c0 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -2870,8 +2870,6 @@  static int __snd_soc_unregister_component(struct device *dev)
 		if (dev != component->dev)
 			continue;
 
-		snd_soc_tplg_component_remove(component,
-					      SND_SOC_TPLG_INDEX_ALL);
 		snd_soc_component_del_unlocked(component);
 		found = 1;
 		break;