From: Mark Brown <broonie@kernel.org>
To: Cezary Rojewski <cezary.rojewski@intel.com>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>,
Takashi Iwai <tiwai@suse.com>
Subject: Re: [RFC] soc_pcm_open: error path behavior change since v5.6
Date: Thu, 3 Sep 2020 14:16:34 +0100 [thread overview]
Message-ID: <20200903131633.GA4771@sirena.org.uk> (raw)
In-Reply-To: <48810933-41cf-265c-1784-2e2acf979720@intel.com>
[-- Attachment #1: Type: text/plain, Size: 1255 bytes --]
On Thu, Sep 03, 2020 at 10:31:35AM +0200, Cezary Rojewski wrote:
> Some time ago negative-tests found out that behavior of soc_pcm_open has
> changed, quite sure this might be a regression hence my email. Till v5.6
> soc_pcm_open was invoking ::shutdown() for cpu_dai in error path only if
> ::startup() succeeded first (label: 'out'). After addition of commit:
Please don't invent new notation that nobody else uses, it just makes
your messages harder to read.
> Should dai's ::shutdown() be introducing some kind of state-check from now
> on? - similarly to how developers deal with some of the core pcm operations
> e.g.: ::prepare() (as it may get invoked multiple times in a row so check is
> there to prevent redundancy).
If there are stateful things it's probably better to do that from a
robustness point of view whatever is going on.
> Or, perhaps behavior change should be reverted with ::shutdown() routine
> again being called only after successful ::startup()?
IIRC part of the thinking there was that we were getting the keeping
track part of things wrong and sometimes missing things that should be
being shut down in error paths. Anything that tries to stop extra calls
would need to be very clearly robust and easily maintainable.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2020-09-03 13:18 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-03 8:31 [RFC] soc_pcm_open: error path behavior change since v5.6 Cezary Rojewski
2020-09-03 13:16 ` Mark Brown [this message]
2020-09-04 9:35 ` Cezary Rojewski
2020-09-06 23:11 ` Kuninori Morimoto
2020-09-04 0:01 ` Kuninori Morimoto
2020-09-04 9:25 ` 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=20200903131633.GA4771@sirena.org.uk \
--to=broonie@kernel.org \
--cc=alsa-devel@alsa-project.org \
--cc=cezary.rojewski@intel.com \
--cc=kuninori.morimoto.gx@renesas.com \
--cc=pierre-louis.bossart@linux.intel.com \
--cc=tiwai@suse.com \
/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