[alsa-devel] [PATCH 4/4] ASoC: soc-core: call snd_soc_remove_card() when component del

[Lars-Peter Clausen]

On 02/10/2015 01:44 AM, Kuninori Morimoto wrote:
>
> Hi Lars
>
>>>> ASoC devices are organized as CPU-CARD-CODEC. Then, CPU/CODEC
>>>> are based on component structure. Now, each CARD device knows
>>>> connected component. But CARD doesn't notice if connected component
>>>> was removed when user called rmmod or unbind in current implementation.
>>>> Thus, CARD which lost some components still exist in system.
>>>> And then, ALSA sound card will have some problem if user used this CARD
>>>> in such timing. This patch temporarily removes CARD from system
>>>> if connected component was removed, and re-add it if some component
>>>> was added.
>>>>
>>>> Reported-by: Nguyen Viet Dung <nv-dung at jinso.co.jp>
>>>> Reported-by: Bui Duc Phuc <bd-phuc at jinso.co.jp>
>>>> Reported-by: Cao Minh Hiep <cm-hiep at jinso.co.jp>
>>>> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
>>>> ---
> (snip)
>> The other issue is that it introduces subtly issues with the suspend and
>> resume order. Suspend and 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 patch 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.
>>
>> This patch essentially is a partial revert of commit b19e6e7b763 ("ASoC:
>> core: Use driver core probe deferral") where the card list was replaced with
>> the -EPROBE_DEFER mechanism.
>>
>> So while this patch fixes the nasty crash it introduces some other subtle
>> issue. Maybe we should also add a big WARN() when a component of a card is
>> removed while still in use until the other issues are also fixed.
>
> OK. I can send such patch.
> Oops ? does this mean my patch-set + WARN() ? or just WARN() ?

Both. Or an alternative would be not to allow re-binding the card and force 
the user to unbind/bind the card before it starts working again.

- Lars