Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Fri, 22 Jan 2021 09:44:12 +0100
Message-ID: <s5hzh118ioz.wl-tiwai@suse.de>
From:   Takashi Iwai <tiwai@suse.de>
To:     Jamie Heilman <jamie@audible.transient.net>
Cc:     tiwai@suse.com, linux-kernel@vger.kernel.org
Subject: Re: bisected regression in v5.11-rc1 snd-usb-audio
In-Reply-To: <YAqIJHzE3UG51G/U@audible.transient.net>
References: <YAqIJHzE3UG51G/U@audible.transient.net>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka)
 FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/25.3
 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Precedence: bulk

On Fri, 22 Jan 2021 09:09:08 +0100,
Jamie Heilman wrote:
> 
> I've bisected a failure in support for the M2Tech USB HiFace Two
> 192kHz Digital Audio Interface device (read as: a reclocked USB
> S/PDIF) to the following ...
> 
> commit 93db51d06b32227319dae2ac289029ccf1b33181
> Author: Takashi Iwai <tiwai@suse.de>
> Date:   Mon Nov 23 09:53:09 2020 +0100
> 
>     ALSA: usb-audio: Check valid altsetting at parsing rates for UAC2/3
> 
> This has always been a somewhat finicky device, but my life is a
> silent void without it, as it is currently a vital part of getting
> audio to my mixer (now, if I could get USB Audio on my Rane MP2015
> actually working right I'd very happily take that approach instead[1],
> but I digress).  It has been known to require replugging to initialize
> properly at times, but until now, it's always worked fine eventually.
> 
> I've attached the dmesg from a working 5.10.9 kernel, the alsa-info
> output, and the lsusb -vvv output for this device when it's
> functioning.  (Note, that alsa-info claims jack isn't running...
> that's not actually true though, maybe because I'm using jack 2's
> jackdbus subsystem, but jack is infact running, though it's probably
> not relevant to the issue at hand[2].) 
> 
> When I boot 93db51d06b32 or later I get lot of errors in the dmesg
> like:
> 
>  usb 1-1.1.2: New USB device found, idVendor=249c, idProduct=930b, bcdDevice= 2.13
>  usb 1-1.1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
>  usb 1-1.1.2: Product: M2Tech USB Audio 2.0
>  usb 1-1.1.2: Manufacturer: M2Tech 
>  usb 1-1.1.2: SerialNumber: 0000
>  usb 1-1.1.2: cannot get ctl value: req = 0x83, wValue = 0x201, wIndex = 0xa00, type = 4
>  usb 1-1.1.2: 10:0: cannot get min/max values for control 2 (id 10)
>  usb 1-1.1.2: cannot get ctl value: req = 0x83, wValue = 0x200, wIndex = 0xa00, type = 4
>  usb 1-1.1.2: 10:0: cannot get min/max values for control 2 (id 10)
>  usbcore: registered new interface driver snd-usb-audio
>  usb 1-1.1-port2: disabled by hub (EMI?), re-enabling...
>  usb 1-1.1.2: USB disconnect, device number 6
>  usb 1-1.1.2: new full-speed USB device number 7 using ehci-pci
>  usb 1-1.1.2: device descriptor read/64, error -32
>  usb 1-1.1.2: device descriptor read/64, error -32
>  usb 1-1.1.2: new full-speed USB device number 8 using ehci-pci
>  usb 1-1.1.2: device descriptor read/64, error -32
>  usb 1-1.1.2: device descriptor read/64, error -32
>  usb 1-1.1-port2: attempt power cycle
>  usb 1-1.1.2: new full-speed USB device number 9 using ehci-pci
>  usb 1-1.1.2: device not accepting address 9, error -32
>  usb 1-1.1.2: new full-speed USB device number 10 using ehci-pci
>  usb 1-1.1.2: device not accepting address 10, error -32
>  usb 1-1.1-port2: unable to enumerate USB device
> 
> and obviously the device doesn't work at all.  Sometimes there's more
> "cannot get ctl value:" noise than other times, but the above is a
> clean boot after being in a working state (it tends to require
> replugging to get back to a being usable again after this, once I've
> booted a working kernel, possibly becuase its hanging off a hub in my
> monitor, not the most elegant of setups, I know---but none of this
> changes even if I plug it directly into my workstation's USB ports, I
> tried that).
> 
> I'm happy to try any patches, or provide more details, just ask.

You seem hitting a firmware bug, and it doesn't look like the only
case.  Interestingly, the backport of 5.11 USB-audio stuff on 5.3
kernel on openSUSE Leap 15.2 caused a similar bug on Steinberg device,
while it worked with 5.11-rc.  So I thought this specific with the
older kernel (in USB core changes or such), but my guess seems wrong,
and the bug looks remaining in 5.11 for some cases.

Below is the fix patch.  Please give it a try.


thanks,

Takashi

-- 8< --
From: Takashi Iwai <tiwai@suse.de>
Subject: [PATCH] ALSA: usb-audio: workaround for iface reset issue

The recently introduced sample rate validation code seems causing a
problem on some devices; namely, after performing this, the bus gets
screwed and it influences even on other USB devices.
As a quick workaround, perform it only for the necessary devices;
currently MOTU devices are known to need the valid altset checks, so
filter out other devices.

Fixes: 93db51d06b32 ("ALSA: usb-audio: Check valid altsetting at parsing rates for UAC2/3")
Reported-by: Jamie Heilman <jamie@audible.transient.net>
BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1178203
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
 sound/usb/format.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/sound/usb/format.c b/sound/usb/format.c
index 9ebc5d202c87..e6ff317a6785 100644
--- a/sound/usb/format.c
+++ b/sound/usb/format.c
@@ -466,6 +466,17 @@ static int validate_sample_rate_table_v2v3(struct snd_usb_audio *chip,
 	unsigned int nr_rates;
 	int i, err;
 
+	/* performing the rate verification may lead to unexpected USB bus
+	 * behavior afterwards by some unknown reason.  Do this only for the
+	 * known devices.
+	 */
+	switch (USB_ID_VENDOR(chip->usb_id)) {
+	case 0x07fd: /* MOTU */
+		break;
+	default:
+		return 0; /* don't perform the validation as default */
+	}
+
 	table = kcalloc(fp->nr_rates, sizeof(*table), GFP_KERNEL);
 	if (!table)
 		return -ENOMEM;
-- 
2.26.2