kernel/git/stable/linux.git/sound/usb, branch linux-3.7.y

ALSA: usb-audio: fix Roland A-PRO support

2013-02-27T17:21:10+00:00

commit 7da58046482fceb17c4a0d4afefd9507ec56de7f upstream. The quirk for the Roland/Cakewalk A-PRO keyboards accidentally used the wrong interface number, which prevented the driver from attaching to the device. Signed-off-by: Clemens Ladisch Signed-off-by: Greg Kroah-Hartman

ALSA: usb-audio: fix invalid length check for RME and other UAC 2 devices

2013-02-04T00:27:03+00:00

commit d56268fb108c7c21e19933588ca4d94652585183 upstream. Commit 23caaf19b11e (ALSA: usb-mixer: Add support for Audio Class v2.0) forgot to adjust the length check for UAC 2.0 feature unit descriptors. This would make the code abort on encountering a feature unit without per-channel controls, and thus prevented the driver to work with any device having such a unit, such as the RME Babyface or Fireface UCX. Reported-by: Florian Hanisch Tested-by: Matthew Robbetts Tested-by: Michael Beer Cc: Daniel Mack Signed-off-by: Clemens Ladisch Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman

ALSA: usb - fix race in creation of M-Audio Fast track pro driver

2013-01-21T19:44:34+00:00

commit b98ae2729dea161edc96c9d177459b6c28bcbba5 upstream. A patch in the 3.2 kernel caused regression with hotplugging the M-Audio Fast track pro, or sound after suspend. I don't have the device so I haven't done a full analysis, but it seems userspace (both udev and pulseaudio) got confused when a card was created, immediately destroyed, and then created again. However, at least one person in the bug report (martin djfun) reports that this patch resolves the issue for him. It also leaves a message in the log: "snd-usb-audio: probe of 1-1.1:1.1 failed with error -5" which is a bit misleading. It is better than non-working audio, but maybe there's a more elegant solution? BugLink: https://bugs.launchpad.net/bugs/1095315 Signed-off-by: David Henningsson Signed-off-by: Takashi Iwai Cc: CAI Qian Signed-off-by: Greg Kroah-Hartman

ALSA: usb-audio: Fix missing autopm for MIDI input

2013-01-11T17:18:21+00:00

commit f5f165418cabf2218eb466c0e94693b8b1aee88b upstream. The commit [88a8516a: ALSA: usbaudio: implement USB autosuspend] added the support of autopm for USB MIDI output, but it didn't take the MIDI input into account. This patch adds the following for fixing the autopm: - Manage the URB start at the first MIDI input stream open, instead of the time of instance creation - Move autopm code to the common substream_open() - Make snd_usbmidi_input_start/_stop() more robust and add the running state check Reviewd-by: Clemens Ladisch Tested-by: Clemens Ladisch Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman

ALSA: usb-audio: Avoid autopm calls after disconnection

2013-01-11T17:18:19+00:00

commit 59866da9e4ae54819e3c4e0a8f426bdb0c2ef993 upstream. Add a similar protection against the disconnection race and the invalid use of usb instance after disconnection, as well as we've done for the USB audio PCM. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=51201 Reviewd-by: Clemens Ladisch Tested-by: Clemens Ladisch Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman

ALSA: snd-usb: properly initialize the sync endpoint

2012-11-22T20:22:33+00:00

Jeffrey Barish reported an obvious bug in the pcm part of the usb-audio driver which causes the code to not initialize the sync endpoint from configure_endpoint(). Reported-by: Jeffrey Barish Signed-off-by: Daniel Mack Cc: stable@kernel.org [3.5+] Signed-off-by: Takashi Iwai

Merge branch 'usb-midi-fix-3.7' of git://git.alsa-project.org/alsa-kprivate into for-linus

2012-11-19T08:55:06+00:00

Merge a regression fix for USB MIDI on non-standard usb-audio drivers by Clemens.

ALSA: ua101, usx2y: fix broken MIDI output

2012-11-18T16:15:24+00:00

Commit 88a8516a2128 (ALSA: usbaudio: implement USB autosuspend) added autosuspend code to all files making up the snd-usb-audio driver. However, midi.c is part of snd-usb-lib and is also used by other drivers, not all of which support autosuspend. Thus, calls to usb_autopm_get_interface() could fail, and this unexpected error would result in the MIDI output being completely unusable. Make it work by ignoring the error that is expected with drivers that do not support autosuspend. Reported-by: Colin Fletcher Reported-by: Devin Venable Reported-by: Dr Nick Bailey Reported-by: Jannis Achstetter Reported-by: Rui Nuno Capela Cc: Oliver Neukum Cc: 2.6.39+ Signed-off-by: Clemens Ladisch

ALSA: usb-audio: Fix mutex deadlock at disconnection

2012-11-14T14:29:09+00:00

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 -> pcm->open_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 snd_usb_audio_disconnect(). Reported-by: Jiri Slaby Cc: Signed-off-by: Takashi Iwai

ALSA: usb-audio: Fix crash at re-preparing the PCM stream

2012-11-08T07:56:44+00:00

There are bug reports of a crash with USB-audio devices when PCM prepare is performed immediately after the stream is stopped via trigger callback. It turned out that the problem is that we don't wait until all URBs are killed. This patch adds a new function to synchronize the pending stop operation on an endpoint, and calls in the prepare callback for avoiding the crash above. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=49181 Reported-and-tested-by: Artem S. Tashkinov Cc: [v3.6] Signed-off-by: Takashi Iwai