All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Tan Nayır" <tannayir@gmail.com>
To: Mark Brown <broonie@kernel.org>
Cc: alsa-devel@alsa-project.org, stable@vger.kernel.org,
	Marek Vasut <marex@denx.de>
Subject: Re: [PATCH] ASoC: ops: Fix the bounds checking in snd_soc_put_volsw_sx and snd_soc_put_xr_sx
Date: Tue, 17 May 2022 17:25:48 +0300	[thread overview]
Message-ID: <2f331adf-6f95-06c1-a366-ea81b5bf6ec2@gmail.com> (raw)
In-Reply-To: <YoOdauC5Q8POpHLe@sirena.org.uk>

 > No, the minimum value we expose to userspace is always scaled so that
 > userspace sees a range starting from zero and that's where platform_max
 > is referenced to - we're applying this limit before we start remapping
 > to actual register values. The code would be a lot simpler if we didn't
 > do this rescaling.

These are the results that I got from debugging my phone
which has a wcd9340 audio codec and a kernel version of 4.9.314:
The control is defined like
-- SOC_SINGLE_S8_TLV("IIR0 INP0 Volume", 
WCD934X_CDC_SIDETONE_IIR0_IIR_GAIN_B1_CTL, -84, 40, digital_gain) --

Now the OEM mixer_path.xml file defines the value of the aforementioned 
control as 54
which is read by the user-mode Qualcomm HAL, the HAL then uses the 
library libalsa-intf
to issue an IOCTL to pass this value directly to the ALSA driver.
At this point, the snd_soc_put_volsw_sx is called and the $val is 54 as 
expected.
$mc->platform_max is 40, $mc->max is also 40 and $mc->min is -84.

The problem is that the snd_soc_put_volsw_sx, checks the userspace value 
that has a range
starting from 0, directly against the $mc->platform_max value mentioned 
above
which is set to 40 at that point so it checks for the incorrect range.

WARNING: multiple messages have this Message-ID (diff)
From: "Tan Nayır" <tannayir@gmail.com>
To: Mark Brown <broonie@kernel.org>
Cc: Marek Vasut <marex@denx.de>,
	alsa-devel@alsa-project.org, stable@vger.kernel.org
Subject: Re: [PATCH] ASoC: ops: Fix the bounds checking in snd_soc_put_volsw_sx and snd_soc_put_xr_sx
Date: Tue, 17 May 2022 17:25:48 +0300	[thread overview]
Message-ID: <2f331adf-6f95-06c1-a366-ea81b5bf6ec2@gmail.com> (raw)
In-Reply-To: <YoOdauC5Q8POpHLe@sirena.org.uk>

 > No, the minimum value we expose to userspace is always scaled so that
 > userspace sees a range starting from zero and that's where platform_max
 > is referenced to - we're applying this limit before we start remapping
 > to actual register values. The code would be a lot simpler if we didn't
 > do this rescaling.

These are the results that I got from debugging my phone
which has a wcd9340 audio codec and a kernel version of 4.9.314:
The control is defined like
-- SOC_SINGLE_S8_TLV("IIR0 INP0 Volume", 
WCD934X_CDC_SIDETONE_IIR0_IIR_GAIN_B1_CTL, -84, 40, digital_gain) --

Now the OEM mixer_path.xml file defines the value of the aforementioned 
control as 54
which is read by the user-mode Qualcomm HAL, the HAL then uses the 
library libalsa-intf
to issue an IOCTL to pass this value directly to the ALSA driver.
At this point, the snd_soc_put_volsw_sx is called and the $val is 54 as 
expected.
$mc->platform_max is 40, $mc->max is also 40 and $mc->min is -84.

The problem is that the snd_soc_put_volsw_sx, checks the userspace value 
that has a range
starting from 0, directly against the $mc->platform_max value mentioned 
above
which is set to 40 at that point so it checks for the incorrect range.

  reply	other threads:[~2022-05-17 14:26 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-15 13:06 [PATCH] ASoC: ops: Shift tested values in snd_soc_put_volsw() by +min Marek Vasut
2022-02-16 18:01 ` Mark Brown
2022-02-23 14:55 ` Takashi Iwai
2022-02-23 16:32   ` Mark Brown
2022-02-23 16:44     ` Takashi Iwai
2022-02-23 16:52     ` Marek Vasut
2022-02-23 16:52       ` Marek Vasut
2022-05-16 23:53       ` Tan N.
2022-05-16 23:53         ` Tan N.
2022-05-17  1:12         ` [PATCH] ASoC: ops: Fix the bounds checking in snd_soc_put_volsw_sx and snd_soc_put_xr_sx Tan Nayir
2022-05-17  1:12           ` Tan Nayir
2022-05-17 13:04           ` Mark Brown
2022-05-17 13:04             ` Mark Brown
2022-05-17 14:25             ` Tan Nayır [this message]
2022-05-17 14:25               ` Tan Nayır
2022-05-17 18:20               ` Mark Brown
2022-05-17 18:20                 ` Mark Brown
2022-05-17 19:58                 ` Tan Nayır
2022-05-17 19:58                   ` Tan Nayır
2022-05-18 12:07                   ` Mark Brown
2022-05-18 12:07                     ` Mark Brown
2022-05-18 23:56                     ` Tan Nayır
2022-05-18 23:56                       ` Tan Nayır
2022-05-19 15:47                       ` Mark Brown
2022-05-19 15:47                         ` 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=2f331adf-6f95-06c1-a366-ea81b5bf6ec2@gmail.com \
    --to=tannayir@gmail.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=marex@denx.de \
    --cc=stable@vger.kernel.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.