- 25 5月, 2018 1 次提交
-
-
由 Lukas Wunner 提交于
Before commit 3b5b899c ("ALSA: hda: Make use of core codec functions to sync power state"), hda_set_power_state() returned the response to the Get Power State verb, a 32-bit unsigned integer whose expected value is 0x233 after transitioning a codec to D3, and 0x0 after transitioning it to D0. The response value is significant because hda_codec_runtime_suspend() does not clear the codec's bit in the codec_powered bitmask unless the AC_PWRST_CLK_STOP_OK bit (0x200) is set in the response value. That in turn prevents the HDA controller from runtime suspending because azx_runtime_idle() checks that the codec_powered bitmask is zero. Since commit 3b5b899c, hda_set_power_state() only returns 0x0 or 0x1, thereby breaking runtime PM for any HDA controller. That's because an inline function introduced by the commit returns a bool instead of a 32-bit unsigned int. The change was likely erroneous and resulted from copying and pasting snd_hda_check_power_state(), which is immediately preceding the newly introduced inline function. Fix it. Link: https://bugs.freedesktop.org/show_bug.cgi?id=106597 Fixes: 3b5b899c ("ALSA: hda: Make use of core codec functions to sync power state") Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Abhijeet Kumar <abhijeet.kumar@intel.com> Reported-and-tested-by: NGunnar Krüger <taijian@posteo.de> Signed-off-by: NLukas Wunner <lukas@wunner.de> Acked-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 18 5月, 2018 1 次提交
-
-
由 Ben Hutchings 提交于
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: NBen Hutchings <ben.hutchings@codethink.co.uk> Cc: stable@vger.kernel.org Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 15 5月, 2018 1 次提交
-
-
由 Jorge Sanjuan 提交于
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: NJorge Sanjuan <jorge.sanjuan@codethink.co.uk> Reviewed-by: NRuslan Bilovol <ruslan.bilovol@gmail.com> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 14 5月, 2018 2 次提交
-
-
由 Jeremy Soller 提交于
This adds support for the P950ER, which has the same required fixup as the P950HR, but has a different PCI ID. Signed-off-by: NJeremy Soller <jeremy@system76.com> Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Federico Cuello 提交于
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: NFederico Cuello <fedux@fedux.com.ar> Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 13 5月, 2018 2 次提交
-
-
由 Hans de Goede 提交于
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: NHans de Goede <hdegoede@redhat.com> Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Wenwen Wang 提交于
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: NWenwen Wang <wang6495@umn.edu> Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 02 5月, 2018 1 次提交
-
-
由 Takashi Iwai 提交于
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: NTakashi Iwai <tiwai@suse.de>
-
- 30 4月, 2018 1 次提交
-
-
由 Takashi Iwai 提交于
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: NDaeRyong Jeong <threeearcat@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 29 4月, 2018 1 次提交
-
-
由 Takashi Sakamoto 提交于
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: NTakashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 27 4月, 2018 2 次提交
-
-
由 Takashi Iwai 提交于
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: NDaeRyong Jeong <threeearcat@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Takashi Iwai 提交于
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: NTakashi Iwai <tiwai@suse.de>
-
- 26 4月, 2018 1 次提交
-
-
由 Takashi Sakamoto 提交于
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: NTakashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 25 4月, 2018 16 次提交
-
-
由 Takashi Iwai 提交于
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: NTakashi Iwai <tiwai@suse.de>
-
由 Takashi Iwai 提交于
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 提交于
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: NKailang Yang <kailang@realtek.com> Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Takashi Iwai 提交于
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: NDan Carpenter <dan.carpenter@oracle.com> Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Takashi Iwai 提交于
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: NDan Carpenter <dan.carpenter@oracle.com> Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Takashi Iwai 提交于
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: NDan Carpenter <dan.carpenter@oracle.com> Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Takashi Iwai 提交于
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: NDan Carpenter <dan.carpenter@oracle.com> Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Takashi Iwai 提交于
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: NDan Carpenter <dan.carpenter@oracle.com> Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Takashi Iwai 提交于
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: NDan Carpenter <dan.carpenter@oracle.com> Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Takashi Iwai 提交于
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: NDan Carpenter <dan.carpenter@oracle.com> Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Takashi Iwai 提交于
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: NTakashi Iwai <tiwai@suse.de>
-
由 Kailang Yang 提交于
Add ALC255 its own depop functions for alc_init and alc_shutup. Assign it to ALC256 usage. Signed-off-by: NKailang Yang <kailang@realtek.com> Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Kailang Yang 提交于
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: NKailang Yang <kailang@realtek.com> Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Souptick Joarder 提交于
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: NSouptick Joarder <jrdr.linux@gmail.com> Reviewed-by: NMatthew Wilcox <mawilcox@microsoft.com> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Souptick Joarder 提交于
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: NSouptick Joarder <jrdr.linux@gmail.com> Reviewed-by: NMatthew Wilcox <mawilcox@microsoft.com> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Michael Drake 提交于
The channel mapping is defined by bChRelationship, not bChPurpose. Fixes: 9a2fe9b8 ("ALSA: usb: initial USB Audio Device Class 3.0 support") Reviewed-by: NRuslan Bilovol <ruslan.bilovol@gmail.com> Signed-off-by: NMichael Drake <michael.drake@codethink.co.uk> Signed-off-by: NJorge Sanjuan <jorge.sanjuan@codethink.co.uk> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 24 4月, 2018 3 次提交
-
-
由 Takashi Sakamoto 提交于
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: NTakashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Takashi Iwai 提交于
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: NTakashi Iwai <tiwai@suse.de>
-
由 Takashi Iwai 提交于
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: NAndrew Chant <achant@google.com> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 23 4月, 2018 8 次提交
-
-
由 Takashi Iwai 提交于
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: NNazar Mokrynskyi <nazar@mokrynskyi.com> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Takashi Iwai 提交于
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: NTakashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 David Henningsson 提交于
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: NDavid Henningsson <diwic@ubuntu.com> Reviewed-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp> Cc: <stable@vger.kernel.org> # v3.8+ Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Jeffery Miller 提交于
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: NJeffery Miller <jmiller@neverware.com> Cc: <stable@vger.kernel.org> # v4.13+ Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Linus Torvalds 提交于
-
git://people.freedesktop.org/~airlied/linux由 Linus Torvalds 提交于
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 ...
-
git://people.freedesktop.org/~agd5f/linux由 Dave Airlie 提交于
- 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 提交于
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
-