08 Apr, 2022
1 commit
-
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
28 Mar, 2022
3 commits
-
commit 1f68915b2efd0d6bfd6e124aa63c94b3c69f127c upstream.
snd_pcm_reset() is a non-atomic operation, and it's allowed to run
during the PCM stream running. It implies that the manipulation of
hw_ptr and other parameters might be racy.This patch adds the PCM stream lock at appropriate places in
snd_pcm_*_reset() actions for covering that.Cc:
Reviewed-by: Jaroslav Kysela
Link: https://lore.kernel.org/r/20220322171325.4355-1-tiwai@suse.de
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit 3c3201f8c7bb77eb53b08a3ca8d9a4ddc500b4c0 upstream.
Like the previous fixes to hw_params and hw_free ioctl races, we need
to paper over the concurrent prepare ioctl calls against hw_params and
hw_free, too.This patch implements the locking with the existing
runtime->buffer_mutex for prepare ioctls. Unlike the previous case
for snd_pcm_hw_hw_params() and snd_pcm_hw_free(), snd_pcm_prepare() is
performed to the linked streams, hence the lock can't be applied
simply on the top. For tracking the lock in each linked substream, we
modify snd_pcm_action_group() slightly and apply the buffer_mutex for
the case stream_lock=false (formerly there was no lock applied)
there.Cc:
Reviewed-by: Jaroslav Kysela
Link: https://lore.kernel.org/r/20220322170720.3529-4-tiwai@suse.de
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
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
14 Aug, 2021
1 commit
-
ALSA PCM core has an optimized way to communicate with user-space for
its control and status data via mmap on the supported architectures
like x86. Depending on the situation, however, we'd rather want to
enforce user-space notifying the applptr or hwptr change explicitly
via ioctl. For example, the upcoming non-contig and non-coherent
buffer handling would need an explicit sync, and this needs to catch
the applptr and hwptr changes. Also, ASoC SOF driver will have the
SPIB support that has the similar requirement for the explicit control
of the applptr and hwptr.This patch adds the new PCM hardware info flag,
SNDRV_PCM_INFO_EXPLICIT_SYNC. When this flag is set, PCM core
disables both the control and the status mmap, which enforces
user-space to update via SYNC_PTR ioctl. In that way, drivers can
catch the applptr and hwptr update and apply the sync operation if
needed.Link: https://lore.kernel.org/r/20210812113818.6479-1-tiwai@suse.de
Link: https://lore.kernel.org/r/20210610205326.1176400-1-pierre-louis.bossart@linux.intel.com
Link: https://lore.kernel.org/r/20210813082142.5375-1-tiwai@suse.de
Signed-off-by: Takashi Iwai
09 Aug, 2021
2 commits
-
Currently we check only the substream->dma_buffer as the preset of the
buffer configuration for verifying the availability of mmap. But a
few drivers rather set up the buffer in the own way without the
standard buffer preallocation using substream->dma_buffer, and they
miss the proper checks. (Now it's working more or less fine as most
of them are running only on x86).Actually, they may set up the runtime dma_buffer (referred via
snd_pcm_get_dma_buf()) at the open callback, though. That is, this
could have been used as the primary source.This patch changes the hw_support_mmap() function to check the runtime
dma buffer at first. It's usually NULL with the standard buffer
preallocation, and in that case, we continue checking
substream->dma_buffer as fallback.Link: https://lore.kernel.org/r/20210809071829.22238-2-tiwai@suse.de
Signed-off-by: Takashi Iwai -
The recent fix c4824ae7db41 ("ALSA: pcm: Fix mmap capability check")
restricts the mmap capability only to the drivers that properly set up
the buffers, but it caused a regression for a few drivers that manage
the buffer on its own way.For those with UNKNOWN buffer type (i.e. the uninitialized / unused
substream->dma_buffer), just assume that the driver handles the mmap
properly and blindly trust the hardware info bit.Fixes: c4824ae7db41 ("ALSA: pcm: Fix mmap capability check")
Reported-and-tested-by: Jeff Woods
Cc:
Link: https://lore.kernel.org/r/s5him0gpghv.wl-tiwai@suse.de
Signed-off-by: Takashi Iwai
31 Jul, 2021
1 commit
-
The snd-dummy driver (fake_buffer configuration) uses the ops->page
callback for the mmap operations. Allow mmap for this case, too.Cc:
Fixes: c4824ae7db41 ("ALSA: pcm: Fix mmap capability check")
Signed-off-by: Jaroslav Kysela
Link: https://lore.kernel.org/r/20210730090254.612478-1-perex@perex.cz
Signed-off-by: Takashi Iwai
20 Jul, 2021
2 commits
-
The recent rewrite of the memory allocation helpers also changed the
page extraction to a common helper, snd_sgbuf_get_page(). But this
assumes implicitly that the buffer was allocated via the standard
helper (usually via preallocation), and didn't consider the case of
the manual buffer handling.This patch fixes it and also covers the manual buffer management.
Fixes: 37af81c5998f ("ALSA: core: Abstract memory alloc helpers")
Link: https://lore.kernel.org/r/20210720092732.12412-1-tiwai@suse.de
Signed-off-by: Takashi Iwai -
The hw_support_mmap() doesn't cover all memory allocation types and
might use a wrong device pointer for checking the capability.
Check the all memory allocation types more completely.Cc:
Link: https://lore.kernel.org/r/20210720092640.12338-1-tiwai@suse.de
Signed-off-by: Takashi Iwai
12 Jul, 2021
1 commit
-
If a 32-bit application is being used with a 64-bit kernel and is using
the mmap mechanism to write data, then the SNDRV_PCM_IOCTL_SYNC_PTR
ioctl results in calling snd_pcm_ioctl_sync_ptr_compat(). Make this use
pcm_lib_apply_appl_ptr() so that the substream's ack() method, if
defined, is called.The snd_pcm_sync_ptr() function, used in the 64-bit ioctl case, already
uses snd_pcm_ioctl_sync_ptr_compat().Fixes: 9027c4639ef1 ("ALSA: pcm: Call ack() whenever appl_ptr is updated")
Signed-off-by: Alan Young
Cc:
Link: https://lore.kernel.org/r/c441f18c-eb2a-3bdd-299a-696ccca2de9c@gmail.com
Signed-off-by: Takashi Iwai
10 Jun, 2021
2 commits
-
This patch moves the mmap handling code into the common memalloc
handler. It allows us to reduce the memory-type specific code in PCM
code gracefully.Link: https://lore.kernel.org/r/20210609162551.7842-5-tiwai@suse.de
Signed-off-by: Takashi Iwai -
This patch introduces the ops table to each memory allocation type
(SNDRV_DMA_TYPE_XXX) and abstract the handling for the better code
management. Then we get separate the page allocation, release and
other tasks for each type, especially for the SG buffer.Each buffer type has now callbacks in the struct snd_malloc_ops, and
the common helper functions call those ops accordingly. The former
inline code that is specific to SG-buffer is moved into the local
sgbuf.c, and we can simplify the PCM code without details of memory
handling.Link: https://lore.kernel.org/r/20210609162551.7842-4-tiwai@suse.de
Signed-off-by: Takashi Iwai
09 Jun, 2021
1 commit
-
There are a few places doing assignments in if condition in ALSA PCM
core code, which is a bad coding style that may confuse readers and
occasionally lead to bugs.This patch is merely for coding-style fixes, no functional changes.
Link: https://lore.kernel.org/r/20210608140540.17885-55-tiwai@suse.de
Signed-off-by: Takashi Iwai
25 May, 2021
2 commits
-
The normal PCM operations are already blocked during the card power
off state in the PCM common ioctl handler, but the release isn't
covered. As the PCM stream release may also access the hardware,
let's block the release until the card power turns on.Reviewed-by: Jaroslav Kysela
Link: https://lore.kernel.org/r/20210523090920.15345-7-tiwai@suse.de
Signed-off-by: Takashi Iwai -
The power_state argument of snd_power_wait() is superfluous, receiving
only SNDRV_POWER_STATE_D0. Let's drop it in all callers for
simplicity.Reviewed-by: Jaroslav Kysela
Acked-by: Mark Brown
Link: https://lore.kernel.org/r/20210523090920.15345-6-tiwai@suse.de
Signed-off-by: Takashi Iwai
26 Mar, 2021
1 commit
-
s/unconditonally/unconditionally/
s/succesful/successful/Signed-off-by: Bhaskar Chowdhury
Link: https://lore.kernel.org/r/20210326064211.6509-1-unixbhaskar@gmail.com
Signed-off-by: Takashi Iwai
08 Feb, 2021
4 commits
-
There are a few places doing the same loop iterating all PCM
substreams belonging to the PCM object. Introduce a local helper
macro, for_each_pcm_substream(), to simplify the code.Link: https://lore.kernel.org/r/20210206203656.15959-5-tiwai@suse.de
Signed-off-by: Takashi Iwai -
The PCM stop operation sets the stop_operating flag for indicating the
sync_stop post-process. This flag is, however, set unconditionally
even if the PCM trigger weren't issued. This may lead to
inconsistency in the driver side.Correct the code to set stop_operating flag only after the trigger
STOP is actually called.Fixes: 1e850beea278 ("ALSA: pcm: Add the support for sync-stop operation")
Cc:
Link: https://lore.kernel.org/r/20210206203656.15959-4-tiwai@suse.de
Signed-off-by: Takashi Iwai -
The current PCM code calls the sync_stop at the resume action due to
the analogy to the PCM prepare call pattern. But, it makes little
sense, as the sync should have been done rather at the suspend time,
not at the resume time.This patch corrects the sync_stop call at suspend/resume to assure the
sync before finishing the suspend.Fixes: 1e850beea278 ("ALSA: pcm: Add the support for sync-stop operation")
Cc:
Link: https://lore.kernel.org/r/20210206203656.15959-3-tiwai@suse.de
Signed-off-by: Takashi Iwai -
The PCM core should perform the sync for the pending stop operations
at disconnection. Otherwise it may lead to unexpected access.Currently the old user of sync_stop, USB-audio driver, has its own
sync, so this isn't needed, but it's better to guarantee the sync in
the PCM core level.This patch adds the missing sync_stop call at PCM disconnection
callback. It also assures the IRQ sync if it's specified in the
card. snd_pcm_sync_stop() is slightly modified to be called also for
any PCM substream object now.Fixes: 1e850beea278 ("ALSA: pcm: Add the support for sync-stop operation")
Cc:
Link: https://lore.kernel.org/r/20210206203656.15959-2-tiwai@suse.de
Signed-off-by: Takashi Iwai
03 Feb, 2021
1 commit
-
Back-merge the 5.11 devel branch for further patching.
Signed-off-by: Takashi Iwai
23 Jan, 2021
1 commit
-
The fix for a long-standing USB-audio bug required one more dependency
variable to be added to the hw constraints. Unfortunately I didn't
realize at debugging that the new addition may result in the overflow
of the dependency array of each snd_pcm_hw_rule (up to three plus a
sentinel), because USB-audio driver adds one more dependency only for
a certain device and bus, hence it works as is for many devices. But
in a bad case, a simple open always results in -EINVAL (with kernel
WARNING if CONFIG_SND_DEBUG is set) no matter what is passed.Since the dependencies are real and unavoidable (USB-audio restricts
the hw_params per looping over the format/rate/channels combos), the
only good solution seems to raise the bar for one more dependency for
snd_pcm_hw_rule -- so does this patch: now the hw constraint
dependencies can be up to four.Fixes: 506c203cc3de ("ALSA: usb-audio: Fix hw constraints dependencies")
Reported-by: Jamie Heilman
Link: https://lore.kernel.org/r/20210123155730.22576-1-tiwai@suse.de
Signed-off-by: Takashi Iwai
08 Jan, 2021
1 commit
-
strlcpy is deprecated. see: Documentation/process/deprecated.rst
Change the calls that do not use the strlcpy return value to the
preferred strscpy.Done with cocci script:
@@
expression e1, e2, e3;
@@- strlcpy(
+ strscpy(
e1, e2, e3);This cocci script leaves the instances where the return value is
used unchanged.After this patch, sound/ has 3 uses of strlcpy() that need to be
manually inspected for conversion and changed one day.$ git grep -w strlcpy sound/
sound/usb/card.c: len = strlcpy(card->longname, s, sizeof(card->longname));
sound/usb/mixer.c: return strlcpy(buf, p->name, buflen);
sound/usb/mixer.c: return strlcpy(buf, p->names[index], buflen);Miscellenea:
o Remove trailing whitespace in conversion of sound/core/hwdep.c
Link: https://lore.kernel.org/lkml/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=V6A6G1oUZcprmknw@mail.gmail.com/
Signed-off-by: Joe Perches
Acked-by: Mark Brown
Link: https://lore.kernel.org/r/22b393d1790bb268769d0bab7bacf0866dcb0c14.camel@perches.com
Signed-off-by: Takashi Iwai
19 Dec, 2020
1 commit
-
The PCM hw_params core function tries to clear up the PCM buffer
before actually using for avoiding the information leak from the
previous usages or the usage before a new allocation. It performs the
memset() with runtime->dma_bytes, but this might still leave some
remaining bytes untouched; namely, the PCM buffer size is aligned in
page size for mmap, hence runtime->dma_bytes doesn't necessarily cover
all PCM buffer pages, and the remaining bytes are exposed via mmap.This patch changes the memory clearance to cover the all buffer pages
if the stream is supposed to be mmap-ready (that guarantees that the
buffer size is aligned in page size).Reviewed-by: Lars-Peter Clausen
Link: https://lore.kernel.org/r/20201218145625.2045-3-tiwai@suse.de
Signed-off-by: Takashi Iwai
26 Oct, 2020
1 commit
-
Kernel-doc markups should use this format:
identifier - descriptionThere is a common comment marked, instead, with kernel-doc
notation.Some identifiers have different names between their prototypes
and the kernel-doc markup.Signed-off-by: Mauro Carvalho Chehab
Acked-by: Mark Brown
Link: https://lore.kernel.org/r/535182d6f55d7a7de293dda9676df68f5f60afc6.1603469755.git.mchehab+huawei@kernel.org
Signed-off-by: Takashi Iwai
09 Jul, 2020
1 commit
-
Replace the existing /* fall through */ comments and its variants with
the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary
fall-through markings when it is the case.[1] https://www.kernel.org/doc/html/latest/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through
Signed-off-by: Gustavo A. R. Silva
Link: https://lore.kernel.org/r/20200708203236.GA5112@embeddedor
Signed-off-by: Takashi Iwai
16 Jun, 2020
1 commit
-
We avoided the explicit use of dma_mmap_coherent() on x86 because of a
spurious warning in x86 APT code in the past. However, this blindly
assumes that the pages allocated via dma_alloc_coherent() on x86 are
the ones convertible via virt_to_page() (that is used in the default
mmap handler), and it's no longer true; with the indirect DMA ops,
this can be handled differently. The only certain way for doing mmap
such pages is the dma_mmap_coherent(), and the warning seems already
gone in the recent code, so let's use it consistently.Link: https://lore.kernel.org/r/20200615160045.2703-2-tiwai@suse.de
Signed-off-by: Takashi Iwai
12 Jun, 2020
1 commit
-
Pull sound fixes from Takashi Iwai:
"Here are last-minute fixes gathered before merge window close; a few
fixes are for the core while the rest majority are driver fixes.- PCM locking annotation fixes and the possible self-lock fix
- ASoC DPCM regression fixes with multi-CPU DAI
- A fix for inconsistent resume from system-PM on USB-audio
- Improved runtime-PM handling with multiple USB interfaces
- Quirks for HD-audio and USB-audio
- Hardened firmware handling in max98390 codec
- A couple of fixes for meson"
* tag 'sound-fix-5.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (21 commits)
ASoC: rt5645: Add platform-data for Asus T101HA
ASoC: Intel: bytcr_rt5640: Add quirk for Toshiba Encore WT10-A tablet
ASoC: SOF: nocodec: conditionally set dpcm_capture/dpcm_playback flags
ASoC: Intel: boards: replace capture_only by dpcm_capture
ASoC: core: only convert non DPCM link to DPCM link
ASoC: soc-pcm: dpcm: fix playback/capture checks
ASoC: meson: add missing free_irq() in error path
ALSA: pcm: disallow linking stream to itself
ALSA: usb-audio: Manage auto-pm of all bundled interfaces
ALSA: hda/realtek - add a pintbl quirk for several Lenovo machines
ALSA: pcm: fix snd_pcm_link() lockdep splat
ALSA: usb-audio: Use the new macro for HP Dock rename quirks
ALSA: usb-audio: Add vendor, product and profile name for HP Thunderbolt Dock
ALSA: emu10k1: delete an unnecessary condition
dt-bindings: ASoc: Fix tdm-slot documentation spelling error
ASoC: meson: fix memory leak of links if allocation of ldata fails
ALSA: usb-audio: Fix inconsistent card PM state after resume
ASoC: max98390: Fix potential crash during param fw loading
ASoC: max98390: Fix incorrect printf qualifier
ASoC: fsl-asoc-card: Defer probe when fail to find codec device
...
09 Jun, 2020
1 commit
-
Prevent SNDRV_PCM_IOCTL_LINK linking stream to itself - the code
can't handle it. Fixed commit is not where bug was introduced, but
changes the context significantly.Cc: stable@vger.kernel.org
Fixes: 0888c321de70 ("pcm_native: switch to fdget()/fdput()")
Signed-off-by: Michał Mirosław
Link: https://lore.kernel.org/r/89c4a2487609a0ed6af3ecf01cc972bdc59a7a2d.1591634956.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Takashi Iwai
08 Jun, 2020
1 commit
-
Add and use snd_pcm_stream_lock_nested() in snd_pcm_link/unlink
implementation. The code is fine, but generates a lockdep complaint:============================================
WARNING: possible recursive locking detected
5.7.1mq+ #381 Tainted: G O
--------------------------------------------
pulseaudio/4180 is trying to acquire lock:
ffff888402d6f508 (&group->lock){-...}-{2:2}, at: snd_pcm_common_ioctl+0xda8/0xee0 [snd_pcm]but task is already holding lock:
ffff8883f7a8cf18 (&group->lock){-...}-{2:2}, at: snd_pcm_common_ioctl+0xe4e/0xee0 [snd_pcm]other info that might help us debug this:
Possible unsafe locking scenario:CPU0
----
lock(&group->lock);
lock(&group->lock);*** DEADLOCK ***
May be due to missing lock nesting notation
2 locks held by pulseaudio/4180:
#0: ffffffffa1a05190 (snd_pcm_link_rwsem){++++}-{3:3}, at: snd_pcm_common_ioctl+0xca0/0xee0 [snd_pcm]
#1: ffff8883f7a8cf18 (&group->lock){-...}-{2:2}, at: snd_pcm_common_ioctl+0xe4e/0xee0 [snd_pcm]
[...]Cc: stable@vger.kernel.org
Fixes: f57f3df03a8e ("ALSA: pcm: More fine-grained PCM link locking")
Signed-off-by: Michał Mirosław
Link: https://lore.kernel.org/r/37252c65941e58473b1219ca9fab03d48f47e3e3.1591610330.git.mirq-linux@rere.qmqm.plSigned-off-by: Takashi Iwai
26 Apr, 2020
1 commit
-
... and no, __put_user() doesn't help here - skipping
access_ok() on the second call does not remove the
possibility of page having become unmapped or r/o
in the meanwhileSigned-off-by: Al Viro
03 Apr, 2020
1 commit
-
Pull sound updates from Takashi Iwai:
"This became again a busy development cycle. There are few ALSA core
updates (merely API cleanups and sparse fixes), with the majority of
other changes are found in ASoC scene.Here are some highlights:
ALSA core:
- More helper macros for sparse warning fixes (e.g. bitwise types)
- Slight optimization of PCM OSS locks
- Make common handling for PCM / compress buffers (for SOF)ASoC:
- Lots of code refactoring and modernization for (still ongoing)
componentization works
- Conversion of SND_SOC_ALL_CODECS to use imply
- Continued refactoring and fixing of the Intel SOF/SST support,
including the initial (but still incomplete) SoundWire support
- SoundWire and more advanced clocking support for Realtek RT5682
- Support for amlogic GX, Meson 8, Meson 8B and T9015 DAC, Broadcom
DSL/PON, Ingenic JZ4760 and JZ4770, Realtek RL6231, and TI TAS2563
and TLV320ADCX140HD-audio:
- Optimizations in HDMI jack handling
- A few new quirks and fixups for Realtek codecsUSB-audio:
- Delayed registration support
- New quirks for Motu, Kingston, Presonus"* tag 'sound-5.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (415 commits)
ALSA: usb-audio: Fix case when USB MIDI interface has more than one extra endpoint descriptor
Revert "ALSA: uapi: Drop asound.h inclusion from asoc.h"
ALSA: hda/realtek - Remove now-unnecessary XPS 13 headphone noise fixups
ALSA: hda/realtek - Set principled PC Beep configuration for ALC256
ALSA: doc: Document PC Beep Hidden Register on Realtek ALC256
ALSA: hda/realtek - a fake key event is triggered by running shutup
ALSA: hda: default enable CA0132 DSP support
ASoC: amd: acp3x-pcm-dma: clean up two indentation issues
ASoC: tlv320adcx140: Remove undocumented property
ASoC: Intel: sof_sdw: Add Volteer support with RT5682 SNDW helper function
ASoC: Intel: common: add match table for TGL RT5682 SoundWire driver
ASoC: Intel: boards: add sof_sdw machine driver
ASoC: Intel: soc-acpi: update topology and driver name for SoundWire platforms
ASoC: rt5682: move DAI clock registry to I2S mode
ASoC: pxa: magician: convert to use i2c_new_client_device()
ASoC: SOF: Intel: hda-ctrl: add reset cycle before parsing capabilities
Asoc: SOF: Intel: hda: check SoundWire wakeen interrupt in irq thread
ASoC: SOF: Intel: hda: add WAKEEN interrupt support for SoundWire
ASoC: SOF: Intel: hda: add parameter to control SoundWire clock stop quirks
ASoC: SOF: Intel: hda: merge IPC, stream and SoundWire interrupt handlers
...
30 Mar, 2020
1 commit
-
* pm-qos: (30 commits)
PM: QoS: annotate data races in pm_qos_*_value()
Documentation: power: fix pm_qos_interface.rst format warning
PM: QoS: Make CPU latency QoS depend on CONFIG_CPU_IDLE
Documentation: PM: QoS: Update to reflect previous code changes
PM: QoS: Update file information comments
PM: QoS: Drop PM_QOS_CPU_DMA_LATENCY and rename related functions
sound: Call cpu_latency_qos_*() instead of pm_qos_*()
drivers: usb: Call cpu_latency_qos_*() instead of pm_qos_*()
drivers: tty: Call cpu_latency_qos_*() instead of pm_qos_*()
drivers: spi: Call cpu_latency_qos_*() instead of pm_qos_*()
drivers: net: Call cpu_latency_qos_*() instead of pm_qos_*()
drivers: mmc: Call cpu_latency_qos_*() instead of pm_qos_*()
drivers: media: Call cpu_latency_qos_*() instead of pm_qos_*()
drivers: hsi: Call cpu_latency_qos_*() instead of pm_qos_*()
drm: i915: Call cpu_latency_qos_*() instead of pm_qos_*()
x86: platform: iosf_mbi: Call cpu_latency_qos_*() instead of pm_qos_*()
cpuidle: Call cpu_latency_qos_limit() instead of pm_qos_request()
PM: QoS: Add CPU latency QoS API wrappers
PM: QoS: Adjust pm_qos_request() signature and reorder pm_qos.h
PM: QoS: Simplify definitions of CPU latency QoS trace events
...
17 Feb, 2020
1 commit
-
Merging the UAC2 effect unit parser improvement. As it's based on the
previous usb-audio driver fix, it was deviated from for-next branch.Signed-off-by: Takashi Iwai
14 Feb, 2020
1 commit
-
Call cpu_latency_qos_add/update/remove_request() and
cpu_latency_qos_request_active() instead of
pm_qos_add/update/remove_request() and pm_qos_request_active(),
respectively, because the latter are going to be dropped.No intentional functional impact.
Signed-off-by: Rafael J. Wysocki
Reviewed-by: Ulf Hansson
Acked-by: Mark Brown
Acked-by: Takashi Iwai
Reviewed-by: Amit Kucheria
Tested-by: Amit Kucheria
13 Feb, 2020
1 commit
-
The commit 66f2d19f8116 ("ALSA: pcm: Fix memory leak at closing a
stream without hw_free") tried to fix the regression wrt the missing
hw_free call at closing without SNDRV_PCM_IOCTL_HW_FREE ioctl.
However, the code change dropped mistakenly the state check, resulting
in calling hw_free twice when SNDRV_PCM_IOCTL_HW_FRE got called
beforehand. For most drivers, this is almost harmless, but the
drivers like SOF show another regression now.This patch adds the state condition check before calling do_hw_free()
at releasing the stream for avoiding the double hw_free calls.Fixes: 66f2d19f8116 ("ALSA: pcm: Fix memory leak at closing a stream without hw_free")
Reported-by: Bard Liao
Reported-by: Pierre-Louis Bossart
Tested-by: Pierre-Louis Bossart
Cc:
Link: https://lore.kernel.org/r/s5hd0ajyprg.wl-tiwai@suse.de
Signed-off-by: Takashi Iwai
10 Feb, 2020
2 commits
-
The parameter bit mask needs often explicit cast with __force,
e.g. for the PCM subformat type. Instead of adding __force at each
place, which is error prone, this patch introduces a new macro and
replaces the all bit shift with it. This fixes the sparse warnings
like the following:
sound/core/pcm_native.c:2508:30: warning: restricted snd_pcm_access_t degrades to integerNo functional changes, just sparse warning fixes.
Link: https://lore.kernel.org/r/20200206163945.6797-7-tiwai@suse.de
Signed-off-by: Takashi Iwai -
Simplify the code with the new macros for PCM format type iterations.
This fixes the sparse warnings nicely:
sound/core/pcm_native.c:2302:26: warning: restricted snd_pcm_format_t degrades to integer
sound/core/pcm_native.c:2306:54: warning: incorrect type in argument 1 (different base types)
sound/core/pcm_native.c:2306:54: expected restricted snd_pcm_format_t [usertype] format
sound/core/pcm_native.c:2306:54: got unsigned int [assigned] k
....No functional changes, just sparse warning fixes.
Link: https://lore.kernel.org/r/20200206163945.6797-6-tiwai@suse.de
Signed-off-by: Takashi Iwai
31 Jan, 2020
1 commit
-
Since we have a bitwise definition of snd_pcm_state_t and use it for
certain struct fields, a few new (and years old) sparse warnings came
up. This patch is an attempt to cover them.- The state fields in snd_pcm_mmap_status* and co are all defined as
snd_pcm_state_t type now- The PCM action callbacks take snd_pcm_state_t argument as well;
some actions taking special values got the explicit cast and
comments- For the PCM action that doesn't need an extra argument receives
ACTION_ARG_IGNORE instead of ambiguous 0While we're at it, the boolean argument is also properly changed to
bool and true/false, as well as a slight refactoring of PCM pause
helper function to make easier to read.No functional changes, just shutting up chatty sparse.
Fixes: 46b770f720bd ("ALSA: uapi: Fix sparse warning")
Reported-by: kbuild test robot
Link: https://lore.kernel.org/r/20200131152214.11698-1-tiwai@suse.de
Signed-off-by: Takashi Iwai