- 01 Mar, 2016 1 commit
-
-
Dennis Kadioglu authored
Plantronics DA45 does not support reading the sample rate which leads to many lines of "cannot get freq at ep 0x4" and "cannot get freq at ep 0x84". This patch adds the USB ID of the DA45 to quirks.c and avoids those error messages. Signed-off-by: Dennis Kadioglu <denk@post.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
- 29 Feb, 2016 3 commits
-
-
Takashi Iwai authored
snd-hdsp driver accesses enum item values (int) instead of boolean values (long) wrongly for some ctl elements. This patch fixes them. Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
HDSPM driver contains a code issuing zero-division potentially in system sample rate ctl code. This patch fixes it by not processing a zero or invalid rate value as a divisor, as well as excluding the invalid value to be passed via the given ctl element. Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
snd-hdspm driver accesses enum item values (int) instead of boolean values (long) wrongly for some ctl elements. This patch fixes them. Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
- 28 Feb, 2016 6 commits
-
-
Takashi Iwai authored
X32 ABI takes the 64bit timespec, thus the timer user status ioctl becomes incompatible with IA32. This results in NOTTY error when the ioctl is issued. Meanwhile, this struct in X32 is essentially identical with the one in X86-64, so we can just bypassing to the existing code for this specific compat ioctl. Cc: <stable@vger.kernel.org> # v3.4+ Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
The timer user status compat ioctl returned the bogus struct used for 64bit architectures instead of the 32bit one. This patch addresses it to return the proper struct. Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
Like the previous fixes for ctl and PCM, we need a fix for incompatible X32 ABI regarding the rawmidi: namely, struct snd_rawmidi_status has the timespec, and the size and the alignment on X32 differ from IA32. This patch fixes the incompatible ioctl for X32. Cc: <stable@vger.kernel.org> # v3.4+ Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
Instead of open-coding, use the existing helper to copy a 32bit timespec from/to 64bit. Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
X32 ABI uses the 64bit timespec in addition to 64bit alignment of 64bit values. This leads to incompatibilities in some PCM ioctls involved with snd_pcm_channel_info, snd_pcm_status and snd_pcm_sync_ptr structs. Fix the PCM compat ABI for these ioctls like the previous commit for ctl API. Reported-by: Steven Newbury <steve@snewbury.org.uk> Cc: <stable@vger.kernel.org> # v3.4+ Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
The X32 ABI takes the same alignment like x86-64, and this may result in the incompatible struct size from ia32. Unfortunately, we hit this in some control ABI: struct snd_ctl_elem_value differs between them due to the position of 64bit variable array. This ends up with the unknown ioctl (ENOTTY) error. The fix is to add the compat entries for the new aligned struct. Reported-and-tested-by: Steven Newbury <steve@snewbury.org.uk> Cc: <stable@vger.kernel.org> # v3.4+ Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
- 26 Feb, 2016 1 commit
-
-
Takashi Iwai authored
Currently the interrupt handler of HD-audio driver assumes that no irq update is needed while processing the irq. But in reality, it has been confirmed that the HW irq is issued even during the irq handling. Since we clear the irq status at the beginning, process the interrupt, then exits from the handler, the lately issued interrupt is left untouched without being properly processed. This patch changes the interrupt handler code to loop over the check-and-process. The handler tries repeatedly as long as the IRQ status are turned on, and either stream or CORB/RIRB is handled. For checking the stream handling, snd_hdac_bus_handle_stream_irq() returns a value indicating the stream indices bits. Other than that, the change is only in the irq handler itself. Reported-by: Libin Yang <libin.yang@linux.intel.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
- 25 Feb, 2016 3 commits
-
-
Takashi Iwai authored
HP EliteBook 755 G2 with ALC3228 (ALC280) codec [103c:221c] requires the known fixup (ALC269_FIXUP_HEADSET_MIC) for making the headset mic working. Also, it suffers from the loopback noise problem, so we should disable aamix path as well. Reported-by: Derick Eddington <derick.eddington@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
David Henningsson authored
On one of the machines we enable, we found that the actual speaker volume did not always correspond to the volume set in alsamixer. This patch fixes that problem. This patch was orginally written by Kailang @ Realtek, I've rebased it to fit sound git master. Cc: stable@vger.kernel.org BugLink: https://bugs.launchpad.net/bugs/1549660Co-Authored-By: Kailang <kailang@realtek.com> Signed-off-by: David Henningsson <david.henningsson@canonical.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Kai-Heng Feng authored
After login to the desktop on Dell Inspiron 3162, there's a very loud background noise comes from the builtin speaker. The noise does not go away even if the speaker is muted. The noise disappears after using the aamix fixup. Codec: Realtek ALC3234 Address: 0 AFG Function Id: 0x1 (unsol 1) Vendor Id: 0x10ec0255 Subsystem Id: 0x10280725 Revision Id: 0x100002 No Modem Function Group found BugLink: http://bugs.launchpad.net/bugs/1549620Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
- 22 Feb, 2016 1 commit
-
-
Takashi Iwai authored
Some Skylake machines show the codec probe errors in certain situations, e.g. HP Z240 desktop fails to probe the onboard Realtek codec at reloading the snd-hda-intel module like: snd_hda_intel 0000:00:1f.3: spurious response 0x200:0x2, last cmd=0x000000 snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to polling mode: lastcmd=0x000f0000 snd_hda_intel 0000:00:1f.3: No response from codec, disabling MSI: last cmd=0x000f0000 snd_hda_intel 0000:00:1f.3: Codec #0 probe error; disabling it... hdaudio hdaudioC0D2: no AFG or MFG node found snd_hda_intel 0000:00:1f.3: no codecs initialized Also, HP G470 G3 suffers from the similar problem, as reported in bugzilla below. On this machine, the codec probe error appears even at a fresh boot. As Libin suggested, the same workaround used for Broxton in the commit [6639484d: ALSA: hda - disable dynamic clock gating on Broxton before reset] can be applied for Skylake in order to fix this problem. The Intel HW team also confirmed that this is needed for SKL. This patch makes the workaround applied to both SKL and BXT platforms. The referred macros are moved and one superfluous macro (IS_BROXTON()) is another one (IS_BXT()) as well. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=112731Suggested-by: Libin Yang <libin.yang@linux.intel.com> Cc: <stable@vger.kernel.org> # v4.4+ Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
- 18 Feb, 2016 1 commit
-
-
Takashi Iwai authored
A non-atomic PCM stream may take snd_pcm_link_rwsem rw semaphore twice in the same code path, e.g. one in snd_pcm_action_nonatomic() and another in snd_pcm_stream_lock(). Usually this is OK, but when a write lock is issued between these two read locks, the problem happens: the write lock is blocked due to the first reade lock, and the second read lock is also blocked by the write lock. This eventually deadlocks. The reason is the way rwsem manages waiters; it's queued like FIFO, so even if the writer itself doesn't take the lock yet, it blocks all the waiters (including reads) queued after it. As a workaround, in this patch, we replace the standard down_write() with an spinning loop. This is far from optimal, but it's good enough, as the spinning time is supposed to be relatively short for normal PCM operations, and the code paths requiring the write lock aren't called so often. Reported-by: Vinod Koul <vinod.koul@intel.com> Tested-by: Ramesh Babu <ramesh.babu@intel.com> Cc: <stable@vger.kernel.org> # v3.18+ Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
- 16 Feb, 2016 1 commit
-
-
Takashi Iwai authored
The commit [7f0973e9: ALSA: seq: Fix lockdep warnings due to double mutex locks] split the management of two linked lists (source and destination) into two individual calls for avoiding the AB/BA deadlock. However, this may leave the possible double deletion of one of two lists when the counterpart is being deleted concurrently. It ends up with a list corruption, as revealed by syzkaller fuzzer. This patch fixes it by checking the list emptiness and skipping the deletion and the following process. BugLink: http://lkml.kernel.org/r/CACT4Y+bay9qsrz6dQu31EcGaH9XwfW7o3oBzSQUG9fMszoh=Sg@mail.gmail.com Fixes: 7f0973e9 ('ALSA: seq: Fix lockdep warnings due to 'double mutex locks) Reported-by: Dmitry Vyukov <dvyukov@google.com> Tested-by: Dmitry Vyukov <dvyukov@google.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
- 15 Feb, 2016 2 commits
-
-
Takashi Iwai authored
The commit [991f86d7: ALSA: hda - Flush the pending probe work at remove] introduced the sync of async probe work at remove for fixing the race. However, this may lead to another hangup when the module removal is performed quickly before starting the probe work, because it issues flush_work() and it's blocked forever. The workaround is to use cancel_work_sync() instead of flush_work() there. Fixes: 991f86d7 ('ALSA: hda - Flush the pending probe work at remove') Cc: <stable@vger.kernel.org> # v3.17+ Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
When multiple concurrent writes happen on the ALSA sequencer device right after the open, it may try to allocate vmalloc buffer for each write and leak some of them. It's because the presence check and the assignment of the buffer is done outside the spinlock for the pool. The fix is to move the check and the assignment into the spinlock. (The current implementation is suboptimal, as there can be multiple unnecessary vmallocs because the allocation is done before the check in the spinlock. But the pool size is already checked beforehand, so this isn't a big problem; that is, the only possible path is the multiple writes before any pool assignment, and practically seen, the current coverage should be "good enough".) The issue was triggered by syzkaller fuzzer. BugLink: http://lkml.kernel.org/r/CACT4Y+bSzazpXNvtAr=WXaL8hptqjHwqEyFA+VN2AWEx=aurkg@mail.gmail.comReported-by: Dmitry Vyukov <dvyukov@google.com> Tested-by: Dmitry Vyukov <dvyukov@google.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
- 13 Feb, 2016 1 commit
-
-
Andrey Konovalov authored
The 'umidi' object will be free'd on the error path by snd_usbmidi_free() when tearing down the rawmidi interface. So we shouldn't try to free it in snd_usbmidi_create() after having registered the rawmidi interface. Found by KASAN. Signed-off-by: Andrey Konovalov <andreyknvl@gmail.com> Acked-by: Clemens Ladisch <clemens@ladisch.de> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
- 12 Feb, 2016 1 commit
-
-
Takashi Iwai authored
Merge tag 'asoc-fix-v4.5-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v4.5 A rather large batch of fixes here, almost all in the Intel driver. The changes that got merged in this merge window for Skylake were rather large and as well as issues that you'd expect in a large block of new code there were some problems created for older processors which needed fixing up. Things are largely settling down now hopefully.
-
- 10 Feb, 2016 9 commits
-
-
Mark Brown authored
Merge remote-tracking branches 'asoc/fix/rt5659', 'asoc/fix/sigmadsp', 'asoc/fix/simple', 'asoc/fix/wm5110' and 'asoc/fix/wm8960' into asoc-linus
-
Mark Brown authored
Merge remote-tracking branches 'asoc/fix/imx-spdif', 'asoc/fix/mtk', 'asoc/fix/mxs-saif', 'asoc/fix/qcom' and 'asoc/fix/rt286' into asoc-linus
-
Mark Brown authored
Merge remote-tracking branches 'asoc/fix/amd', 'asoc/fix/arizona', 'asoc/fix/dpcm', 'asoc/fix/dwc', 'asoc/fix/fsl' and 'asoc/fix/fsl-ssi' into asoc-linus
-
Mark Brown authored
-
Mark Brown authored
-
Mark Brown authored
-
Mark Brown authored
-
Richard Fitzgerald authored
When the FLL is in pseudo-fractional mode there is an additional limit on fref based on the fratio, to prevent aliasing around the Nyquist frequency. If fref exceeds this limit the refclk divider must be increased and the calculation tried again until a suitable combination of fref and fratio is found or we have to fall back to integer mode. This patch also adds some debug log prints around this code. Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
Pascal Huerst authored
Forwarding the return value of i2c_master_send, leads to errors later on, since i2c_master_send returns the number of bytes transmittet. Check for ret < 0 instead and return 0 otherwise. Signed-off-by: Pascal Huerst <pascal.huerst@gmail.com> Acked-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
-
- 09 Feb, 2016 5 commits
-
-
Takashi Iwai authored
-
Takashi Iwai authored
snd_timer_user_read() has a potential race among parallel reads, as qhead and qused are updated outside the critical section due to copy_to_user() calls. Move them into the critical section, and also sanitize the relevant code a bit. Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Geert Uytterhoeven authored
sound/firewire/digi00x/amdtp-dot.c:67: warning: type qualifiers ignored on function return type Drop the bogus "const" type qualifier on the return type of dot_scrt() to fix this. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
The hda_jack_tbl entries are managed by snd_array for allowing multiple jacks. It's good per se, but the problem is that struct hda_jack_callback keeps the hda_jack_tbl pointer. Since snd_array doesn't preserve each pointer at resizing the array, we can't keep the original pointer but have to deduce the pointer at each time via snd_array_entry() instead. Actually, this resulted in the deference to the wrong pointer on codecs that have many pins such as CS4208. This patch replaces the pointer to the NID value as the search key. As an unexpected good side effect, this even simplifies the code, as only NID is needed in most cases. Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
A slave timer element also unlinks at snd_timer_stop() but it takes only slave_active_lock. When a slave is assigned to a master, however, this may become a race against the master's interrupt handling, eventually resulting in a list corruption. The actual bug could be seen with a syzkaller fuzzer test case in BugLink below. As a fix, we need to take timeri->timer->lock when timer isn't NULL, i.e. assigned to a master, while the assignment to a master itself is protected by slave_active_lock. BugLink: http://lkml.kernel.org/r/CACT4Y+Y_Bm+7epAb=8Wi=AaWd+DYS7qawX52qxdCfOfY49vozQ@mail.gmail.com Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
- 08 Feb, 2016 5 commits
-
-
Takashi Iwai authored
In snd_timer_notify1(), the wrong timer instance was passed for slave ccallback function. This leads to the access to the wrong data when an incompatible master is handled (e.g. the master is the sequencer timer and the slave is a user timer), as spotted by syzkaller fuzzer. This patch fixes that wrong assignment. BugLink: http://lkml.kernel.org/r/CACT4Y+Y_Bm+7epAb=8Wi=AaWd+DYS7qawX52qxdCfOfY49vozQ@mail.gmail.comReported-by: Dmitry Vyukov <dvyukov@google.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Vinod Koul authored
The match module lacked module license and description, so add it Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
Pierre-Louis Bossart authored
DPCM driver is recommended for BYT, CHT based platforms, so if CONFIG_SND_SST_IPC_ACPI is selected then don't compile the BYT Device IDs in common ACPI driver to avoid probe conflicts. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Acked-by: Jie Yang <yang.jie@intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
Vinod Koul authored
The ACPI match module is common to all three drivers, HSW, SKL and Atom-DPCM driver. But Atom-DPCM driver does not use common sst code so we cannot include the common SST module in Atom-DPCM driver. So the solution is to have a independent sst-match-acpi module which helps in matching for all the three drivers. Now all driver can be inbuilt in a single image This patch really fixes the regression introduced by the commit 95f09801 ("ASoC: Intel: Move apci find machine routines") Acked-by: Jie Yang <yang.jie@intel.com> Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
Vinod Koul authored
This reverts commit dc901a35 ("ASoC: Intel: fix ACPI probe regression with Atom DPCM driver") as the fix prevented the probe on HSW/BDW if Atom-DPCM was selected Acked-by: Jie Yang <yang.jie@intel.com> Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-