All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Barry Song <21cnbao@gmail.com>
Cc: uclinux-dist-devel@blackfin.uclinux.org, alsa-devel@alsa-project.org
Subject: Re: [PATCH] soc-core: let suspend/resume not called if the card is not instantiated
Date: Fri, 13 Nov 2009 17:04:59 +0000	[thread overview]
Message-ID: <20091113170459.GB23607@rakim.wolfsonmicro.main> (raw)
In-Reply-To: <3c17e3570911130729xab6a443t5b257c2699dfa169@mail.gmail.com>

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.

  reply	other threads:[~2009-11-13 17:05 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-13  4:51 [PATCH] soc-core: let suspend/resume not called if the card is not instantiated Barry Song
2009-11-13 13:38 ` Mark Brown
2009-11-13 14:56   ` Barry Song
2009-11-13 15:02     ` Mark Brown
2009-11-13 15:29       ` Barry Song
2009-11-13 17:04         ` Mark Brown [this message]
2009-11-14  0:46           ` Barry Song
2009-11-16 17:04             ` Mark Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20091113170459.GB23607@rakim.wolfsonmicro.main \
    --to=broonie@opensource.wolfsonmicro.com \
    --cc=21cnbao@gmail.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=uclinux-dist-devel@blackfin.uclinux.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.