1. 22 Sep, 2017 1 commit
    • Takashi Iwai's avatar
      ALSA: usb-audio: Check out-of-bounds access by corrupted buffer descriptor · bfc81a8b
      Takashi Iwai authored
      When a USB-audio device receives a maliciously adjusted or corrupted
      buffer descriptor, the USB-audio driver may access an out-of-bounce
      value at its parser.  This was detected by syzkaller, something like:
        BUG: KASAN: slab-out-of-bounds in usb_audio_probe+0x27b2/0x2ab0
        Read of size 1 at addr ffff88006b83a9e8 by task kworker/0:1/24
        CPU: 0 PID: 24 Comm: kworker/0:1 Not tainted 4.14.0-rc1-42251-gebb2c243 #224
        Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
        Workqueue: usb_hub_wq hub_event
        Call Trace:
         __dump_stack lib/dump_stack.c:16
         dump_stack+0x292/0x395 lib/dump_stack.c:52
         print_address_description+0x78/0x280 mm/kasan/report.c:252
         kasan_report_error mm/kasan/report.c:351
         kasan_report+0x22f/0x340 mm/kasan/report.c:409
         __asan_report_load1_noabort+0x19/0x20 mm/kasan/report.c:427
         snd_usb_create_streams sound/usb/card.c:248
         usb_audio_probe+0x27b2/0x2ab0 sound/usb/card.c:605
         usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
         really_probe drivers/base/dd.c:413
         driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
         __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
         bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
         __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
         device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
         bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
         device_add+0xd0b/0x1660 drivers/base/core.c:1835
         usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932
         generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
         usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
         really_probe drivers/base/dd.c:413
         driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
         __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
         bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
         __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
         device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
         bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
         device_add+0xd0b/0x1660 drivers/base/core.c:1835
         usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
         hub_port_connect drivers/usb/core/hub.c:4903
         hub_port_connect_change drivers/usb/core/hub.c:5009
         port_event drivers/usb/core/hub.c:5115
         hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195
         process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
         worker_thread+0x221/0x1850 kernel/workqueue.c:2253
         kthread+0x3a1/0x470 kernel/kthread.c:231
         ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431
      This patch adds the checks of out-of-bounce accesses at appropriate
      places and bails out when it goes out of the given buffer.
      Reported-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Tested-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
  2. 06 Aug, 2017 1 commit
  3. 31 Mar, 2017 1 commit
    • Takashi Iwai's avatar
      ALSA: usb-audio: Fake also USB device id when alias is given · 03a1f48e
      Takashi Iwai authored
      Recently snd-usb-audio driver received a new option, quirk_alias, to
      allow user to apply the existing quirk for a different device.  This
      works for many quirks as is, but some still need more tune-ups:
      namely, some quirks check the USB vendor/device IDs in various places,
      thus it doesn't work as long as the ID is different from the expected
      With this patch, the driver stores the aliased USB ID, so that these
      rest quirks per device ID are applied.  The transition to use the
      cached USB ID was already done in the past, so what we needed now is
      only to overwrite chip->usb_id.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
  4. 29 Nov, 2016 1 commit
  5. 14 Nov, 2016 1 commit
    • Takashi Iwai's avatar
      ALSA: usb-audio: Fix use-after-free of usb_device at disconnect · 6ff1a253
      Takashi Iwai authored
      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
        [<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
        [<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: 79289e24 ('ALSA: usb-audio: Refer to chip->usb_id for quirks...')
      Reported-and-tested-by: default avatarShuah Khan <shuahkh@osg.samsung.com>
      Cc: <stable@vger.kernel.org> # v4.6+
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
  6. 18 Jul, 2016 1 commit
  7. 08 May, 2016 1 commit
  8. 31 Mar, 2016 1 commit
  9. 03 Mar, 2016 1 commit
  10. 29 Jan, 2016 2 commits
    • Takashi Iwai's avatar
      ALSA: usb-audio: Add quirk_alias option · e2703363
      Takashi Iwai authored
      This patch adds a new option "quirk_alias" to snd-usb-audio driver for
      allowing user to pass the quirk alias list.  A quirk alias consists of
      a string form like 0123abcd:5678beef, which makes to apply a quirk to
      a device with USB ID 0123:abcd treated as if it were 5678:beef.
      This feature is useful to test an existing quirk, typically for a
      newer model of the same vendor, without patching / rebuilding the
      kernel driver.
      The current implementation is fairly simplistic: since there is no API
      for matching a usb_device_id to the given ID pair, it has an open code
      to loop over the id table and matches only with vendor:product pair.
      So far, this is OK, as all existing entries are with vendor:product
      pairs, indeed.  Once when we have another matching entry, however,
      we'd need to update get_alias_quirk() as well.
      Note that this option is provided only for testing / development.  If
      you want to have a proper support, contact to upstream for adding the
      matching quirk in the driver code statically.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
    • Takashi Iwai's avatar
      ALSA: usb-audio: Refer to chip->usb_id for quirks and MIDI creation · 79289e24
      Takashi Iwai authored
      This is a preliminary patch for the later change to allow a better
      quirk ID management.  In the current USB-audio code, there are a few
      places looking at usb_device idVendor and idProduct fields directly
      even though we have already a static member in snd_usb_audio.usb_id.
      This patch modifies such codes to refer to the latter field.
      For achieving this, two slightly intensive changes have been done:
      - The snd_usb_audio object is set/reset via dev_getdrv() for the given
        USB device; it's needed for minimizing the changes for some existing
        quirks that take only usb_device object.
      - __snd_usbmidi_create() is introduced to receive the pre-given usb_id
        argument.  The exported snd_usbmidi_create() is unchanged by calling
        this new function internally.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
  11. 12 Jan, 2016 1 commit
    • Takashi Iwai's avatar
      ALSA: usb-audio: Avoid calling usb_autopm_put_interface() at disconnect · 5c06d68b
      Takashi Iwai authored
      ALSA PCM may still have a leftover instance after disconnection and
      it delays its release.  The problem is that the PCM close code path of
      USB-audio driver has a call of snd_usb_autosuspend().  This involves
      with the call of usb_autopm_put_interface() and it may lead to a
      kernel Oops due to the NULL object like:
       BUG: unable to handle kernel NULL pointer dereference at 0000000000000190
       IP: [<ffffffff815ae7ef>] usb_autopm_put_interface+0xf/0x30 PGD 0
       Call Trace:
        [<ffffffff8173bd94>] snd_usb_autosuspend+0x14/0x20
        [<ffffffff817461bc>] snd_usb_pcm_close.isra.14+0x5c/0x90
        [<ffffffff8174621f>] snd_usb_playback_close+0xf/0x20
        [<ffffffff816ef58a>] snd_pcm_release_substream.part.36+0x3a/0x90
        [<ffffffff816ef6b3>] snd_pcm_release+0xa3/0xb0
        [<ffffffff816debb0>] snd_disconnect_release+0xd0/0xe0
        [<ffffffff8114d417>] __fput+0x97/0x1d0
        [<ffffffff8114d589>] ____fput+0x9/0x10
        [<ffffffff8109e452>] task_work_run+0x72/0x90
        [<ffffffff81088510>] do_exit+0x280/0xa80
        [<ffffffff8108996a>] do_group_exit+0x3a/0xa0
        [<ffffffff8109261f>] get_signal+0x1df/0x540
        [<ffffffff81040903>] do_signal+0x23/0x620
        [<ffffffff8114c128>] ? do_readv_writev+0x128/0x200
        [<ffffffff810012e1>] prepare_exit_to_usermode+0x91/0xd0
        [<ffffffff810013ba>] syscall_return_slowpath+0x9a/0x120
        [<ffffffff817587cd>] ? __sys_recvmsg+0x5d/0x70
        [<ffffffff810d2765>] ? ktime_get_ts64+0x45/0xe0
        [<ffffffff8115dea0>] ? SyS_poll+0x60/0xf0
        [<ffffffff818d2327>] int_ret_from_sys_call+0x25/0x8f
      We have already a check of disconnection in snd_usb_autoresume(), but
      the check is missing its counterpart.  The fix is just to put the same
      check in snd_usb_autosuspend(), too.
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=109431
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
  12. 26 Aug, 2015 3 commits
    • Takashi Iwai's avatar
      ALSA: usb-audio: Handle normal and auto-suspend equally · 0662292a
      Takashi Iwai authored
      In theory, the device may get suspended even at runtime PM suspend.
      Currently we don't save the mixer state for autopm, and it may bring
      This patch removes the special handling for autosuspend.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
    • Takashi Iwai's avatar
      ALSA: usb-audio: Replace probing flag with active refcount · a6da499b
      Takashi Iwai authored
      We can use active refcount for preventing autopm during probe.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
    • Takashi Iwai's avatar
      ALSA: usb-audio: Avoid nested autoresume calls · 47ab1545
      Takashi Iwai authored
      After the recent fix of runtime PM for USB-audio driver, we got a
      lockdep warning like:
        [ INFO: possible recursive locking detected ]
        4.2.0-rc8+ #61 Not tainted
        pulseaudio/980 is trying to acquire lock:
         (&chip->shutdown_rwsem){.+.+.+}, at: [<ffffffffa0355dac>] snd_usb_autoresume+0x1d/0x52 [snd_usb_audio]
        but task is already holding lock:
         (&chip->shutdown_rwsem){.+.+.+}, at: [<ffffffffa0355dac>] snd_usb_autoresume+0x1d/0x52 [snd_usb_audio]
      This comes from snd_usb_autoresume() invoking down_read() and it's
      used in a nested way.  Although it's basically safe, per se (as these
      are read locks), it's better to reduce such spurious warnings.
      The read lock is needed to guarantee the execution of "shutdown"
      (cleanup at disconnection) task after all concurrent tasks are
      finished.  This can be implemented in another better way.
      Also, the current check of chip->in_pm isn't good enough for
      protecting the racy execution of multiple auto-resumes.
      This patch rewrites the logic of snd_usb_autoresume() & co; namely,
      - The recursive call of autopm is avoided by the new refcount,
        chip->active.  The chip->in_pm flag is removed accordingly.
      - Instead of rwsem, another refcount, chip->usage_count, is introduced
        for tracking the period to delay the shutdown procedure.  At
        the last clear of this refcount, wake_up() to the shutdown waiter is
      - The shutdown flag is replaced with shutdown atomic count; this is
        for reducing the lock.
      - Two new helpers are introduced to simplify the management of these
        refcounts; snd_usb_lock_shutdown() increases the usage_count, checks
        the shutdown state, and does autoresume.  snd_usb_unlock_shutdown()
        does the opposite.  Most of mixer and other codes just need this,
        and simply returns an error if it receives an error from lock.
      Fixes: 9003ebb1 ('ALSA: usb-audio: Fix runtime PM unbalance')
      Reported-and-tested-by: default avatarAlexnader Kuleshov <kuleshovmail@gmail.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
  13. 19 Aug, 2015 1 commit
    • Takashi Iwai's avatar
      ALSA: usb-audio: Fix runtime PM unbalance · 9003ebb1
      Takashi Iwai authored
      The fix for deadlock in PM in commit [1ee23fe0: ALSA: usb-audio:
      Fix deadlocks at resuming] introduced a new check of in_pm flag.
      However, the brainless patch author evaluated it in a wrong way
      (logical AND instead of logical OR), thus usb_autopm_get_interface()
      is wrongly called at probing, leading to unbalance of runtime PM
      This patch fixes it by correcting the logic.
      Reported-by: default avatarHans Yang <hansy@nvidia.com>
      Fixes: 1ee23fe0 ('ALSA: usb-audio: Fix deadlocks at resuming')
      Cc: <stable@vger.kernel.org> [v3.15+]
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
  14. 05 Nov, 2014 1 commit
    • Takashi Iwai's avatar
      ALSA: usb-audio: Fix device_del() sysfs warnings at disconnect · 0725dda2
      Takashi Iwai authored
      Some USB-audio devices show weird sysfs warnings at disconnecting the
      devices, e.g.
       usb 1-3: USB disconnect, device number 3
       ------------[ cut here ]------------
       WARNING: CPU: 0 PID: 973 at fs/sysfs/group.c:216 device_del+0x39/0x180()
       sysfs group ffffffff8183df40 not found for kobject 'midiC1D0'
       Call Trace:
        [<ffffffff814a3e38>] ? dump_stack+0x49/0x71
        [<ffffffff8103cb72>] ? warn_slowpath_common+0x82/0xb0
        [<ffffffff8103cc55>] ? warn_slowpath_fmt+0x45/0x50
        [<ffffffff813521e9>] ? device_del+0x39/0x180
        [<ffffffff81352339>] ? device_unregister+0x9/0x20
        [<ffffffff81352384>] ? device_destroy+0x34/0x40
        [<ffffffffa00ba29f>] ? snd_unregister_device+0x7f/0xd0 [snd]
        [<ffffffffa025124e>] ? snd_rawmidi_dev_disconnect+0xce/0x100 [snd_rawmidi]
        [<ffffffffa00c0192>] ? snd_device_disconnect+0x62/0x90 [snd]
        [<ffffffffa00c025c>] ? snd_device_disconnect_all+0x3c/0x60 [snd]
        [<ffffffffa00bb574>] ? snd_card_disconnect+0x124/0x1a0 [snd]
        [<ffffffffa02e54e8>] ? usb_audio_disconnect+0x88/0x1c0 [snd_usb_audio]
        [<ffffffffa015260e>] ? usb_unbind_interface+0x5e/0x1b0 [usbcore]
        [<ffffffff813553e9>] ? __device_release_driver+0x79/0xf0
        [<ffffffff81355485>] ? device_release_driver+0x25/0x40
        [<ffffffff81354e11>] ? bus_remove_device+0xf1/0x130
        [<ffffffff813522b9>] ? device_del+0x109/0x180
        [<ffffffffa01501d5>] ? usb_disable_device+0x95/0x1f0 [usbcore]
        [<ffffffffa014634f>] ? usb_disconnect+0x8f/0x190 [usbcore]
        [<ffffffffa0149179>] ? hub_thread+0x539/0x13a0 [usbcore]
        [<ffffffff810669f5>] ? sched_clock_local+0x15/0x80
        [<ffffffff81066c98>] ? sched_clock_cpu+0xb8/0xd0
        [<ffffffff81070730>] ? bit_waitqueue+0xb0/0xb0
        [<ffffffffa0148c40>] ? usb_port_resume+0x430/0x430 [usbcore]
        [<ffffffffa0148c40>] ? usb_port_resume+0x430/0x430 [usbcore]
        [<ffffffff8105973e>] ? kthread+0xce/0xf0
        [<ffffffff81059670>] ? kthread_create_on_node+0x1c0/0x1c0
        [<ffffffff814a8b7c>] ? ret_from_fork+0x7c/0xb0
        [<ffffffff81059670>] ? kthread_create_on_node+0x1c0/0x1c0
       ---[ end trace 40b1928d1136b91e ]---
      This comes from the fact that usb-audio driver may receive the
      disconnect callback multiple times, per each usb interface.  When a
      device has both audio and midi interfaces, it gets called twice, and
      currently the driver tries to release resources at the last call.
      At this point, the first parent interface has been already deleted,
      thus deleting a child of the first parent hits such a warning.
      For fixing this problem, we need to call snd_card_disconnect() and
      cancel pending operations at the very first disconnect while the
      release of the whole objects waits until the last disconnect call.
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=80931Reported-and-tested-by: default avatarTomas Gayoso <tgayoso@gmail.com>
      Reported-and-tested-by: default avatarChris J Arges <chris.j.arges@canonical.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
  15. 04 Nov, 2014 3 commits
  16. 05 Aug, 2014 1 commit
  17. 26 Jun, 2014 1 commit
    • Takashi Iwai's avatar
      ALSA: usb-audio: Fix races at disconnection and PCM closing · 92a586bd
      Takashi Iwai authored
      When a USB-audio device is disconnected while PCM is still running, we
      still see some race: the disconnect callback calls
      snd_usb_endpoint_free() that calls release_urbs() and then kfree()
      while a PCM stream would be closed at the same time and calls
      stop_endpoints() that leads to wait_clear_urbs().  That is, the EP
      object might be deallocated while a PCM stream is syncing with
      wait_clear_urbs() with the same EP.
      Basically calling multiple wait_clear_urbs() would work fine, also
      calling wait_clear_urbs() and release_urbs() would work, too, as
      wait_clear_urbs() just reads some fields in ep.  The problem is the
      succeeding kfree() in snd_pcm_endpoint_free().
      This patch moves out the EP deallocation into the later point, the
      destructor callback.  At this stage, all PCMs must have been already
      closed, so it's safe to free the objects.
      Reported-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
  18. 02 May, 2014 2 commits
  19. 26 Feb, 2014 1 commit
    • Takashi Iwai's avatar
      ALSA: usb-audio: Use standard printk helpers · 0ba41d91
      Takashi Iwai authored
      Convert with dev_err() and co from snd_printk(), etc.
      As there are too deep indirections (e.g. ep->chip->dev->dev),
      a few new local macros, usb_audio_err() & co, are introduced.
      Also, the device numbers in some messages are dropped, as they are
      shown in the prefix automatically.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
  20. 12 Feb, 2014 1 commit
  21. 03 Feb, 2014 1 commit
  22. 09 Oct, 2013 1 commit
  23. 07 Oct, 2013 1 commit
  24. 26 Sep, 2013 1 commit
    • Alan Stern's avatar
      ALSA: improve buffer size computations for USB PCM audio · 976b6c06
      Alan Stern authored
      This patch changes the way URBs are allocated and their sizes are
      determined for PCM playback in the snd-usb-audio driver.  Currently
      the driver allocates too few URBs for endpoints that don't use
      implicit sync, making underruns more likely to occur.  This may be a
      holdover from before I/O delays could be measured accurately; in any
      case, it is no longer necessary.
      The patch allocates as many URBs as possible, subject to four
      	The total number of URBs for the endpoint is not allowed to
      	exceed MAX_URBS (which the patch increases from 8 to 12).
      	The total number of packets per URB is not allowed to exceed
      	MAX_PACKS (or MAX_PACKS_HS for high-speed devices), which is
      	decreased from 20 to 6.
      	The total duration of queued data is not allowed to exceed
      	MAX_QUEUE, which is decreased from 24 ms to 18 ms.
      	The total number of ALSA frames in the output queue is not
      	allowed to exceed the ALSA buffer size.
      The last requirement is the hardest to implement.  Currently the
      number of URBs needed to fill a buffer cannot be determined in
      advance, because a buffer contains a fixed number of frames whereas
      the number of frames in an URB varies to match shifts in the device's
      clock rate.  To solve this problem, the patch changes the logic for
      deciding how many packets an URB should contain.  Rather than using as
      many as possible without exceeding an ALSA period boundary, now the
      driver uses only as many packets as needed to transfer a predetermined
      number of frames.  As a result, unless the device's clock has an
      exceedingly variable rate, the number of URBs making up each period
      (and hence each buffer) will remain constant.
      The overall effect of the patch is that playback works better in
      low-latency settings.  The user can still specify values for
      frames/period and periods/buffer that exceed the capabilities of the
      hardware, of course.  But for values that are within those
      capabilities, the performance will be improved.  For example, testing
      shows that a high-speed device can handle 32 frames/period and 3
      periods/buffer at 48 KHz, whereas the current driver starts to get
      glitchy at 64 frames/period and 2 periods/buffer.
      A side effect of these changes is that the "nrpacks" module parameter
      is no longer used.  The patch removes it.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      CC: Clemens Ladisch <clemens@ladisch.de>
      Tested-by: default avatarDaniel Mack <zonque@gmail.com>
      Tested-by: default avatarEldad Zack <eldad@fogrefinery.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
  25. 17 Jun, 2013 1 commit
  26. 25 Apr, 2013 1 commit
    • Takashi Iwai's avatar
      ALSA: usb-audio: Fix autopm error during probing · 60af3d03
      Takashi Iwai authored
      We've got strange errors in get_ctl_value() in mixer.c during
      probing, e.g. on Hercules RMX2 DJ Controller:
        ALSA mixer.c:352 cannot get ctl value: req = 0x83, wValue = 0x201, wIndex = 0xa00, type = 4
        ALSA mixer.c:352 cannot get ctl value: req = 0x83, wValue = 0x200, wIndex = 0xa00, type = 4
      It turned out that the culprit is autopm: snd_usb_autoresume() returns
      -ENODEV when called during card->probing = 1.
      Since the call itself during card->probing = 1 is valid, let's fix the
      return value of snd_usb_autoresume() as success.
      Reported-and-tested-by: default avatarDaniel Schürmann <daschuer@mixxx.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
  27. 04 Apr, 2013 3 commits
  28. 12 Mar, 2013 1 commit
  29. 29 Jan, 2013 1 commit
  30. 21 Nov, 2012 1 commit
  31. 14 Nov, 2012 1 commit
    • Takashi Iwai's avatar
      ALSA: usb-audio: Fix mutex deadlock at disconnection · 10e44239
      Takashi Iwai authored
      The recent change for USB-audio disconnection race fixes introduced a
      mutex deadlock again.  There is a circular dependency between
      chip->shutdown_rwsem and pcm->open_mutex, depicted like below, when a
      device is opened during the disconnection operation:
      A. snd_usb_audio_disconnect() ->
           card.c::register_mutex ->
             chip->shutdown_rwsem (write) ->
               snd_card_disconnect() ->
                 pcm.c::register_mutex ->
      B. snd_pcm_open() ->
           pcm->open_mutex ->
             snd_usb_pcm_open() ->
               chip->shutdown_rwsem (read)
      Since the chip->shutdown_rwsem protection in the case A is required
      only for turning on the chip->shutdown flag and it doesn't have to be
      taken for the whole operation, we can reduce its window in
      Reported-by: default avatarJiri Slaby <jslaby@suse.cz>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
  32. 30 Oct, 2012 1 commit