- 18 May, 2018 2 commits
-
-
Takashi Iwai authored
There multiple open-codes to get the hardware timer resolution. Make a local helper function snd_timer_hw_resolution() and call it from all relevant places. There is no functional change by this, just a preliminary work for the following timer resolution hardening patch. Signed-off-by:Takashi Iwai <tiwai@suse.de>
-
Ben Hutchings authored
Commit f65e0d29 ("ALSA: timer: Call notifier in the same spinlock") combined the start/continue and stop/pause functions, and in doing so changed the event code for the pause case to SNDRV_TIMER_EVENT_CONTINUE. Change it back to SNDRV_TIMER_EVENT_PAUSE. Fixes: f65e0d29 ("ALSA: timer: Call notifier in the same spinlock") Signed-off-by:
Ben Hutchings <ben.hutchings@codethink.co.uk> Cc: stable@vger.kernel.org Signed-off-by:
-
- 15 May, 2018 1 commit
-
-
Jorge Sanjuan authored
bmAtributes offset doesn't exist in the UAC3 CS_EP descriptor. Hence, checking for pitch control as if it was UAC2 doesn't make any sense. Use the defined UAC3 offsets instead. Fixes: 9a2fe9b8 ("ALSA: usb: initial USB Audio Device Class 3.0 support") Signed-off-by:
Jorge Sanjuan <jorge.sanjuan@codethink.co.uk> Reviewed-by:
Ruslan Bilovol <ruslan.bilovol@gmail.com> Signed-off-by:
-
- 13 May, 2018 4 commits
-
-
Jeremy Soller authored
This adds support for the P950ER, which has the same required fixup as the P950HR, but has a different PCI ID. Signed-off-by:
Jeremy Soller <jeremy@system76.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Federico Cuello authored
Currently it's not possible to set volume lower than 26% (it just mutes). Also fixes this warning: Warning! Unlikely big volume range (=9472), cval->res is probably wrong. [13] FU [PCM Playback Volume] ch = 2, val = -9473/-1/1 , and volume works fine for full range. Signed-off-by:
Federico Cuello <fedux@fedux.com.ar> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Hans de Goede authored
Power-saving is causing loud plops on the Lenovo C50 All in one, add it to the blacklist. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1572975Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Wenwen Wang authored
In snd_ctl_elem_add_compat(), the fields of the struct 'data' need to be copied from the corresponding fields of the struct 'data32' in userspace. This is achieved by invoking copy_from_user() and get_user() functions. The problem here is that the 'type' field is copied twice. One is by copy_from_user() and one is by get_user(). Given that the 'type' field is not used between the two copies, the second copy is *completely* redundant and should be removed for better performance and cleanup. Also, these two copies can cause inconsistent data: as the struct 'data32' resides in userspace and a malicious userspace process can race to change the 'type' field between the two copies to cause inconsistent data. Depending on how the data is used in the future, such an inconsistency may cause potential security risks. For above reasons, we should take out the second copy. Signed-off-by:
Wenwen Wang <wang6495@umn.edu> Cc: <stable@vger.kernel.org> Signed-off-by:
-
- 02 May, 2018 1 commit
-
-
Takashi Iwai authored
Since snd_pcm_ioctl_xfern_compat() has no PCM state check, it may go further and hit the sanity check pcm_sanity_check() when the ioctl is called right after open. It may eventually spew a kernel warning, as triggered by syzbot, depending on kconfig. The lack of PCM state check there was just an oversight. Although it's no real crash, the spurious kernel warning is annoying, so let's add the proper check. Reported-by: syzbot+1dac3a4f6bc9c1c675d4@syzkaller.appspotmail.com Cc: <stable@vger.kernel.org> Signed-off-by:
-
- 30 Apr, 2018 1 commit
-
-
Takashi Iwai authored
Some control API callbacks in aloop driver are too lazy to take the loopback->cable_lock and it results in possible races of cable access while it's being freed. It eventually lead to a UAF, as reported by fuzzer recently. This patch covers such control API callbacks and add the proper mutex locks. Reported-by:
DaeRyong Jeong <threeearcat@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
- 29 Apr, 2018 1 commit
-
-
Takashi Sakamoto authored
At a commit f91c9d76 ('ALSA: firewire-lib: cache maximum length of payload to reduce function calls'), maximum size of payload for tx isochronous packet is cached to reduce the number of function calls. This cache was programmed to updated at a first callback of ohci1394 IR context. However, the maximum size is required to queueing packets before starting the isochronous context. As a result, the cached value is reused to queue packets in next time to starting the isochronous context. Then the cache is updated in a first callback of the isochronous context. This can cause kernel NULL pointer dereference in a below call graph: (sound/firewire/amdtp-stream.c) amdtp_stream_start() ->queue_in_packet() ->queue_packet() (drivers/firewire/core-iso.c) ->fw_iso_context_queue() ->struct fw_card_driver.queue_iso() (drivers/firewire/ohci.c) = ohci_queue_iso() ->queue_iso_packet_per_buffer() buffer->pages[page] The issued dereference occurs in a case that: - target unit supports different stream formats for sampling transmission frequency. - maximum length of payload for tx stream in a first trial is bigger than the length in a second trial. In this case, correct number of pages are allocated for DMA and the 'pages' array has enough elements, while index of the element is wrongly calculated according to the old value of length of payload in a call of 'queue_in_packet()'. Then it causes the issue. This commit fixes the critical bug. This affects all of drivers in ALSA firewire stack in Linux kernel v4.12 or later. [12665.302360] BUG: unable to handle kernel NULL pointer dereference at 0000000000000030 [12665.302415] IP: ohci_queue_iso+0x47c/0x800 [firewire_ohci] [12665.302439] PGD 0 [12665.302440] P4D 0 [12665.302450] [12665.302470] Oops: 0000 [#1] SMP PTI [12665.302487] Modules linked in: ... [12665.303096] CPU: 1 PID: 12760 Comm: jackd Tainted: P OE 4.13.0-38-generic #43-Ubuntu [12665.303154] Hardware name: /DH77DF, BIOS KCH7710H.86A.0069.2012.0224.1825 02/24/2012 [12665.303215] task: ffff9ce87da2ae80 task.stack: ffffb5b8823d0000 [12665.303258] RIP: 0010:ohci_queue_iso+0x47c/0x800 [firewire_ohci] [12665.303301] RSP: 0018:ffffb5b8823d3ab8 EFLAGS: 00010086 [12665.303337] RAX: ffff9ce4f4876930 RBX: 0000000000000008 RCX: ffff9ce88a3955e0 [12665.303384] RDX: 0000000000000000 RSI: 0000000034877f00 RDI: 0000000000000000 [12665.303427] RBP: ffffb5b8823d3b68 R08: ffff9ce8ccb390a0 R09: ffff9ce877639ab0 [12665.303475] R10: 0000000000000108 R11: 0000000000000000 R12: 0000000000000003 [12665.303513] R13: 0000000000000000 R14: ffff9ce4f4876950 R15: 0000000000000000 [12665.303554] FS: 00007f2ec467f8c0(0000) GS:ffff9ce8df280000(0000) knlGS:0000000000000000 [12665.303600] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [12665.303633] CR2: 0000000000000030 CR3: 00000002dcf90004 CR4: 00000000000606e0 [12665.303674] Call Trace: [12665.303698] fw_iso_context_queue+0x18/0x20 [firewire_core] [12665.303735] queue_packet+0x88/0xe0 [snd_firewire_lib] [12665.303770] amdtp_stream_start+0x19b/0x270 [snd_firewire_lib] [12665.303811] start_streams+0x276/0x3c0 [snd_dice] [12665.303840] snd_dice_stream_start_duplex+0x1bf/0x480 [snd_dice] [12665.303882] ? vma_gap_callbacks_rotate+0x1e/0x30 [12665.303914] ? __rb_insert_augmented+0xab/0x240 [12665.303936] capture_prepare+0x3c/0x70 [snd_dice] [12665.303961] snd_pcm_do_prepare+0x1d/0x30 [snd_pcm] [12665.303985] snd_pcm_action_single+0x3b/0x90 [snd_pcm] [12665.304009] snd_pcm_action_nonatomic+0x68/0x70 [snd_pcm] [12665.304035] snd_pcm_prepare+0x68/0x90 [snd_pcm] [12665.304058] snd_pcm_common_ioctl1+0x4c0/0x940 [snd_pcm] [12665.304083] snd_pcm_capture_ioctl1+0x19b/0x250 [snd_pcm] [12665.304108] snd_pcm_capture_ioctl+0x27/0x40 [snd_pcm] [12665.304131] do_vfs_ioctl+0xa8/0x630 [12665.304148] ? entry_SYSCALL_64_after_hwframe+0xe9/0x139 [12665.304172] ? entry_SYSCALL_64_after_hwframe+0xe2/0x139 [12665.304195] ? entry_SYSCALL_64_after_hwframe+0xdb/0x139 [12665.304218] ? entry_SYSCALL_64_after_hwframe+0xd4/0x139 [12665.304242] ? entry_SYSCALL_64_after_hwframe+0xcd/0x139 [12665.304265] ? entry_SYSCALL_64_after_hwframe+0xc6/0x139 [12665.304288] ? entry_SYSCALL_64_after_hwframe+0xbf/0x139 [12665.304312] ? entry_SYSCALL_64_after_hwframe+0xb8/0x139 [12665.304335] ? entry_SYSCALL_64_after_hwframe+0xb1/0x139 [12665.304358] SyS_ioctl+0x79/0x90 [12665.304374] ? entry_SYSCALL_64_after_hwframe+0x72/0x139 [12665.304397] entry_SYSCALL_64_fastpath+0x24/0xab [12665.304417] RIP: 0033:0x7f2ec3750ef7 [12665.304433] RSP: 002b:00007fff99e31388 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [12665.304465] RAX: ffffffffffffffda RBX: 00007fff99e312f0 RCX: 00007f2ec3750ef7 [12665.304494] RDX: 0000000000000000 RSI: 0000000000004140 RDI: 0000000000000007 [12665.304522] RBP: 0000556ebc63fd60 R08: 0000556ebc640560 R09: 0000000000000000 [12665.304553] R10: 0000000000000001 R11: 0000000000000246 R12: 0000556ebc63fcf0 [12665.304584] R13: 0000000000000000 R14: 0000000000000007 R15: 0000000000000000 [12665.304612] Code: 01 00 00 44 89 eb 45 31 ed 45 31 db 66 41 89 1e 66 41 89 5e 0c 66 45 89 5e 0e 49 8b 49 08 49 63 d4 4d 85 c0 49 63 ff 48 8b 14 d1 <48> 8b 72 30 41 8d 14 37 41 89 56 04 48 63 d3 0f 84 ce 00 00 00 [12665.304713] RIP: ohci_queue_iso+0x47c/0x800 [firewire_ohci] RSP: ffffb5b8823d3ab8 [12665.304743] CR2: 0000000000000030 [12665.317701] ---[ end trace 9d55b056dd52a19f ]--- Fixes: f91c9d76 ('ALSA: firewire-lib: cache maximum length of payload to reduce function calls') Cc: <stable@vger.kernel.org> # v4.12+ Signed-off-by:
Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by:
-
- 27 Apr, 2018 2 commits
-
-
Takashi Iwai authored
The sequencer virmidi code has an open race at its output trigger callback: namely, virmidi keeps only one event packet for processing while it doesn't protect for concurrent output trigger calls. snd_virmidi_output_trigger() tries to process the previously unfinished event before starting encoding the given MIDI stream, but this is done without any lock. Meanwhile, if another rawmidi stream starts the output trigger, this proceeds further, and overwrites the event package that is being processed in another thread. This eventually corrupts and may lead to the invalid memory access if the event type is like SYSEX. The fix is just to move the spinlock to cover both the pending event and the new stream. The bug was spotted by a new fuzzer, RaceFuzzer. BugLink: http://lkml.kernel.org/r/20180426045223.GA15307@dragonet.kaist.ac.krReported-by:
-
Takashi Iwai authored
The commit c469652b ("ALSA: hda - Use IS_REACHABLE() for dependency on input") simplified the dependencies with IS_REACHABLE() macro, but it broke due to its incorrect usage: it should have been IS_REACHABLE(CONFIG_INPUT) instead of IS_REACHABLE(INPUT). Fixes: c469652b ("ALSA: hda - Use IS_REACHABLE() for dependency on input") Cc: <stable@vger.kernel.org> Signed-off-by:
-
- 26 Apr, 2018 1 commit
-
-
Takashi Sakamoto authored
In error path of snd_dice_stream_init_duplex(), stream data for incoming packet can be left to be initialized. This commit fixes it. Fixes: 436b5abe ('ALSA: dice: handle whole available isochronous streams') Cc: <stable@vger.kernel.org> # v4.6+ Signed-off-by:
-
- 25 Apr, 2018 15 commits
-
-
Takashi Iwai authored
When CONFIG_SND_DYNAMIC_MINORS isn't set, there are only limited number of devices available, and HD-audio, especially with HDMI/DP codec, will fail to create more than two devices. The driver warns about the lack of such devices and skips the PCM device creations, but the HDMI driver still tries to create the corresponding JACK, SPDIF and ELD controls even for the non-existing PCM substreams. This results in confusion on user-space, and even may break the operation. Similarly, Intel HDMI/DP codec builds the ELD notification from i915 graphics driver, and this may be broken if a notification is sent for the non-existing PCM stream. This patch adds the check of the existence of the assigned PCM substream in the both scenarios above, and skips the further operation if the PCM substream is not assigned. Fixes: 9152085d ("ALSA: hda - add DP MST audio support") Cc: <stable@vger.kernel.org> Signed-off-by:
-
Takashi Iwai authored
Merge tag 'asoc-fix-4.17-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v4.17 A small batch of fixes collected since the merge window, none of which are particularly large or remarkable. They've all been cooking in -next for a while.
-
Kailang Yang authored
On this Lenovo ThinkCentre machine. There are two front mics, we change the location for one of them. Relation: f33f79f3 ("ALSA: hda/realtek - change the location for one of two front microphones") Signed-off-by:
Kailang Yang <kailang@realtek.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Takashi Iwai authored
As recently Smatch suggested, one place in RME9652 driver may expand the array directly from the user-space value with speculation: sound/pci/rme9652/rme9652.c:2074 snd_rme9652_channel_info() warn: potential spectre issue 'rme9652->channel_map' (local cap) This patch puts array_index_nospec() for hardening against it. BugLink: https://marc.info/?l=linux-kernel&m=152411496503418&w=2Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Takashi Iwai authored
As recently Smatch suggested, a couple of places in HDSP MADI driver may expand the array directly from the user-space value with speculation: sound/pci/rme9652/hdspm.c:5717 snd_hdspm_channel_info() warn: potential spectre issue 'hdspm->channel_map_out' (local cap) sound/pci/rme9652/hdspm.c:5734 snd_hdspm_channel_info() warn: potential spectre issue 'hdspm->channel_map_in' (local cap) This patch puts array_index_nospec() for hardening against them. BugLink: https://marc.info/?l=linux-kernel&m=152411496503418&w=2Reported-by:
-
Takashi Iwai authored
As recently Smatch suggested, a couple of places in ASIHPI driver may expand the array directly from the user-space value with speculation: sound/pci/asihpi/hpimsginit.c:70 hpi_init_response() warn: potential spectre issue 'res_size' (local cap) sound/pci/asihpi/hpioctl.c:189 asihpi_hpi_ioctl() warn: potential spectre issue 'adapters' This patch puts array_index_nospec() for hardening against them. BugLink: https://marc.info/?l=linux-kernel&m=152411496503418&w=2Reported-by:
-
Takashi Iwai authored
As recently Smatch suggested, one place in OPL3 driver may expand the array directly from the user-space value with speculation: sound/drivers/opl3/opl3_synth.c:476 snd_opl3_set_voice() warn: potential spectre issue 'snd_opl3_regmap' This patch puts array_index_nospec() for hardening against it. BugLink: https://marc.info/?l=linux-kernel&m=152411496503418&w=2Reported-by:
-
Takashi Iwai authored
As recently Smatch suggested, one place in HD-audio hwdep ioctl codes may expand the array directly from the user-space value with speculation: sound/pci/hda/hda_local.h:467 get_wcaps() warn: potential spectre issue 'codec->wcaps' As get_wcaps() itself is a fairly frequently called inline function, and there is only one single call with a user-space value, we replace only the latter one to open-code locally with array_index_nospec() hardening in this patch. BugLink: https://marc.info/?l=linux-kernel&m=152411496503418&w=2Reported-by:
-
Takashi Iwai authored
As recently Smatch suggested, a few places in ALSA control core codes may expand the array directly from the user-space value with speculation: sound/core/control.c:1003 snd_ctl_elem_lock() warn: potential spectre issue 'kctl->vd' sound/core/control.c:1031 snd_ctl_elem_unlock() warn: potential spectre issue 'kctl->vd' sound/core/control.c:844 snd_ctl_elem_info() warn: potential spectre issue 'kctl->vd' sound/core/control.c:891 snd_ctl_elem_read() warn: potential spectre issue 'kctl->vd' sound/core/control.c:939 snd_ctl_elem_write() warn: potential spectre issue 'kctl->vd' Although all these seem doing only the first load without further reference, we may want to stay in a safer side, so hardening with array_index_nospec() would still make sense. In this patch, we put array_index_nospec() to the common snd_ctl_get_ioff*() helpers instead of each caller. These helpers are also referred from some drivers, too, and basically all usages are to calculate the array index from the user-space value, hence it's better to cover there. BugLink: https://marc.info/?l=linux-kernel&m=152411496503418&w=2Reported-by:
-
Takashi Iwai authored
As Smatch recently suggested, a few places in OSS sequencer codes may expand the array directly from the user-space value with speculation, namely there are a significant amount of references to either info->ch[] or dp->synths[] array: sound/core/seq/oss/seq_oss_event.c:315 note_on_event() warn: potential spectre issue 'info->ch' (local cap) sound/core/seq/oss/seq_oss_event.c:362 note_off_event() warn: potential spectre issue 'info->ch' (local cap) sound/core/seq/oss/seq_oss_synth.c:470 snd_seq_oss_synth_load_patch() warn: potential spectre issue 'dp->synths' (local cap) sound/core/seq/oss/seq_oss_event.c:293 note_on_event() warn: potential spectre issue 'dp->synths' sound/core/seq/oss/seq_oss_event.c:353 note_off_event() warn: potential spectre issue 'dp->synths' sound/core/seq/oss/seq_oss_synth.c:506 snd_seq_oss_synth_sysex() warn: potential spectre issue 'dp->synths' sound/core/seq/oss/seq_oss_synth.c:580 snd_seq_oss_synth_ioctl() warn: potential spectre issue 'dp->synths' Although all these seem doing only the first load without further reference, we may want to stay in a safer side, so hardening with array_index_nospec() would still make sense. We may put array_index_nospec() at each place, but here we take a different approach: - For dp->synths[], change the helpers to retrieve seq_oss_synthinfo pointer directly instead of the array expansion at each place - For info->ch[], harden in a normal way, as there are only a couple of places As a result, the existing helper, snd_seq_oss_synth_is_valid() is replaced with snd_seq_oss_synth_info(). Also, we cover MIDI device where a similar array expansion is done, too, although it wasn't reported by Smatch. BugLink: https://marc.info/?l=linux-kernel&m=152411496503418&w=2Reported-by:
-
Takashi Iwai authored
When get_synthdev() is called for a MIDI device, it returns the fixed midi_synth_dev without the use refcounting. OTOH, the caller is supposed to unreference unconditionally after the usage, so this would lead to unbalanced refcount. This patch corrects the behavior and keep up the refcount balance also for the MIDI synth device. Cc: <stable@vger.kernel.org> Signed-off-by: -
Kailang Yang authored
Add ALC255 its own depop functions for alc_init and alc_shutup. Assign it to ALC256 usage. Signed-off-by:
-
Kailang Yang authored
Fill COEF to change EAPD to verb control. Assigned codec type. This is an additional fix over 92f974df ("ALSA: hda/realtek - New vendor ID for ALC233"). [ More notes: according to Kailang, the chip is 10ec:0235 bonding for ALC233b, which is equivalent with ALC255. It's only used for Lenovo. The chip needs no alc_process_coef_fw() for headset unlike ALC255. ] Signed-off-by:
-
Souptick Joarder authored
Use new return type vm_fault_t for fault handler. For now, this is just documenting that the function returns a VM_FAULT value rather than an errno. Once all instances are converted, vm_fault_t will become a distinct type. Commit 1c8f4220 ("mm: change return type to vm_fault_t") Signed-off-by:
Souptick Joarder <jrdr.linux@gmail.com> Reviewed-by:
Matthew Wilcox <mawilcox@microsoft.com> Signed-off-by:
-
Souptick Joarder authored
Use new return type vm_fault_t for fault handler. For now, this is just documenting that the function returns a VM_FAULT value rather than an errno. Once all instances are converted, vm_fault_t will become a distinct type. Commit 1c8f4220 ("mm: change return type to vm_fault_t") Signed-off-by:
-
- 24 Apr, 2018 4 commits
-
-
Michael Drake authored
The channel mapping is defined by bChRelationship, not bChPurpose. Fixes: 9a2fe9b8 ("ALSA: usb: initial USB Audio Device Class 3.0 support") Reviewed-by:
Michael Drake <michael.drake@codethink.co.uk> Signed-off-by:
-
Takashi Sakamoto authored
OUI for TC Electronic is 0x000166, for TC GROUP A/S. 0x001486 is for Echo Digital Audio Corporation. Fixes: 7cafc65b ('ALSA: dice: force to add two pcm devices for listed models') Cc: <stable@vger.kernel.org> # v4.6+ Reference: http://standards-oui.ieee.org/oui/oui.txtSigned-off-by:
-
Takashi Iwai authored
The Dell Dock USB-audio device with 0bda:4014 is behaving notoriously bad, and we have already applied some workaround to avoid the firmware hiccup. Yet we still need to skip one thing, the Extension Unit at ID 4, which doesn't react correctly to the mixer ctl access. Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1090658 Cc: <stable@vger.kernel.org> Signed-off-by:
-
Takashi Iwai authored
The UAC2 jack detection support introduced the bmControls checks in a couple of places, but they forgot the endian conversion; the bmControls of UAC2 terminal descriptor is __le16, not a byte like in UAC1. Fixes: 5a222e84 ("ALSA: usb-audio: UAC2 jack detection") Tested-by:
Andrew Chant <achant@google.com> Signed-off-by:
-
- 23 Apr, 2018 6 commits
-
-
Takashi Iwai authored
The recent code refactoring made the argument for some helper functions to be the explicit UAC_CS_* and UAC2_CS_* value instead of 0-based offset. However, there was one place left forgotten, and it caused a regression on some devices appearing as the inconsistent mixer setup. This patch corrects the forgotten conversion. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=199449 Fixes: 21e9b3e9 ("ALSA: usb-audio: fix uac control query argument") Tested-by:
Nazar Mokrynskyi <nazar@mokrynskyi.com> Signed-off-by:
-
Takashi Iwai authored
There is one place missing __user annotation to the pointer used by the recent code refactoring. Reported by sparse. Fixes: 450296f3 ("ALSA: control: code refactoring TLV ioctl handler") Reviewed-by:
-
David Henningsson authored
It looks like a simple mistake that this struct member was forgotten. Audio_tstamp isn't used much, and on some archs (such as x86) this ioctl is not used by default, so that might be the reason why this has slipped for so long. Fixes: 4eeaaeae ("ALSA: core: add hooks for audio timestamps") Signed-off-by:
David Henningsson <diwic@ubuntu.com> Reviewed-by:
-
Jeffery Miller authored
The commit c2c86a97 ("ALSA: pcm: Remove set_fs() in PCM core code") changed SNDRV_PCM_IOCTL_DELAY to return an inconsistent error instead of a negative delay. Originally the call would succeed and return the negative delay. The Chromium OS Audio Server (CRAS) gets confused and hangs when the error is returned instead of the negative delay. Help CRAS avoid the issue by rolling back the behavior to return a negative delay instead of an error. Fixes: c2c86a97 ("ALSA: pcm: Remove set_fs() in PCM core code") Signed-off-by:
Jeffery Miller <jmiller@neverware.com> Cc: <stable@vger.kernel.org> # v4.13+ Signed-off-by:
-
Linus Torvalds authored
-
git://people.freedesktop.org/~airlied/linuxLinus Torvalds authored
Pull drm fixes from Dave Airlie: "Exynos, i915, vc4, amdgpu fixes. i915: - an oops fix - two race fixes - some gvt fixes amdgpu: - dark screen fix - clk/voltage fix - vega12 smu fix vc4: - memory leak fix exynos just drops some code" * tag 'drm-fixes-for-v4.17-rc2' of git://people.freedesktop.org/~airlied/linux: (23 commits) drm/amd/powerplay: header file interface to SMU update drm/amd/pp: Fix bug voltage can't be OD separately on VI drm/amd/display: Don't program bypass on linear regamma LUT drm/i915: Fix LSPCON TMDS output buffer enabling from low-power state drm/i915/audio: Fix audio detection issue on GLK drm/i915: Call i915_perf_fini() on init_hw error unwind drm/i915/bios: filter out invalid DDC pins from VBT child devices drm/i915/pmu: Inspect runtime PM state more carefully while estimating RC6 drm/i915: Do no use kfree() to free a kmem_cache_alloc() return value drm/exynos: exynos_drm_fb -> drm_framebuffer drm/exynos: Move dma_addr out of exynos_drm_fb drm/exynos: Move GEM BOs to drm_framebuffer drm: Fix HDCP downstream dev count read drm/vc4: Fix memory leak during BO teardown drm/i915/execlists: Clear user-active flag on preemption completion drm/i915/gvt: Add drm_format_mod update drm/i915/gvt: Disable primary/sprite/cursor plane at virtual display initialization drm/i915/gvt: Delete redundant error message in fb_decode.c drm/i915/gvt: Cancel dma map when resetting ggtt entries drm/i915/gvt: Missed to cancel dma map for ggtt entries ...
-
- 22 Apr, 2018 2 commits
-
-
git://people.freedesktop.org/~agd5f/linuxDave Airlie authored
- Fix a dark screen issue in DC - Fix clk/voltage dependency tracking for wattman - Update SMU interface for vega12 * 'drm-next-4.17' of git://people.freedesktop.org/~agd5f/linux: drm/amd/powerplay: header file interface to SMU update drm/amd/pp: Fix bug voltage can't be OD separately on VI drm/amd/display: Don't program bypass on linear regamma LUT
-
Dave Airlie authored
Merge tag 'exynos-drm-fixes-for-v4.17-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next Remove Exynos specific framebuffer structure and relevant functions. - it removes exynos_drm_fb structure which is a wrapper of drm_framebuffer and unnecessary two exynos specific callback functions, exynos_drm_destory() and exynos_drm_fb_create_handle() because we can reuse existing drm common callback ones instead. * tag 'exynos-drm-fixes-for-v4.17-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos: drm/exynos: exynos_drm_fb -> drm_framebuffer drm/exynos: Move dma_addr out of exynos_drm_fb drm/exynos: Move GEM BOs to drm_framebuffer drm/amdkfd: Deallocate SDMA queues correctly drm/amdkfd: Fix scratch memory with HWS enabled
-
