From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lars-Peter Clausen Subject: Re: [PATCH 4/4] ASoC: soc-core: call snd_soc_remove_card() when component del Date: Tue, 10 Feb 2015 13:28:18 +0100 Message-ID: <54D9F962.60405@metafoo.de> References: <87siefv54e.wl%kuninori.morimoto.gx@renesas.com> <87mw4nv524.wl%kuninori.morimoto.gx@renesas.com> <54D8994A.5090906@metafoo.de> <87r3tya921.wl%kuninori.morimoto.gx@renesas.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from smtp-out-115.synserver.de (smtp-out-115.synserver.de [212.40.185.115]) by alsa0.perex.cz (Postfix) with ESMTP id E47AD261481 for ; Tue, 10 Feb 2015 13:28:20 +0100 (CET) In-Reply-To: <87r3tya921.wl%kuninori.morimoto.gx@renesas.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: alsa-devel-bounces@alsa-project.org To: Kuninori Morimoto Cc: Takashi Iwai , Linux-ALSA , Mark Brown , Liam Girdwood , Simon List-Id: alsa-devel@alsa-project.org 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 >>>> Reported-by: Bui Duc Phuc >>>> Reported-by: Cao Minh Hiep >>>> Signed-off-by: Kuninori Morimoto >>>> --- > (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