Forked version of the Linux usbtmc driver

[tgaz]

As the firmware actually crashes with the Linux usbtmc driver, I've
spent some (far too much) time on trying to get it working.

There is a branch over at GitHub:

https://github.com/tommie/linux/blob/usbtmc-rigol/drivers/usb/class/usbtmc.c

I've interpreted the USBTMC specs differently from the original
authors of the Linux and Agilent drivers. It seems stable and hasn't
resulted in any crash (host or device ;) or truncated data so far.

What differs from before is that I issue a single Bulk-IN request, but
then read multiple times. It shouldn't make a difference as long as
userspace always requests as least as many bytes as will be available.
We are as bad as we were before communicating EOM to userspace, but
now the caller has more control over what is sent OTW.

From various sources, I see that people using libusb always read more
than the device would return, thus avoiding the USB bugs of the
firmware.

I'll squash some commits and submit to LKML for review at some point.

[Bert Vermeulen]

That's patching the linux kernel to work around a bug in a USB device's firmware, surely the wrong way to go about it. You might argue about the correct way to implement a standard, but a USB device crashing points to a bug in that device, period. I'm sure the LKML will see things the same way.

Considering this is a Rigol firmware project, I would suggest fixing the bug there. Clearly you already have a handle on the problem.

[tgaz]

I agree. It's easier to fix FOSS, though. ;)

And I would say it's really a matter of how you interpret the USBTMC
specs. The forked version isn't more or less ugly than previous code.
If anything, it's slightly more efficient as it doesn't send a
REQUEST_DEV_DEP_MSG_IN for each kernel buffer (2 kB,) but only one for
the entire syscall (which would normally be 500 kB.)

So I don't think it's a bad thing, and this is how everyone using
libusb seems to be doing it anyway.