All of lore.kernel.org
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Cezary Rojewski <cezary.rojewski@intel.com>
Cc: alsa-devel@alsa-project.org, Mark Brown <broonie@kernel.org>,
	Yu-Hsuan Hsu <yuhsuan@chromium.org>
Subject: Re: [PATCH] ASoC: DAPM: Cover regression by kctl change notification fix
Date: Fri, 05 Nov 2021 12:36:35 +0100	[thread overview]
Message-ID: <s5hr1bug7gc.wl-tiwai@suse.de> (raw)
In-Reply-To: <bd3fbedf-6210-530e-2eb9-106a498bb23b@intel.com>

On Fri, 05 Nov 2021 12:30:48 +0100,
Cezary Rojewski wrote:
> 
> On 2021-11-05 10:09 AM, Takashi Iwai wrote:
> > The recent fix for DAPM to correct the kctl change notification by the
> > commit 5af82c81b2c4 ("ASoC: DAPM: Fix missing kctl change
> > notifications") caused other regressions since it changed the behavior
> > of snd_soc_dapm_set_pin() that is called from several API functions.
> > Formerly it returned always 0 for success, but now it returns 0 or 1.
> >
> > This patch addresses it, restoring the old behavior of
> > snd_soc_dapm_set_pin() while keeping the fix in
> > snd_soc_dapm_put_pin_switch().
> >
> > Fixes: 5af82c81b2c4 ("ASoC: DAPM: Fix missing kctl change notifications")
> > Reported-by: Yu-Hsuan Hsu <yuhsuan@chromium.org>
> > Cc: <stable@vger.kernel.org>
> > Signed-off-by: Takashi Iwai <tiwai@suse.de>
> 
> Hello,
> 
> From my research I've found very few places which actually check the
> returned value of functions mentioned by you. And thus we could use
> this opportunity to adjust the kcontrol-put behavior according to
> documentation for all users without adding any additional functions
> which are part of this patch.
> 
> Board:
> sound/soc/intel/boards/kbl_da7219_max98927.c
> 
> seems to be the offending user. We could update its code instead,
> leaving ASoC unchanged. What do you think?

Well, if we're going to that direction, we have to update the
documentation and properly mention about the positive return value.
So the changes in ASoC core would be needed nevertheless.

I find it good to keep the old existing behavior; those API functions
are only for enabling/disabling, so returning 0 or a negative error is
more natural than tri-state, less complex for callers.


thanks,

Takashi

  reply	other threads:[~2021-11-05 11:37 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-05  9:09 [PATCH] ASoC: DAPM: Cover regression by kctl change notification fix Takashi Iwai
2021-11-05 11:30 ` Cezary Rojewski
2021-11-05 11:36   ` Takashi Iwai [this message]
2021-11-05 12:03     ` Cezary Rojewski
2021-11-05 15:22 ` 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=s5hr1bug7gc.wl-tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=cezary.rojewski@intel.com \
    --cc=yuhsuan@chromium.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.