Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Cc: alsa-devel@alsa-project.org, Mark Brown <broonie@kernel.org>,
	Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Subject: Re: [PATCH v2 1/2] ALSA: add snd_card_disconnect_sync()
Date: Wed, 11 Oct 2017 14:19:52 +0200	[thread overview]
Message-ID: <s5hzi8x98rb.wl-tiwai@suse.de> (raw)
In-Reply-To: <4f400024-56df-884c-efc4-8104e86b0b99@sakamocchi.jp>

On Wed, 11 Oct 2017 13:22:12 +0200,
Takashi Sakamoto wrote:
> 
> Hi,
> 
> On Oct 11 2017 19:16, Takashi Iwai wrote:
> > In case of user unbind ALSA driver during playing back / capturing,
> > each driver needs to stop and remove it correctly. One note here is
> > that we can't cancel from remove function in such case, because
> > unbind operation doesn't check return value from remove function.
> > So, we *must* stop and remove in this case.
> >
> > For this purpose, we need to sync (= wait) until the all top-level
> > operations are canceled at remove function.
> > For example, snd_card_free() processes the disconnection procedure at
> > first, then waits for the completion. That's how the hot-unplug works
> > safely. It's implemented, at least, in the top-level driver removal.
> >
> > Now for the lower level driver, we need a similar strategy. Notify to
> > the toplevel for hot-unplug (disconnect in ALSA), and sync with the
> > stop operation, then continue the rest of its own remove procedure.
> >
> > This patch adds snd_card_disconnect_sync(), and driver can use it from
> > remove function.
> >
> > Tested-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> > Signed-off-by: Takashi Iwai <tiwai@suse.de>
> > ---
> >   include/sound/core.h |  2 ++
> >   sound/core/init.c    | 32 ++++++++++++++++++++++++++++++++
> >   2 files changed, 34 insertions(+)
> 
> I have a question for this patch. If this patch is applied and the
> lower-level driver call this function in its .remove callback, after
> all references to an instance of snd_card by file instances
> corresponding to each of ALSA character devices are released, the
> lower-level driver must explicitly releases the last reference to the
> instance of snd_card.

Not really.  This is only about files user-space opened.  It has
nothing to do with the refcount of objects / resources.  The refcount
sync is done by card->release_completion instead, which is sync'ed in
snd_card_free().

> On ALSA SoC part, which context perform this
> important task?

The "lower-level" might be confusing here; in the context, it's rather
meant as middle layer (component) that can be unbound freely.
Thus, for non-ASoC codes, this hasn't been a big problem, so far,
since the helper modules can't be unbound.
(Maybe the legacy AC97 codec driver needs something, and HD-audio has
 already some not-so-perfect workaround.)

> In my opinion, this patch easily allows leak of
> kobject. Do you have any safety?

There isn't anything different from the current state wrt kobjects.
The only merit of calling this in the remove callback is that it can
assure that the all actions are stopped, by disconnecting the devices.
It doesn't free resources by itself.

> At least, it's better for us to add enough comments to inform it to
> developers.

Well, I thought it well informed about the disconnection procedure.
Maybe the term "lower level driver" needs to be more explicit.


thanks,

Takashi

  reply	other threads:[~2017-10-11 12:19 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-11 10:16 [PATCH v2 0/2] Add snd_card_disconnect_sync() helper Takashi Iwai
2017-10-11 10:16 ` [PATCH v2 1/2] ALSA: add snd_card_disconnect_sync() Takashi Iwai
2017-10-11 11:22   ` Takashi Sakamoto
2017-10-11 12:19     ` Takashi Iwai [this message]
2017-10-11 13:13       ` Takashi Iwai
2017-10-11 10:16 ` [PATCH v2 2/2] ALSA: pcm: Forcibly stop at disconnect callback Takashi Iwai
2017-10-13  7:39 ` [PATCH v2 0/2] Add snd_card_disconnect_sync() helper Kuninori Morimoto
2017-10-13  7:44   ` Takashi Iwai
2017-10-13  9:11     ` Kuninori Morimoto
2017-10-13  9:43       ` Takashi Iwai
2017-10-13 17:11         ` Mark Brown
2017-10-16  2:26         ` Kuninori Morimoto
2017-10-16 15:37           ` Takashi Iwai
2017-10-17  0:59             ` Kuninori Morimoto
2017-10-17 10:37               ` Takashi Iwai
2017-10-17 20:05                 ` Mark Brown
2017-10-18  2:08                   ` Kuninori Morimoto
2017-10-18  6:10                     ` Takashi Iwai
2017-10-18  7:13                       ` Kuninori Morimoto
2017-10-17 14:25               ` Takashi Sakamoto
2017-10-17 14:34                 ` Takashi Iwai
2017-10-17 15:16                   ` Takashi Sakamoto
2017-10-17 16:09                     ` Takashi Iwai

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=s5hzi8x98rb.wl-tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=kuninori.morimoto.gx@renesas.com \
    --cc=o-takashi@sakamocchi.jp \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox