Re: [PATCH] ALSA: usb-audio: Apply boot quirk for some Behringer models

[Jan Lentfer]

> Jan reported that a few Behringer devices became broken since the
> recent optimization to avoid usb_string() call at probe time at the
> commit b364a0d23cae ("ALSA: usb-audio: Use strings in struct usb_dev
> for manufacturer & co").  Interestingly, the devices seem requiring
> the explicit descriptor read at probing time, and the optimization
> above dropped it.
>
> There is already a boot quirk for another model, Behringer CM1A
> (1397:1234), that adds a device descriptor read, and this seems
> working for them, too.  So just apply the same boot quirk to those
> affected models:
>   - Behringer K-2 Mk II (1397:1230)
>   - Behringer Kobol Expander (1397:1249)
>   - Behringer 2-XM (1397:1256)
>
> Fixes: b364a0d23cae ("ALSA: usb-audio: Use strings in struct usb_dev for manufacturer & co")
> Reported-and-tested-by: Jan Lentfer<jan.lentfer@xxxxxx>
> Closes:https://lore.kernel.org/e7087d42-5e74-4d85-b1c5-b11eff235d41@xxxxxx
> Signed-off-by: Takashi Iwai<tiwai@xxxxxxx>
> ---
>   sound/usb/quirks.c | 3 +++
>   1 file changed, 3 insertions(+)
>
> diff --git a/sound/usb/quirks.c b/sound/usb/quirks.c
> index 294c7026b93c..de6a82a42eb7 100644
> --- a/sound/usb/quirks.c
> +++ b/sound/usb/quirks.c
> @@ -1702,7 +1702,10 @@ int snd_usb_apply_boot_quirk_once(struct usb_device *dev,
>   	switch (id) {
>   	case USB_ID(0x07fd, 0x0008): /* MOTU M Series, 1st hardware version */
>   		return snd_usb_motu_m_series_boot_quirk(dev);
> +	case USB_ID(0x1397, 0x1230): /* Behringer K-2 Mk II */
>   	case USB_ID(0x1397, 0x1234): /* Behringer CM1A */
> +	case USB_ID(0x1397, 0x1249): /* Behringer Kobol Expander */
> +	case USB_ID(0x1397, 0x1256): /* Behringer 2-XM */
>   		return snd_usb_cm1a_boot_quirk(dev);
>   	}
>   
> --


Hi Takashi,

thanks a lot for the quick patch!

One thought on the scope: Behringer sells a large number of synths and
drum machines that seem to share the same USB-MIDI firmware platform
(the ones managed by their "SynthTribe" tool). The three models in the
patch are simply the ones I tested first. Meanwhile I checked another
one I own, the CAT (1397:1224): it shows exactly the same stall, and a
single GET_DESCRIPTOR(DEVICE) from userspace fixes it as well. With the
CM1A that makes five different 1397 products needing the same wake-up,
so I'd expect more models to be affected and to show up one by one.

Since the quirk is just one extra GET_DESCRIPTOR(DEVICE) at probe time,
which should be harmless for any USB device, would it make sense to
apply it to the whole vendor ID 0x1397 instead of individual product
IDs?

For reference, what I have seen so far (7.2.7/7.2.8, device hot-plugged,
no wake-up in place):

  1397:1224  CAT               stalls, fixed by GET_DESCRIPTOR(DEVICE)
  1397:1230  K-2 MK II         stalls, fixed by GET_DESCRIPTOR(DEVICE)
  1397:1249  Kobol Expander    stalls
  1397:1256  2-XM              stalls
  1397:125f  PRO 800           fine
  1397:12a7  Grind             fine
  26a0:0040  Neutron           fine (different vendor ID)

So it looks like an older firmware generation is affected and newer
models are not, but that's only a guess from these few devices.

Either way, a vendor-wide read would not hurt the ones that don't
need it.

Also, to be precise about the Tested-by: I verified the fix by issuing
the same GET_DESCRIPTOR(DEVICE) request from userspace, not with a
kernel carrying your patch. I'm happy to test the patch itself if you
want the tag to reflect that.

Thanks,
Jan