[5/5,v4] ASoC: soc-core: indicate warning for unbind/bind issue

Commit Message

Kuninori Morimoto Feb. 13, 2015, 4:44 a.m. UTC

From: Kuninori Morimoto <[e-mail]>

We have unbinded_card_list for unbind / bind issue of component.
But suspend / resume are called in the order in which the probe functions
of devices are called (and succeed). By returning -EPROBE_DEFER in the
card driver we make sure that the card's probe function is always called
after the probe functions of all the components of the card have run.
This again causes the card's suspend function to be called before any
suspend function of any of it's components. Now with this unbind / bind
fixup it is possible again for a component's probe function to be called
after the card's probe function which changes the suspend and resume
order and might break things.
Ideally the correct fix would somehow make sure that the card itself is
unbound and put back onto the probe_defer list in the future.
We indicate warning to this issue for now.

Reported-by: Lars-Peter Clausen <[e-mail]>
Signed-off-by: Kuninori Morimoto <[e-mail]>
---
v3 -> v4

 - new patch

 sound/soc/soc-core.c |    5 +++++
 1 file changed, 5 insertions(+)

Comments

Mark Brown March 22, 2015, 6:50 p.m. UTC | #1

On Fri, Feb 13, 2015 at 04:44:05AM +0000, Kuninori Morimoto wrote:

> Ideally the correct fix would somehow make sure that the card itself is
> unbound and put back onto the probe_defer list in the future.
> We indicate warning to this issue for now.

I don't think we should be trying to do this at the ASoC level at all,
we should do it at the driver core level.  A similar issue applies to
other inter device dependencies - if someone manages to remove a GPIO
controller, a clock or a regulator for example.  The components of a
card are really no different here.  Like I said in my mail just now
let's have a look at how this is supposed to work at the driver core
level and ask Greg if there's nothing clear.

Kuninori Morimoto March 23, 2015, 9:12 a.m. UTC | #2

Hi Mark

> > Ideally the correct fix would somehow make sure that the card itself is
> > unbound and put back onto the probe_defer list in the future.
> > We indicate warning to this issue for now.
> 
> I don't think we should be trying to do this at the ASoC level at all,
> we should do it at the driver core level.  A similar issue applies to
> other inter device dependencies - if someone manages to remove a GPIO
> controller, a clock or a regulator for example.  The components of a
> card are really no different here.  Like I said in my mail just now
> let's have a look at how this is supposed to work at the driver core
> level and ask Greg if there's nothing clear.

Thank you.
Yes, we need more generic approach for this.

Patch

diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index f04e97d..c286a76 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -2719,6 +2719,11 @@  static void snd_soc_component_del_unlocked(struct snd_soc_component *component)
 
 	/* card is removed temporarily */
 	if (component->probed && card->instantiated) {
+		dev_warn(component->dev,
+			 "%s is unbinded. but we recommend you to "
+			 "unbind/bind or rmmod/insmod it by yourself\n",
+			 card->name);
+
 		list_add(&card->unbinded_list, &unbinded_card_list);
 		snd_soc_remove_card(card);
 	}