kernel.git/sound/usb/endpoint.c, branch linux-5.0.y

ALSA: usb-audio: remove redundant pointer 'urb'

2018-08-01T12:00:32Z

Pointer 'urb' is being assigned but is never used hence it is redundant and can be removed. Cleans up clang warning: warning: variable 'urb' set but not used [-Wunused-but-set-variable] Signed-off-by: Colin Ian King Signed-off-by: Takashi Iwai

ALSA: usb-audio: test EP_FLAG_RUNNING at urb completion

2017-01-05T06:35:17Z

Testing EP_FLAG_RUNNING in snd_complete_urb() before running the completion logic allows us to save a few cpu cycles by returning early, skipping the pending urb in case the stream was stopped; the stop logic handles the urb and sets the completion callbacks to NULL. Signed-off-by: Ioan-Adrian Ratiu Signed-off-by: Takashi Iwai

ALSA: usb-audio: Fix irq/process data synchronization

2017-01-05T06:35:00Z

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 Signed-off-by: Takashi Iwai

Revert "ALSA: usb-audio: Fix race at stopping the stream"

2016-12-21T17:48:14Z

This reverts commit 16200948d8353fe29a473a394d7d26790deae0e7. The commit was intended to cover the race condition, but it introduced yet another regression for devices with the implicit feedback, leading to a kernel panic due to NULL-dereference in an irq context. As the race condition that was addressed by the commit is very rare and the regression is much worse, let's revert the commit for rc1, and fix the issue properly in a later patch. Fixes: 16200948d835 ("ALSA: usb-audio: Fix race at stopping the stream") Reported-by: Ioan-Adrian Ratiu Cc: Signed-off-by: Takashi Iwai Signed-off-by: Linus Torvalds

ALSA: usb-audio: Eliminate noise at the start of DSD playback.

2016-12-12T21:43:35Z

[Problem] In some USB DACs, a terrible pop noise comes to be heard at the start of DSD playback (in the following situations). - play first DSD track - change from PCM track to DSD track - change from DSD64 track to DSD128 track (and etc...) - seek DSD track - Fast-Forward/Rewind DSD track [Cause] At the start of playback, there is a little silence. The silence bit pattern "0x69" is required on DSD mode, but it is not like that. [Solution] This patch adds DSD silence pattern to the endpoint settings. Signed-off-by: Nobutaka Okabe Signed-off-by: Takashi Iwai

Merge branch 'for-linus' into for-next

2016-12-09T10:21:35Z

ALSA: usb-audio: more tolerant packetsize

2016-12-06T12:55:59Z

since commit 57e6dae1087b ("ALSA: usb-audio: do not trust too-big wMaxPacketSize values"), the expected packetsize is always limited to nominal + 25%. It was discovered, that some devices (Android audio accessory) have a much higher jitter in used packetsizes than 25% which would result in BABBLE condition and dropping of packets. A better solution is so assume the jitter to be the nominal packetsize: -one nearly empty packet followed by a almost 150% sized one. V2: changed to assume max frequency is +50 of nominal packetsize. Signed-off-by: Andreas Pape Signed-off-by: Jiada Wang Acked-by: Clemens Ladisch Signed-off-by: Takashi Iwai

ALSA: usb-audio: Fix race at stopping the stream

2016-12-05T10:19:38Z

We've got a kernel crash report showing like: Unable to handle kernel NULL pointer dereference at virtual address 00000008 pgd = a1d7c000 [00000008] *pgd=31c93831, *pte=00000000, *ppte=00000000 Internal error: Oops: 17 [#1] PREEMPT SMP ARM CPU: 0 PID: 250 Comm: dbus-daemon Not tainted 3.14.51-03479-gf50bdf4 #1 task: a3ae61c0 ti: a08c8000 task.ti: a08c8000 PC is at retire_capture_urb+0x10/0x1f4 [snd_usb_audio] LR is at snd_complete_urb+0x140/0x1f0 [snd_usb_audio] pc : [<7f0eb22c>] lr : [<7f0e57fc>] psr: 200e0193 sp : a08c9c98 ip : a08c9ce8 fp : a08c9ce4 r10: 0000000a r9 : 00000102 r8 : 94cb3000 r7 : 94cb3000 r6 : 94d0f000 r5 : 94d0e8e8 r4 : 94d0e000 r3 : 7f0eb21c r2 : 00000000 r1 : 94cb3000 r0 : 00000000 Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user Control: 10c5387d Table: 31d7c04a DAC: 00000015 Process dbus-daemon (pid: 250, stack limit = 0xa08c8238) Stack: (0xa08c9c98 to 0xa08ca000) ... Backtrace: [<7f0eb21c>] (retire_capture_urb [snd_usb_audio]) from [<7f0e57fc>] (snd_complete_urb+0x140/0x1f0 [snd_usb_audio]) [<7f0e56bc>] (snd_complete_urb [snd_usb_audio]) from [<80371118>] (__usb_hcd_giveback_urb+0x78/0xf4) [<803710a0>] (__usb_hcd_giveback_urb) from [<80371514>] (usb_giveback_urb_bh+0x8c/0xc0) [<80371488>] (usb_giveback_urb_bh) from [<80028e3c>] (tasklet_hi_action+0xc4/0x148) [<80028d78>] (tasklet_hi_action) from [<80028358>] (__do_softirq+0x190/0x380) [<800281c8>] (__do_softirq) from [<80028858>] (irq_exit+0x8c/0xfc) [<800287cc>] (irq_exit) from [<8000ea88>] (handle_IRQ+0x8c/0xc8) [<8000e9fc>] (handle_IRQ) from [<800085e8>] (gic_handle_irq+0xbc/0xf8) [<8000852c>] (gic_handle_irq) from [<80509044>] (__irq_svc+0x44/0x78) [<80508820>] (_raw_spin_unlock_irq) from [<8004b880>] (finish_task_switch+0x5c/0x100) [<8004b824>] (finish_task_switch) from [<805052f0>] (__schedule+0x48c/0x6d8) [<80504e64>] (__schedule) from [<805055d4>] (schedule+0x98/0x9c) [<8050553c>] (schedule) from [<800116c8>] (do_work_pending+0x30/0xd0) [<80011698>] (do_work_pending) from [<8000e160>] (work_pending+0xc/0x20) Code: e1a0c00d e92ddff0 e24cb004 e24dd024 (e5902008) Kernel panic - not syncing: Fatal exception in interrupt There is a race between retire_capture_urb() and stop_endpoints(). The latter is called at stopping the stream and it sets some endpoint fields to NULL. But its call is asynchronous, thus the pending complete callback might get called after these NULL clears, and it leads the NULL dereference like the above. The fix is to move the NULL clearance after the synchronization, i.e. wait_clear_urbs(). This is called at prepare and hw_free callbacks, so it's assured to be called before the restart of the stream or the release of the stream. Also, while we're at it, put the EP_FLAG_RUNNING flag check at the beginning of snd_complete_urb() to skip the pending complete after the stream is stopped. Fixes: b2eb950de2f0 ("ALSA: usb-audio: stop both data and sync...") Reported-by: Jiada Wang Reported-by: Mark Craske Cc: Signed-off-by: Takashi Iwai

ALSA: usb: fine-tune Tenor error compensation value

2016-08-22T09:40:04Z

Users of devices affected by the Tenor feedback data error report buffer underruns, even with the +/- 0x1.0000 quirk applied. Compensating the error with 0xf000 instead seems to reliably fix that issue. See https://sourceforge.net/p/alsa/mailman/message/35230259/ Reported-and-tested-by: Norman Nolte Reported-and-tested-by: Thomas Gresens Signed-off-by: Daniel Mack Signed-off-by: Takashi Iwai

ALSA: usb: use TEAC UD-H01 quirk for more devices

2016-08-22T09:39:56Z

The quirk seems to be necessary not only for TEAC UD-H01 devices, but to more that are based on the Tenor 8802TL chipset. Devices built by T+A are affected too, and they apparently all use the same USB PID:PID. Extend the quirky handling for that device as well, and rename the quirks flag. Reported-and-tested-by: Thomas Gresens Signed-off-by: Daniel Mack Signed-off-by: Takashi Iwai