Request for information how to disable USB bulk endpoint transfer validation

Commit Message

Alan Stern April 23, 2018, 8:50 p.m. UTC

On Mon, 23 Apr 2018, Elvinas wrote:

> Hello,
> 
> I have a somewhat strange request: how to break Linux USB support and disable some 
> validation.
> 
> Recently I have become a "lucky" owner of the badly designed hardware (ZWO 120MM astronomy 
>   camera to be specific) and stumbled upon classic issue: hardware was designed not 
> according to specifications, but to work on Windows. From what I was able to dig on ZWO 
> forums , camera uses bulk transfer mode, but uses incorrect packet size of 1024 bytes. 
> Windows ignores that, Linux - does not. As a result camera does not work in Linux.
> 
> There are repeated messages in kern.log "usb 1-1: reset high-speed USB device number 8 
> using ehci_hcd" and "usb usb1-port1: disabled by hub (EMI?), re-enabling..." each time I 
> attempted to use camera.
> 
> In ZWO forums there was a suggestion to revert USB packet validation by applying a "break" 
> to Linux kernel. With some changes to line locations I have applied the patch below and 
> camera started to work on a desktop with USB 2.0 host.

The patch you wrote isn't ideal; the one below is better.  In fact, the
code should be like this already.  It was an oversight.

> However this patch does not help if 
> camera is attached to a laptop with USB 3.0 host. Each time I try to use camera, I see 
> similar error messages, but now originating from xhci_hcd.
> 
> Question: can anyone point what lines should be commented out to ignore packet sizes for 
> USB 2.0 device, when attached to USB 3.0 host?

As far as I know, there is no way to do this.  USB-3 xHCI host
controllers validate maxpacket sizes in the hardware, not in software,
and there isn't any way to change the hardware's behavior.  But I am
not an expert on xHCI.

Does the camera work when attached to a USB-3 host controller on a 
computer running Windows or Mac OS X?

> As I am not much of C programmer I have not been able to locate those myself and did not 
> want to play "whack a mole" by commenting out some random line, wait ~1 hour to compile 
> kernel and see that nothing good happens.
> 
> -------------------- CUT LINE -------------------
> --- config.c.ORIG   2018-03-14 19:48:11.000000000 +0200
> +++ config.c   2018-04-16 19:45:24.538599024 +0300
> @@ -374,10 +374,12 @@
>      j = maxpacket_maxes[usb_endpoint_type(&endpoint->desc)];
> 
>      if (maxp > j) {
> -      dev_warn(ddev, "config %d interface %d altsetting %d endpoint 0x%X has invalid 
> maxpacket %d, setting to %d\n",
> +      dev_warn(ddev, "config %d interface %d altsetting %d endpoint 0x%X has invalid 
> maxpacket %d, setting to %d (IGNORED!)\n",
>             cfgno, inum, asnum, d->bEndpointAddress, maxp, j);
> +      #if 0
>         maxp = j;
>         endpoint->desc.wMaxPacketSize = cpu_to_le16(i | maxp);
> 
> -------------------- CUT LINE -------------------
> 
> PS I know that not the ideal way to solve the problem, but booting customized kernel just 
> for the imaging sessions for me seems to be a good trade off.
> 
> Thank you

Alan Stern




--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Elvinas April 24, 2018, 5:41 p.m. UTC | #1

Hello,

On 04/23/2018 11:50 PM, Alan Stern wrote:
>>
>> In ZWO forums there was a suggestion to revert USB packet validation by applying a "break"
>> to Linux kernel. With some changes to line locations I have applied the patch below and
>> camera started to work on a desktop with USB 2.0 host.
> 
> The patch you wrote isn't ideal; the one below is better.  In fact, the
> code should be like this already.  It was an oversight.
Well, that was not my patch. I have just updated line numbers.

>> Question: can anyone point what lines should be commented out to ignore packet sizes for
>> USB 2.0 device, when attached to USB 3.0 host?
> 
> As far as I know, there is no way to do this.  USB-3 xHCI host
> controllers validate maxpacket sizes in the hardware, not in software,
> and there isn't any way to change the hardware's behavior.  But I am
> not an expert on xHCI.
> 
> Does the camera work when attached to a USB-3 host controller on a
> computer running Windows or Mac OS X?

It looks you are right. Camera does not work properly on a Windows computer with USB 3.0 
host. So it may be as you said - data is validated by hardware, device does not work and I 
will have thrown some money out.

Anyway thanks for the help

Patch

Index: usb-4.x/drivers/usb/core/config.c
===================================================================
--- usb-4.x.orig/drivers/usb/core/config.c
+++ usb-4.x/drivers/usb/core/config.c
@@ -191,7 +191,9 @@  static const unsigned short full_speed_m
 static const unsigned short high_speed_maxpacket_maxes[4] = {
 	[USB_ENDPOINT_XFER_CONTROL] = 64,
 	[USB_ENDPOINT_XFER_ISOC] = 1024,
-	[USB_ENDPOINT_XFER_BULK] = 512,
+
+	/* Bulk should be 512, but some devices use 1024: we warn below */
+	[USB_ENDPOINT_XFER_BULK] = 1024,
 	[USB_ENDPOINT_XFER_INT] = 1024,
 };
 static const unsigned short super_speed_maxpacket_maxes[4] = {