[alsa-devel] [PATCH] soc-core: let suspend/resume not called if the card is not instantiated

Barry Song 21cnbao at gmail.com
Sat Nov 14 01:46:05 CET 2009

On Sat, Nov 14, 2009 at 1:04 AM, Mark Brown
<broonie at opensource.wolfsonmicro.com> wrote:
> On Fri, Nov 13, 2009 at 11:29:39PM +0800, Barry Song wrote:
>> The logic seems different: in snd_soc_instantiate_card(), only while
>> all cpu DAIs and codec DAIs are found and registered in the system
>> except ac97, their probes will be called. Then card->instantiated
>> becomes 1.
>> A case current codes will cause crash is:
>> For a CPU DAI driver based on platform driver, if arch hasn't defined
>> the platform device for cpu dai, then cpu dai is not registered and
>> initialized in the probe() of its platform driver. Even though its
>> instance is in card->dai_link, it doesn't really enter the system. But
>> while suspend/resume, its entries will be called too since the call
>> doesn't check the existence:
> Yes, that can go wrong - but as I say the converse thing can also go
> wrong where some but not all of the card has managed to register and the
> bits that have managed to register expect to be suspended by the core.
>> I think suspend/resume of a DAI can only be called while it really
>> exists and can be found in the dai_list, at least.
> Checking to see if the device is in the DAI relevant list would work
> but...
>> So I add a overall condition for soc_suspend/resume just like
>>       if (!card->instantiated)
>>               return 0
>> has be done in soc_remove(),  soc_poweroff().
> ...this is too broad.
Then do you think it is workable to find the dai in dai_list before
calling its suspend/resume? My original plan was checking the
existence of DAI in dai_list, if DAI doesn't exist, don't call its PM
entries.  Then I found card->instantiated, I moved to check it.
If you have better plan for fixing this problem, I can wait and keep
this fix locally.


More information about the Alsa-devel mailing list