| Age | Commit message (Collapse) | Author |
|---|
|
commit f3d83317a69e7d658e7c83e24f8b31ac533c39e3 upstream.
This reverts commit f6a0dd107ad0c8b59d1c9735eea4b8cb9f460949.
The commit caused a regression on LINE6 Transport that has no control
caps. Although reverting the commit may result back in a spurious
error message for some device again, it's the simplest regression fix,
hence it's taken as is at first. The further code fix will follow
later.
Fixes: f6a0dd107ad0 ("ALSA: line6: Only determine control port properties if needed")
Reported-by: Igor Zinovev <zinigor@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 37a7ea4a9b81f6a864c10a7cb0b96458df5310a3 upstream.
snd_seq_pool_done() syncs with closing of all opened threads, but it
aborts the wait loop with a timeout, and proceeds to the release
resource even if not all threads have been closed. The timeout was 5
seconds, and if you run a crazy stuff, it can exceed easily, and may
result in the access of the invalid memory address -- this is what
syzkaller detected in a bug report.
As a fix, let the code graduate from naiveness, simply remove the loop
timeout.
BugLink: http://lkml.kernel.org/r/CACT4Y+YdhDV2H5LLzDTJDVF-qiYHUHhtRaW4rbb4gUhTCQB81w@mail.gmail.com
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 4842e98f26dd80be3623c4714a244ba52ea096a8 upstream.
When a sequencer queue is created in snd_seq_queue_alloc(),it adds the
new queue element to the public list before referencing it. Thus the
queue might be deleted before the call of snd_seq_queue_use(), and it
results in the use-after-free error, as spotted by syzkaller.
The fix is to reference the queue object at the right time.
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit af677166cf63c179dc2485053166e02c4aea01eb upstream.
Without this change, the HDMI/DP codec will be recognised as a
generic codec, and there is no sound when playing through this codec.
As suggested by NVidia side, after adding the new ID in the driver,
the sound playing works well.
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 2e40795c3bf344cfb5220d94566205796e3ef19a upstream.
Plantronics BT600 does not support reading the sample rate which leads
to many lines of "cannot get freq at ep 0x1" and "cannot get freq at
ep 0x82". This patch adds the USB ID of the BT600 to quirks.c and
avoids those error messages.
Signed-off-by: Dennis Kadioglu <denk@post.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 6a2a2f45560a9cb7bc49820883b042e44f83726c upstream.
This module has a bug not to return error code in a case that data
structure for transmitted packets fails to be initialized.
This commit fixes the bug.
Fixes: 35efa5c489de ("ALSA: firewire-tascam: add streaming functionality")
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 5faf071d08ddd1c1be66deaa93a09ccf43f5b538 upstream.
Unfortunately, I seem to have missed a case where an IRQ safe spinlock was
required, in samsung_i2s_dai_remove, when I fixed up the other calls in
this patch:
316fa9e09ad7 ("ASoC: samsung: Use IRQ safe spin lock calls")
This causes a lockdep warning when unbinding and rebinding the audio card:
[ 104.357664] CPU0 CPU1
[ 104.362174] ---- ----
[ 104.366692] lock(&(&pri_dai->spinlock)->rlock);
[ 104.371372] local_irq_disable();
[ 104.377283] lock(&(&substream->self_group.lock)->rlock);
[ 104.385259] lock(&(&pri_dai->spinlock)->rlock);
[ 104.392469] <Interrupt>
[ 104.395072] lock(&(&substream->self_group.lock)->rlock);
[ 104.400710]
[ 104.400710] *** DEADLOCK ***
Fixes: ce8bcdbb61d9 ("ASoC: samsung: i2s: Protect more registers with a spinlock")
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit c8eabf821cac120afb78ca251b07cbf520406a7e upstream.
"*val" is a u64. It definitely looks like we intend to use the high 32
bits as well.
Fixes: 700a9a63f9c1 ("ASoC: Intel: Skylake: Add module instance id generation APIs")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Vinod Koul <vinod.koul@intel.com>
Tested-by: Kranthi G <gudishax.kranthikumar@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit a823a17981a73faa115bc0f7eda0190763075e2c upstream.
cht_bsw_rt5645 driver allocates the own codec_id string but doesn't
release it. For simplicity, put the string in cht_mc_private; then
the string is allocated in a shot and released altogether.
Fixes: c8560b7c917f ("ASoC: cht_bsw_rt5645: Fix writing to string literal")
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 3b89e4b77ef9c2f985964fab17032db98f074ed0 upstream.
A bugfix accidentally removed the implicit initialization of the
dma channel number, causing undefined behavior when
v->alloc_dma_channel is NULL:
sound/soc/qcom/lpass-platform.c: In function ‘lpass_platform_pcmops_open’:
sound/soc/qcom/lpass-platform.c:83:29: error: ‘dma_ch’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
This adds back an explicit initialization to zero, restoring the
previous behavior for that case.
Fixes: 022d00ee0b55 ("ASoC: lpass-platform: Fix broken pcm data usage")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Kenneth Westfield <kwestfie@codeaurora.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 4763601a56f155ddf94ef35fc2c41504a2de15f5 upstream.
The function returns -EINVAL even if it builds the stream properly.
The bogus error code sneaked in during the code refactoring, but it
wasn't noticed until now since the returned error code itself is
ignored in anyway. Kill it here, but there is no behavior change by
this patch, obviously.
Fixes: e5779998bf8b ('ALSA: usb-audio: refactor code')
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 1d0f953086f090a022f2c0e1448300c15372db46 upstream.
Commit 16200948d83 ("ALSA: usb-audio: Fix race at stopping the stream") was
incomplete causing another more severe kernel panic, so it got reverted.
This fixes both the original problem and its fallout kernel race/crash.
The original fix is to move the endpoint member NULL clearing logic inside
wait_clear_urbs() so the irq triggering the urb completion doesn't call
retire_capture/playback_urb() after the NULL clearing and generate a panic.
However this creates a new race between snd_usb_endpoint_start()'s call
to wait_clear_urbs() and the irq urb completion handler which again calls
retire_capture/playback_urb() leading to a new NULL dereference.
We keep the EP deactivation code in snd_usb_endpoint_start() because
removing it will break the EP reference counting (see [1] [2] for info),
however we don't need the "can_sleep" mechanism anymore because a new
function was introduced (snd_usb_endpoint_sync_pending_stop()) which
synchronizes pending stops and gets called inside the pcm prepare callback.
It also makes sense to remove can_sleep because it was also removed from
deactivate_urbs() signature in [3] so we benefit from more simplification.
[1] commit 015618b90 ("ALSA: snd-usb: Fix URB cancellation at stream start")
[2] commit e9ba389c5 ("ALSA: usb-audio: Fix scheduling-while-atomic bug in PCM capture stream")
[3] commit ccc1696d5 ("ALSA: usb-audio: simplify endpoint deactivation code")
Fixes: f8114f8583bb ("Revert "ALSA: usb-audio: Fix race at stopping the stream"")
Signed-off-by: Ioan-Adrian Ratiu <adi@adirat.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit c7efff9284dfde95a11aaa811c9d8ec8167f0f6e upstream.
Although the old quirk table showed ASUS X71SL with ALC663 codec being
compatible with asus-mode3 fixup, the bugzilla reporter explained that
asus-model8 fits better for the dual headphone controls. So be it.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=191781
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 85bcf96caba8b4a7c0805555638629ba3c67ea0c upstream.
ASUS ROG Ranger VIII with ALC1150 codec requires the extra GPIO pin to
up for the front panel. Just use the existing fixup for setting up
the GPIO pins.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=189411
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 2fc995a87f2efcd803438f07bfecd35cc3d90d32 upstream.
When ASoC Intel SST Medfield driver is probed but without codec / card
assigned, it causes an Oops and freezes the kernel at suspend/resume,
PM: Suspending system (freeze)
Suspending console(s) (use no_console_suspend to debug)
BUG: unable to handle kernel NULL pointer dereference at 0000000000000018
IP: [<ffffffffc09d9409>] sst_soc_prepare+0x19/0xa0 [snd_soc_sst_mfld_platform]
Oops: 0000 [#1] PREEMPT SMP
CPU: 0 PID: 1552 Comm: systemd-sleep Tainted: G W 4.9.0-rc6-1.g5f5c2ad-default #1
Call Trace:
[<ffffffffb45318f9>] dpm_prepare+0x209/0x460
[<ffffffffb4531b61>] dpm_suspend_start+0x11/0x60
[<ffffffffb40d3cc2>] suspend_devices_and_enter+0xb2/0x710
[<ffffffffb40d462e>] pm_suspend+0x30e/0x390
[<ffffffffb40d2eba>] state_store+0x8a/0x90
[<ffffffffb43c670f>] kobj_attr_store+0xf/0x20
[<ffffffffb42b0d97>] sysfs_kf_write+0x37/0x40
[<ffffffffb42b02bc>] kernfs_fop_write+0x11c/0x1b0
[<ffffffffb422be68>] __vfs_write+0x28/0x140
[<ffffffffb43728a8>] ? apparmor_file_permission+0x18/0x20
[<ffffffffb433b2ab>] ? security_file_permission+0x3b/0xc0
[<ffffffffb422d095>] vfs_write+0xb5/0x1a0
[<ffffffffb422e3d6>] SyS_write+0x46/0xa0
[<ffffffffb4719fbb>] entry_SYSCALL_64_fastpath+0x1e/0xad
Add proper NULL checks in the PM code of mdfld driver.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 5e0ad0d8747f3e4803a9c3d96d64dd7332506d3c upstream.
Commit [64047d7f4912 ALSA: hda - ignore the assoc and seq when comparing
pin configurations] intented to ignore both seq and assoc at pin
comparing, but it only ignored seq. So that commit may still fail to
match pins on some machines.
Change the bitmask to also ignore assoc.
v2: Use macro to do bit masking.
Thanks to Hui Wang for the analysis.
Fixes: 64047d7f4912 ("ALSA: hda - ignore the assoc and seq when comparing...")
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit f73cd43ac3b41c0f09a126387f302bbc0d9c726d upstream.
HP Z1 Gen3 AiO with Conexant codec doesn't give an unsolicited event
to the headset mic pin upon the jack plugging, it reports only to the
headphone pin. It results in the missing mic switching. Let's fix up
by simply gating the jack event.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 989dbe4a30728c047316ab87e5fa8b609951ce7c upstream.
This group of new pins is not in the pin quirk table yet, adding
them to the pin quirk table to fix the headset-mic problem.
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 64047d7f4912de1769d1bf0d34c6322494b13779 upstream.
More and more pin configurations have been adding to the pin quirk
table, lots of them are only different from assoc and seq, but they
all apply to the same QUIRK_FIXUP, if we don't compare assoc and seq
when matching pin configurations, it will greatly reduce the pin
quirk table size.
We have tested this change on a couple of Dell laptops, it worked
well.
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit b5337cfe067e96b8a98699da90c7dcd2bec21133 upstream.
I'm using an Alienware 15 R2 and had to use the alienware quirks to
get my headphone output working.
I fixed it by adding, SND_PCI_QUIRK(0x1028, 0x0708, "Alienware 15 R2
2016", QUIRK_ALIENWARE) to the patch.
Signed-off-by: Sven Hahne <hahne@zeitkunst.eu>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 995c6a7fd9b9212abdf01160f6ce3193176be503 upstream.
Sampling rate changes after first set one are not reflected to the
hardware, while driver and ALSA think the rate has been changed.
Fix the problem by properly stopping the interface at the beginning of
prepare call, allowing new rate to be set to the hardware. This keeps
the hardware in sync with the driver.
Signed-off-by: Jussi Laako <jussi@sonarnerd.net>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 82ffb6fc637150b279f49e174166d2aa3853eaf4 upstream.
The Logitech QuickCam Communicate Deluxe/S7500 microphone fails with the
following warning.
[ 6.778995] usb 2-1.2.2.2: Warning! Unlikely big volume range (=3072),
cval->res is probably wrong.
[ 6.778996] usb 2-1.2.2.2: [5] FU [Mic Capture Volume] ch = 1, val =
4608/7680/1
Adding it to the list of devices in volume_control_quirks makes it work
properly, fixing related typo.
Signed-off-by: Con Kolivas <kernel@kolivas.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
We accidentally introduced a dereference before the NULL check in
xmit_descs() as part of silencing a GCC warning.
Fixes: 16f46050e709 ("dbri: Fix compiler warning")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Pull sparc fixes from David Miller:
"Two ugly build warning fixes"
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc:
dbri: Fix compiler warning
qlogicpti: Fix compiler warnings
|
|
dbri uses 'u32' for dma handle while invoking kernel DMA APIs,
instead of using dma_addr_t. This hasn't caused any 'incompatible
pointer type' warning on SPARC because until now dma_addr_t is of
type u32. However, recent changes in SPARC ATU (iommu) enabled 64bit
DMA and therefore dma_addr_t became of type u64. This makes
'incompatible pointer type' warnings inevitable.
e.g.
sound/sparc/dbri.c: In function ‘snd_dbri_create’:
sound/sparc/dbri.c:2538: warning: passing argument 3 of ‘dma_zalloc_coherent’ from incompatible pointer type
./include/linux/dma-mapping.h:608: note: expected ‘dma_addr_t *’ but argument is of type ‘u32 *’
For the record, dbri(sbus) driver never executes on sun4v. Therefore
even though 64bit DMA is enabled on SPARC, dbri continues to use
legacy iommu that guarantees DMA address is always in 32bit range.
This patch resolves above compiler warning.
Signed-off-by: Tushar Dave <tushar.n.dave@oracle.com>
Reviewed-by: thomas tai <thomas.tai@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"Three trivial fixes:
A regression fix for ASRock mobo, a use-after-free fix at hot-unplug
of USB-audio, and a quirk for new Thinkpad models"
* tag 'sound-4.9-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ALSA: usb-audio: Fix use-after-free of usb_device at disconnect
ALSA: hda - Fix mic regression by ASRock mobo fixup
ALSA: hda - add a new condition to check if it is thinkpad
|
|
The usb-audio driver implements the deferred device disconnection for
the device in use. In this mode, the disconnection callback returns
immediately while the actual ALSA card object removal happens later
when all files get closed. As Shuah reported, this code flow,
however, leads to a use-after-free, detected by KASAN:
BUG: KASAN: use-after-free in snd_usb_audio_free+0x134/0x160 [snd_usb_audio] at addr ffff8801c863ce10
Write of size 8 by task pulseaudio/2244
Call Trace:
[<ffffffff81b31473>] dump_stack+0x67/0x94
[<ffffffff81564ef1>] kasan_object_err+0x21/0x70
[<ffffffff8156518a>] kasan_report_error+0x1fa/0x4e0
[<ffffffff81564ad7>] ? kasan_slab_free+0x87/0xb0
[<ffffffff81565733>] __asan_report_store8_noabort+0x43/0x50
[<ffffffffa0fc0f54>] ? snd_usb_audio_free+0x134/0x160 [snd_usb_audio]
[<ffffffffa0fc0f54>] snd_usb_audio_free+0x134/0x160 [snd_usb_audio]
[<ffffffffa0fc0fb1>] snd_usb_audio_dev_free+0x31/0x40 [snd_usb_audio]
[<ffffffff8243c78a>] __snd_device_free+0x12a/0x210
[<ffffffff8243d1f5>] snd_device_free_all+0x85/0xd0
[<ffffffff8242cae4>] release_card_device+0x34/0x130
[<ffffffff81ef1846>] device_release+0x76/0x1e0
[<ffffffff81b37ad7>] kobject_release+0x107/0x370
.....
Object at ffff8801c863cc80, in cache kmalloc-2048 size: 2048
Allocated:
[<ffffffff810804eb>] save_stack_trace+0x2b/0x50
[<ffffffff81564296>] save_stack+0x46/0xd0
[<ffffffff8156450d>] kasan_kmalloc+0xad/0xe0
[<ffffffff81560d1a>] kmem_cache_alloc_trace+0xfa/0x240
[<ffffffff8214ea47>] usb_alloc_dev+0x57/0xc90
[<ffffffff8216349d>] hub_event+0xf1d/0x35f0
....
Freed:
[<ffffffff810804eb>] save_stack_trace+0x2b/0x50
[<ffffffff81564296>] save_stack+0x46/0xd0
[<ffffffff81564ac1>] kasan_slab_free+0x71/0xb0
[<ffffffff81560929>] kfree+0xd9/0x280
[<ffffffff8214de6e>] usb_release_dev+0xde/0x110
[<ffffffff81ef1846>] device_release+0x76/0x1e0
....
It's the code trying to clear drvdata of the assigned usb_device where
the usb_device itself was already released in usb_release_dev() after
the disconnect callback.
This patch fixes it by checking whether the code path is via the
disconnect callback, i.e. chip->shutdown flag is set.
Fixes: 79289e24194a ('ALSA: usb-audio: Refer to chip->usb_id for quirks...')
Reported-and-tested-by: Shuah Khan <shuahkh@osg.samsung.com>
Cc: <stable@vger.kernel.org> # v4.6+
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
In commit 022d00ee0b55 ("ASoC: lpass-platform: Fix broken pcm data
usage") the stream specific information initialization was broken, with
the dma channel information not being initialized if there was no
alloc_dma_channel() helper function.
Before that, the DMA channel number was implicitly initialized to zero
because the backing store was allocated with devm_kzalloc(). When the
init code was rewritten, that implicit initialization was lost, and gcc
rightfully complains about an uninitialized variable being used.
Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Cc: Mark Brown <broonie@kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
The commit [1a3f099101b8: ALSA: hda - Fix surround output pins for
ASRock B150M mobo] introduced a fixup of pin configs for ASRock
mobos to fix the surround outputs. However, this overrides the pin
configs of the mic pins as if they are outputs-only, effectively
disabling the mic inputs. Of course, it's a regression wrt mic
functionality.
Actually the pins 0x18 and 0x1a don't need to be changed; we just need
to disable the bogus pins 0x14 and 0x15. Then the auto-parser will
pick up mic pins as switchable and assign the surround outputs there.
This patch removes the incorrect pin overrides of NID 0x18 and 0x1a
from the ASRock fixup.
Fixes: 1a3f099101b8 ('ALSA: hda - Fix surround output pins for ASRock...')
Reported-and-tested-by: Vitor Antunes <vitor.hda@gmail.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=187431
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Latest Thinkpad laptops use the HKEY_HID LEN0268 instead of the
LEN0068, as a result neither audio mute led nor mic mute led can work
any more.
After adding the new HKEY_HID into the is_thinkpad(), both of them
works well as before.
Cc: <stable@vger.kernel.org>
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Currently the ALSA proc handler allows read or write even if the proc
file were write-only or read-only. It's mostly harmless, does thing
but allocating memory and ignores the input/output. But it doesn't
tell user about the invalid use, and it's confusing and inconsistent
in comparison with other proc files.
This patch adds some sanity checks and let the proc handler returning
an -EIO error when the invalid read/write is performed.
Cc: <stable@vger.kernel.org> # v4.2+
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The ALSA proc handler allows currently the write in the unlimited size
until kmalloc() fails. But basically the write is supposed to be only
for small inputs, mostly for one line inputs, and we don't have to
handle too large sizes at all. Since the kmalloc error results in the
kernel warning, it's better to limit the size beforehand.
This patch adds the limit of 16kB, which must be large enough for the
currently existing code.
Cc: stable@vger.kernel.org # v4.2+
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
'asoc/fix/sti', 'asoc/fix/sti-codec', 'asoc/fix/sunxi' and 'asoc/fix/tas571x' into asoc-linus
|
|
'asoc/fix/hdmi-codec', 'asoc/fix/pxa', 'asoc/fix/qcom' and 'asoc/fix/rt298' into asoc-linus
|
|
|
|
This patch fixes issues introduced in commit 73f5dfc68316bef2ab7062ec
"ASoC: samsung: get access to DMA engine early to defer probe properly"
and indicated by a following compilation warning:
CC [M] sound/soc/samsung/spdif.o
sound/soc/samsung/spdif.c: In function ‘spdif_probe’:
sound/soc/samsung/spdif.c:419:6: warning: ‘filter’ may be used uninitialized
in this function [-Wuninitialized]
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
In the current probe function the GPIO is acquired after the codec's
bus clock is enabled. However if it fails to acquire the GPIO due to
a deferred probe, it does not disable the bus clock before bailing out.
This would result in the clock being enabled multiple times.
Move the code that enables the bus clock after the part that gets the
GPIO, maintaining a separation between resource acquisition and device
enablement in the probe function.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
This patch adds module licence to lpass-cpu driver, without this
patch lpass-cpu module would taint with below error:
snd_soc_lpass_cpu: module license 'unspecified' taints kernel.
Disabling lock debugging due to kernel taint
snd_soc_lpass_cpu: Unknown symbol regmap_write (err 0)
snd_soc_lpass_cpu: Unknown symbol devm_kmalloc (err 0)
...
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Acked-by: Kenneth Westfield <kwestfie@codeaurora.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
This patch fixes lpass-platform driver which was broken in v4.9-rc1.
lpass_pcm_data data structure holds information specific to stream.
Holding a single private pointer to it in global lpass_data
will not work, because it would be overwritten by for each pcm instance.
This code was breaking playback when we have both playback and capture
pcm streams, as playback settings are over written by capture settings.
Fix this by moving channel allocation logic out of pcm_new to pcm_open
so that we can store the stream specific information in private_data of
snd_pcm_runtime.
Fixes: 6adcbdcd4b6e ("ASoC: lpass-platform: don't use snd_soc_pcm_set_drvdata()")
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
When sun4i_codec_create_card fails, we do not assign a proper error
code to the return value. The return value would be 0 from the previous
function call, or we would have bailed out sooner. This would confuse
the driver core into thinking the device probe succeeded, when in fact
it didn't, leaving various devres based resources lingering.
Make the create_card function pass back a meaningful error code, and
assign it to the return value.
Fixes: 45fb6b6f2aa3 ("ASoC: sunxi: add support for the on-chip codec on
early Allwinner SoCs")
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
If a DAI specifies "#sound-dai-cells = <0>" in device-tree then
hdmi_of_xlate_dai_name() will be called with zero args, which it isn't
implemented to cope with. The resulting use of an uninitialised variable
for the id will usually result in an error like:
asoc-simple-card sound: parse error -11
asoc-simple-card: probe of sound failed with error -11
Fix this by using and id of zero if no arg is provided.
Fixes: 9731f82d6016 ("ASoC: hdmi-codec: enable multi probe for same device")
Signed-off-by: Jon Medhurst <tixy@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
ASoC Samsung sub-drivers tried to get access to their DMA engine
controllers as a last step in driver probe. If a DMA engine was not
available yet, samsung_asoc_dma_platform_register() function ended in
-EPROBE_DEFER, but the driver already registered its component to ASoC
core. This patch moves samsung_asoc_dma_platform_register() call before
registering any components, to the common place, where driver was gathering
all needed resources.
In case of Samsung Exynos i2s driver the issue was even worse. The driver
managed already to register its secondary DAI platform device before
even getting the DMA engine access. That together with -EPROBE_DEFER error
code from samsung_i2s_probe() immediately triggered another round of
deferred probe retry and in turn endless loop of driver probing.
This patch fixes broken boot on Odroid XU3 and other Exynos5422-based
boards.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
da7219 output (for headset capture) should be set to high-impedance when
not in use, since it will otherwise interfere with output from other
codecs attached to the same DAI.
Signed-off-by: Stephen Barber <smbarber@chromium.org>
Acked-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
HDMI codec is required to be powered up before controller initialization
for successful enumeration of codec. If the probe fails it needs to be
powered off to balance the power state of HDMI codec.
This fix balances the reference count in the error path before turning
off the codec.
Reported-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Sodhi, VunnyX <vunnyx.sodhi@intel.com>
Signed-off-by: Subhransu S. Prusty <subhransu.s.prusty@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The stk1160 chip needs QUIRK_AUDIO_ALIGN_TRANSFER. This patch resolves
the issue reported on the mailing list
(http://marc.info/?l=linux-sound&m=139223599126215&w=2) and also fixes
bug 180071 (https://bugzilla.kernel.org/show_bug.cgi?id=180071).
Signed-off-by: Marcel Hasler <mahasler@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Some registers accesses are done in atomic context.
Enable fast io to use spinlock instead of mutex to protect access.
Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
If 'IEC958 Playback Default' control is updated during playback,
Channel status needs to be set according to the runtime structure.
Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The recent rewrite of the sequencer time accounting using timespec64
in the commit [3915bf294652: ALSA: seq_timer: use monotonic times
internally] introduced a bad regression. Namely, the time reported
back doesn't increase but goes back and forth.
The culprit was obvious: the delta is stored to the result (cur_time =
delta), instead of adding the delta (cur_time += delta)!
Let's fix it.
Fixes: 3915bf294652 ('ALSA: seq_timer: use monotonic times internally')
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=177571
Reported-by: Yves Guillemot <yc.guillemot@wanadoo.fr>
Cc: <stable@vger.kernel.org> # v4.8+
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
ASRock B150M Pro4/D3 mobo with ALC892 codec doesn't seem to provide
proper pins for the surround outputs, hence we need to specify the
pincfgs manually with a couple of other corrections.
Reported-and-tested-by: Benjamin Valentin <benpicco@googlemail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
I rand into a new build error with SND_MMP_SOC_BROWNSTONE:
warning: (SND_MMP_SOC_BROWNSTONE && SND_SOC_SAMSUNG_SMDK_WM8994 && SND_SOC_SMDK_WM8994_PCM && SND_SOC_LITTLEMILL) selects MFD_WM8994 which has unmet direct dependencies (HAS_IOMEM && I2C)
drivers/mfd/wm8994-core.c:688:1: error: data definition has no type or storage class [-Werror]
drivers/mfd/wm8994-core.c:688:1: error: type defaults to 'int' in declaration of 'module_i2c_driver' [-Werror=implicit-int]
I don't see why this never showed up before, as the dependency seems to
have been missing since the symbol was first introduced several years
ago. This adds a dependency like the other drivers have.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
