linux-stable.git/include/sound, branch v5.17.2

ALSA: intel-nhlt: add helper to detect SSP link mask

2022-04-08T11:58:46+00:00

[ Upstream commit 0c470db0399e17310ed2ba54dd1c25cfa16ce0d3 ]

The NHLT information can be used to figure out which SSPs are enabled
in a platform.

The 'SSP' link type is too broad for machine drivers, since it can
cover the Bluetooth sideband and the analog audio codec connections,
so this helper exposes a parameter to filter with the device
type (DEVICE_I2S refers to analog audio codec in NHLT parlance).

The helper returns a mask, since more than one SSP may be used for
analog audio, e.g. the NHLT spec describes the use of SSP0 for
amplifiers and SSP1 for headset codec. Note that if more than one bit
is set, it's impossible to determine which SSP is connected to what
external component. Additional platform-specific information based on
e.g. DMI quirks would still be required in the machine driver to
configure the relevant dailinks.

Signed-off-by: Pierre-Louis Bossart 
Reviewed-by: Bard Liao 
Reviewed-by: Péter Ujfalusi 
Acked-by: Takashi Iwai 
Link: https://lore.kernel.org/r/20220308192610.392950-5-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin

ALSA: pcm: Fix potential AB/BA lock with buffer_mutex and mmap_lock

2022-04-08T11:57:21+00:00

commit bc55cfd5718c7c23e5524582e9fa70b4d10f2433 upstream.

syzbot caught a potential deadlock between the PCM
runtime->buffer_mutex and the mm->mmap_lock.  It was brought by the
recent fix to cover the racy read/write and other ioctls, and in that
commit, I overlooked a (hopefully only) corner case that may take the
revert lock, namely, the OSS mmap.  The OSS mmap operation
exceptionally allows to re-configure the parameters inside the OSS
mmap syscall, where mm->mmap_mutex is already held.  Meanwhile, the
copy_from/to_user calls at read/write operations also take the
mm->mmap_lock internally, hence it may lead to a AB/BA deadlock.

A similar problem was already seen in the past and we fixed it with a
refcount (in commit b248371628aa).  The former fix covered only the
call paths with OSS read/write and OSS ioctls, while we need to cover
the concurrent access via both ALSA and OSS APIs now.

This patch addresses the problem above by replacing the buffer_mutex
lock in the read/write operations with a refcount similar as we've
used for OSS.  The new field, runtime->buffer_accessing, keeps the
number of concurrent read/write operations.  Unlike the former
buffer_mutex protection, this protects only around the
copy_from/to_user() calls; the other codes are basically protected by
the PCM stream lock.  The refcount can be a negative, meaning blocked
by the ioctls.  If a negative value is seen, the read/write aborts
with -EBUSY.  In the ioctl side, OTOH, they check this refcount, too,
and set to a negative value for blocking unless it's already being
accessed.

Reported-by: syzbot+6e5c88838328e99c7e1c@syzkaller.appspotmail.com
Fixes: dca947d4d26d ("ALSA: pcm: Fix races among concurrent read/write and buffer changes")
Cc: 
Link: https://lore.kernel.org/r/000000000000381a0d05db622a81@google.com
Link: https://lore.kernel.org/r/20220330120903.4738-1-tiwai@suse.de
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman

ALSA: pcm: Fix races among concurrent hw_params and hw_free calls

2022-03-28T08:03:19+00:00

commit 92ee3c60ec9fe64404dc035e7c41277d74aa26cb upstream.

Currently we have neither proper check nor protection against the
concurrent calls of PCM hw_params and hw_free ioctls, which may result
in a UAF.  Since the existing PCM stream lock can't be used for
protecting the whole ioctl operations, we need a new mutex to protect
those racy calls.

This patch introduced a new mutex, runtime->buffer_mutex, and applies
it to both hw_params and hw_free ioctl code paths.  Along with it, the
both functions are slightly modified (the mmap_count check is moved
into the state-check block) for code simplicity.

Reported-by: Hu Jiahui 
Cc: 
Reviewed-by: Jaroslav Kysela 
Link: https://lore.kernel.org/r/20220322170720.3529-2-tiwai@suse.de
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman

Merge tag 'asoc-fix-v5.17-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus

2022-02-01T15:52:54+00:00

ASoC: Fixes for v5.17

Quite a few fixes here, including an unusually large set in the core
spurred on by various testing efforts as well as the usual small driver
fixes.  There are quite a few fixes for out of bounds writes in both the
core and the various Qualcomm drivers, plus a couple of fixes for
locking in the DPCM code.

ASoC: soc-pcm: Fix DPCM lockdep warning due to nested stream locks

2022-01-28T15:59:16+00:00

The recent change for DPCM locking caused spurious lockdep warnings.
Actually the warnings are false-positive, as those are triggered due
to the nested stream locks for FE and BE.  Since both locks belong to
the same lock class, lockdep sees it as if a deadlock.

For fixing this, we need to take PCM stream locks for BE with the
nested lock primitives.  Since currently snd_pcm_stream_lock*() helper
assumes only the top-level single locking, a new helper function
snd_pcm_stream_lock_irqsave_nested() is defined for a single-depth
nested lock, which is now used in the BE DAI trigger that is always
performed inside a FE stream lock.

Fixes: b2ae80663008 ("ASoC: soc-pcm: serialize BE triggers")
Reported-and-tested-by: Hans de Goede 
Reported-and-tested-by: Marek Szyprowski 
Link: https://lore.kernel.org/r/73018f3c-9769-72ea-0325-b3f8e2381e30@redhat.com
Link: https://lore.kernel.org/alsa-devel/9a0abddd-49e9-872d-2f00-a1697340f786@samsung.com
Signed-off-by: Takashi Iwai 
Link: https://lore.kernel.org/r/20220119155249.26754-2-tiwai@suse.de
Signed-off-by: Mark Brown

Merge tag 'asoc-v5.17-2' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus

2022-01-10T13:33:42+00:00

ASoC: Updates for v5.17

A few more updates for v5.17, nothing hugely stand out in the few days
since the initial pull request was sent.

ASoC: cs35l41: Add support for hibernate memory retention mode

2022-01-07T17:14:27+00:00

The cs35l41 supports a low power DSP memory retention mode. Add support
for entering this mode when then device is not in use.

Co-authored-by: David Rhodes 
Signed-off-by: David Rhodes 
Signed-off-by: Charles Keepax 
Link: https://lore.kernel.org/r/20220107160636.6555-3-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown

ASoC: cs35l41: Update handling of test key registers

2022-01-07T17:14:26+00:00

In preparation for the addition of PM runtime support move the test
key out of the register patches themselves. This is necessary to
allow the test key to be held during cache synchronisation, which is
required by the OTP settings which were unpacked from the device and
written by the driver.

Also whilst at it, the driver uses a mixture of accessing the test key
register by name and by address, consistently use the name.

Signed-off-by: Charles Keepax 
Link: https://lore.kernel.org/r/20220107160636.6555-2-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown

Merge tag 'asoc-v5.17' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus

2022-01-05T14:39:24+00:00

ASoC: Updates for v5.17

Not much going on framework release this time, but a big update for
drivers especially the Intel and SOF ones.

 - Refinements and cleanups around the delay() APIs.
 - Wider use of dev_err_probe().
 - Continuing cleanups and improvements to the SOF code.
 - Support for pin switches in simple-card derived cards.
 - Support for AMD Renoir ACP, Asahi Kasei Microdevices AKM4375, Intel
   systems using NAU8825 and MAX98390, Mediatek MT8915, nVidia Tegra20
   S/PDIF, Qualcomm systems using ALC5682I-VS and Texas Instruments
   TLV320ADC3xxx.

Merge branch 'for-next' into for-linus

2022-01-05T14:38:34+00:00

Pull 5.17 materials.

Signed-off-by: Takashi Iwai