Re: ehci-pci: Scarlett Gen 2 mixer driver init failure

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Alan,

Thank you so much for your help! With your hint...

On Wed, May 19, 2021 at 10:52:46AM -0400, Alan Stern wrote:
[...]
> The actual packets sent by ehci-hcd are exactly the same, regardless of
> whether they were submitted by a kernel driver or by userspace.  (In
> fact, userspace submits URBs by way of usbfs, which is itself a kernel
> driver.)

...I started comparing how usbfs submitted the packet in
do_proc_control() vs. how I was submitting the packet.

It turns out that in the name usb_sndctrlpipe(), "snd" is *not*
shorthand for "sound", but is in fact "send". So...

diff --git a/sound/usb/mixer_scarlett_gen2.c b/sound/usb/mixer_scarlett_gen2.c
index 560c2ade829d..dcff3e3a49f3 100644
--- a/sound/usb/mixer_scarlett_gen2.c
+++ b/sound/usb/mixer_scarlett_gen2.c
@@ -635,7 +635,7 @@ static int scarlett2_usb(
        /* send a second message to get the response */

        err = snd_usb_ctl_msg(mixer->chip->dev,
-                       usb_sndctrlpipe(mixer->chip->dev, 0),
+                       usb_rcvctrlpipe(mixer->chip->dev, 0),
                        SCARLETT2_USB_VENDOR_SPECIFIC_CMD_RESP,
                        USB_RECIP_INTERFACE | USB_TYPE_CLASS | USB_DIR_IN,
                        0,

...works for me now. I will prepare and submit a patch to alsa-devel.

[...]
> Have you looked at a complete usbmon record of _all_ the packets sent,
> starting from the time when the Focusrite Scarlett mixer is plugged in?
> It could be that some difference in the sequence of packets leading up
> to the one in question is what triggers the error.

That's what I actually thought the problem was for such a long time
until I could do a test setup that produced a clean diff of all the
packets from plug-in between working and not working which is what led
me here.

I'm not sure if there's anything that could reasonably be added to
make this sort of error easier to spot, such as warn if the pipe
direction doesn't match the requesttype direction? Or have the ehci
driver fix it up like the xhci driver appears to do?

A small aside; I did notice that usb_sndctrlpipe(dev, 0) is evaluated
twice in do_proc_control(), vs. usb_rcvctrlpipe(dev, 0) which is not;
you might like to make this change:

diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
index 533236366a03..4a8ec136460c 100644
--- a/drivers/usb/core/devio.c
+++ b/drivers/usb/core/devio.c
@@ -1162,7 +1162,7 @@ static int do_proc_control(struct usb_dev_state *ps,
 			tbuf, ctrl->wLength);
 
 		usb_unlock_device(dev);
-		i = usb_control_msg(dev, usb_sndctrlpipe(dev, 0), ctrl->bRequest,
+		i = usb_control_msg(dev, pipe, ctrl->bRequest,
 				    ctrl->bRequestType, ctrl->wValue, ctrl->wIndex,
 				    tbuf, ctrl->wLength, tmo);
 		usb_lock_device(dev);

Thanks again!

Regards,
Geoffrey.



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux