Recently released USB Audio Class 3.0 specification
introduces many significant changes comparing to
previous versions, like
 - new Power Domains, support for LPM/L1
 - new Cluster descriptor
 - changed layout of all class-specific descriptors
 - new High Capability descriptors
 - New class-specific String descriptors
 - new and removed units
 - additional sources for interrupts
 - removed Type II Audio Data Formats
 - ... and many other things (check spec)

It also provides backward compatibility through
multiple configurations, as well as requires
mandatory support for BADD (Basic Audio Device
Definition) on each ADC3.0 compliant device

This patch adds initial support of UAC3 specification
that is enough for Generic I/O Profile (BAOF, BAIF)
device support from BADD document.
Signed-off-by: NRuslan Bilovol <ruslan.bilovol@gmail.com>
Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This patch changes the semantics of the enable option for snd-usb-audio
in order to allow users to disable a device specified by either or both
of the vendor id and the product id.
Signed-off-by: NTamaki Nishino <otamachan@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

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: NAndrey Konovalov <andreyknvl@google.com>
Tested-by: NAndrey Konovalov <andreyknvl@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

usb_device_id are not supposed to change at runtime. All functions
working with usb_device_id provided by <linux/usb.h> work with
const usb_device_id. So mark the non-const structs as const.
Signed-off-by: NArvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

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
one.

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: NTakashi Iwai <tiwai@suse.de>

The function returns -EINVAL even if it builds the stream properly.
The bogus error code sneaked in during the code refactoring, but it
wasn't noticed until now since the returned error code itself is
ignored in anyway.  Kill it here, but there is no behavior change by
this patch, obviously.

Fixes: e5779998 ('ALSA: usb-audio: refactor code')
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

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
 Allocated:
  [<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
  ....
 Freed:
  [<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: NShuah Khan <shuahkh@osg.samsung.com>
Cc: <stable@vger.kernel.org> # v4.6+
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

snd_usb_{set_interface,ctl_msg}_quirk checks chip->usb_id to need
calling a quirks code. But existed code path that not calling
dev_set_drvdata in usb_audio_probe.

Fixes: 79289e24 ("ALSA: usb-audio: Refer to chip->usb_id for quirks and MIDI creation")
Signed-off-by: NKazuki Oikawa <k@oikw.org>
Cc: <stable@vger.kernel.org> # v4.6+
Reviewed-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Tested-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Allow handling SS+ USB devices correctly.
Signed-off-by: NOliver Neukum <oneukum@suse.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Unfortunately, this patch caused several regressions at au0828 and
snd-usb-audio, like this one:
	https://bugzilla.kernel.org/show_bug.cgi?id=115561

It also showed several troubles at the MC core that handles pretty
poorly the memory protections and data lifetime management.

So, better to revert it and fix the core before reapplying this
change.

This reverts commit aebb2b89 ("[media] sound/usb: Use Media
Controller API to share media resources")'
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Change ALSA driver to use Media Controller API to share media resources
with DVB and V4L2 drivers on a AU0828 media device. Media Controller
specific initialization is done after sound card is registered. ALSA
creates Media interface and entity function graph nodes for Control,
Mixer, PCM Playback, and PCM Capture devices.

snd_usb_hw_params() will call Media Controller enable source handler
interface to request the media resource. If resource request is
granted, it will release it from snd_usb_hw_free(). If resource is
busy, -EBUSY is returned.

Media specific cleanup is done in usb_audio_disconnect().
Signed-off-by: NShuah Khan <shuahkh@osg.samsung.com>
Acked-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

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: NTakashi Iwai <tiwai@suse.de>

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: NTakashi Iwai <tiwai@suse.de>

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: NTakashi Iwai <tiwai@suse.de>

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
inconsistency.

This patch removes the special handling for autosuspend.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

We can use active refcount for preventing autopm during probe.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

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
  called.
- 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: NAlexnader Kuleshov <kuleshovmail@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

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
refcount.

This patch fixes it by correcting the logic.
Reported-by: NHans Yang <hansy@nvidia.com>
Fixes: 1ee23fe0 ('ALSA: usb-audio: Fix deadlocks at resuming')
Cc: <stable@vger.kernel.org> [v3.15+]
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

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: NTomas Gayoso <tgayoso@gmail.com>
Reported-and-tested-by: NChris J Arges <chris.j.arges@canonical.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Some functions in mixer.c and endpoint.c receive list_head instead of
the object itself.  This is not obvious and rather error-prone.  Let's
pass the proper object directly instead.

The functions in midi.c still receive list_head and this can't be
changed since the object definition isn't exposed to the outside of
midi.c, so left as is.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The usb-audio probe and disconnect functions have been split just for
adapting the (new!) API at 2.5 kernel time.  We left them until now,
partly because we wanted to build with the pretty old kernels in the
external alsa-driver tree.  But the support of such old kernels has
been longly stopped, so it's good time to clean up this mess.

One good point by this cleanup is that now the probe function returns
a proper error code instead of only -EIO.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

sound/usb/card.c registers USB suspend and resume but did not previously
kill the input URBs. This means that USB MIDI devices left open across
suspend/resume had non-functional input (output still usually worked,
but it looks like that is another issue). Before this change, we would
get ESHUTDOWN for each of the input URBs at suspend time, killing input.
Signed-off-by: NAdam Goode <agoode@google.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

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: NAlan Stern <stern@rowland.harvard.edu>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The recent addition of the USB audio mixer suspend/resume may lead to
deadlocks when the driver tries to call usb_autopm_get_interface()
recursively, since the function tries to sync with the finish of the
other calls.  For avoiding it, introduce a flag indicating the resume
operation and avoids the recursive usb_autopm_get_interface() calls
during the resume.
Reported-and-tested-by: NBryan Quigley <gquigs@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The suspend callback of usb-audio driver may be called multiple times
per suspend when multiple USB interfaces are bound to a single sound
card instance.  In such a case, it's superfluous to save the mixer
values multiple times.  This patch fixes it by checking the counter.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

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: NTakashi Iwai <tiwai@suse.de>

Also remove superfluous snd_card_set_dev() calls.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Implement reset_resume callback so that the mixer values are properly
restored.  Still no boot quirks are called, so it might not work well
on some devices.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

module_usb_driver makes code simpler by removing the boilerplate.
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This patch updates snd_usb_audio_create also support devices whose
speed == USB_SPEED_WIRELESS.
Signed-off-by: NThomas Pugliese <thomas.pugliese@gmail.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

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
limitations:

	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: NAlan Stern <stern@rowland.harvard.edu>
CC: Clemens Ladisch <clemens@ladisch.de>
Tested-by: NDaniel Mack <zonque@gmail.com>
Tested-by: NEldad Zack <eldad@fogrefinery.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

When the Android firmware enables the audio interfaces in accessory
mode, it always declares in the control interface's baInterfaceNr array
that interfaces 0 and 1 belong to the audio function.  However, the
accessory interface itself, if also enabled, already is at index 0 and
shifts the actual audio interface numbers to 1 and 2, which prevents the
PCM streaming interface from being seen by the host driver.

To get the PCM interface interface to work, detect when the descriptors
point to the (for this driver useless) accessory interface, and redirect
to the correct one.
Reported-by: NJeremy Rosen <jeremy.rosen@openwide.fr>
Tested-by: NJeremy Rosen <jeremy.rosen@openwide.fr>
Cc: <stable@vger.kernel.org>
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

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: NDaniel Schürmann <daschuer@mixxx.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Add a module param to disable auto clock selection.
This is provided for users that expect the audio stream to
fail when the clock source is invalid (e.g., the word clock
was unintentionally disconnected).
Signed-off-by: NEldad Zack <eldad@fogrefinery.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Minor style fix, following a general code style in the kernel.
Signed-off-by: NEldad Zack <eldad@fogrefinery.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Change occurances of list_for_each into list_for_each_entry where
applicable.
Signed-off-by: NEldad Zack <eldad@fogrefinery.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The NuForce UDH-100 numbers its interfaces incorrectly, which makes the
interface associations come out wrong, which results in the driver
erroring out with the message "Audio class v2 interfaces need an
interface association".

Work around this by searching for the interface association descriptor
also in some other place where it might have ended up.
Reported-and-tested-by: NDave Helstroom <helstroom@google.com>
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Signed-off-by: NAntonio Ospite <ao2@amarulasolutions.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The async unlink behavior has been working over years.  The option was
provided only as a workaround for 2.4.x kernel.  Let's get rid of it.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>