New: PATCH 6.1 082/167 which adds support for Owon HDS200 breaks functionality of Owon VDS1022

https://bugzilla.kernel.org/show_bug.cgi?id=220193

Bug ID: 220193
Summary: PATCH 6.1 082/167 which adds support for Owon HDS200
breaks functionality of Owon VDS1022
Product: Drivers
Version: 2.5
Kernel Version: 6.1-stable
Hardware: All
OS: Linux
Status: NEW
Severity: high
Priority: P3
Component: USB
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected]
Regression: Yes
Bisected 4cc01410e1c1dd075df10f750775c81d1cb6672b
commit-id:

The commit mentioned added support for the Owon HDS200 into the usb-simple-serial kernel driver. Since all the Owon test equipment uses the same VID and PID, my Owon VDS1022 stopped working in kernels that have this patch.

Currently I've blacklisted usb_simple_serial kernel module as a temporary workaround. Could you help with a proper fix?

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220193

Wei Huang ([email protected]) changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]

--- Comment #1 from Wei Huang ([email protected]) --- Hi leStoppe,

Thanks for reporting this and bisecting the regression to commit 4cc01410e1c1.

A fix has been submitted to the linux-usb mailing list. It narrows the OWON match from USB_DEVICE() to USB_DEVICE_AND_INTERFACE_INFO(), requiring bInterfaceClass=0x05 (Physical Interface Device) as reported in the HDS200 USB descriptor. This should let the VDS1022 fall back to the generic usbserial driver as before, provided it uses a different interface class.

The patch can be found here:
https://lore.kernel.org/linux-usb/[email protected]/

Could you test whether this resolves the issue on your VDS1022? If the VDS1022 also happens to use bInterfaceClass=0x05, further work (e.g. a probe callback checking the device string descriptor) may be needed.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220193

--- Comment #2 from leStoppe ([email protected]) --- Hi Wei Huang,

The patch resolves the issue. I tested it on the latest kernel (6.1.176) in Debian Bookworm. Just giving the version as a reference, the fix most certainly will work on any Kernel version that uses this driver.

Validation steps followed:

1. Test on un-patched kernel (Observed the issue as expected)
2. Rebuild the Kernel with the patch (The issues goes away. The VDS1022I connects properly without any intervetion)

Thank you so much for this fix!

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220193

--- Comment #3 from Wei Huang ([email protected]) --- Thank you for the detailed testing and confirmation!

For reference, a formal Tested-by tag has been requested on the mailing list so it can be included in the patch:
https://lore.kernel.org/linux-usb/[email protected]/

The patch is now awaiting review from the USB serial maintainers.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220193

--- Comment #4 from Wei Huang ([email protected]) --- Hi leStoppe,

Quick update: the patch you tested is currently under review on the linux-usb mailing list. To finalize it, the USB serial maintainer (Johan Hovold) needs a few details about the VDS1022:

1. Which userspace software do you use to talk to the VDS1022? In particular, is it a libusb-based tool (e.g. the Python 'vds1022' package)? This matters because once a kernel driver claims the USB interface, libusb can no longer access the device - which is the most likely explanation for the breakage you reported.

2. Could you please attach the output of:

       lsusb -v -d 5345:1234

for the VDS1022 (or the full 'lsusb -v' output if that fails)? The interface class reported in the descriptors decides how narrowly the driver match can be defined.

3. Does the VDS1022 support the same SCPI command set as the HDS200 series over its serial interface?

I asked these questions on the mailing list thread as well, but in case replying there is inconvenient, answering here is perfectly fine - I will forward the information to the thread.

A reworked version of the patch (v2) is already prepared and will be submitted as soon as this information is available.

Thanks a lot for your help!

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220193

Wei Huang ([email protected]) changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]

--- Comment #5 from Wei Huang ([email protected]) --- Hi leStoppe,

Friendly follow-up on the request from August - no pressure at all if you've been busy.

To recap: the patch fixing the VDS1022 regression is ready and was reviewed by the USB serial maintainer, but he asked for a few details about the device before it can be finalized. The one thing that would really help is the output of:

    lsusb -v -d 5345:1234

run with the VDS1022 plugged in (needs root; if it prints nothing, a plain "lsusb -v" also works). If you can also mention which application you use to talk to the scope (a libusb-based one?), that would settle the remaining review question.

If you no longer have access to the device, just say so and I'll note it on the mailing list - no problem either way.

Thanks a lot!

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220193

--- Comment #6 from leStoppe ([email protected]) ---
Apologies for the delayed response! I'll lookup the mail thread and reply there as well.

1. I use this software : https://github.com/florentbr/Owon-VDS1022

What you said is exactly what is happening. This software uses libusb to
access the VDS1022. The breakage started when the kernel automatically started to load the usb-simple-serial driver. The application could access it only after I blacklisted the driver.

3. The VDS1022 supports some SCPI commands. I can enable the socket for it via the userspace application above. I'm not sure the command set is same as HDS200 or if it can be done through the serial interface instead of libusb

2. Pasting the output of lsusb -v -d 5345:1234 below :

------------------------------------------------------------------------
Bus 001 Device 003: ID 5345:1234 Owon PDS6062T Oscilloscope Negotiated speed: Full Speed (12Mbps)
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00

  bDeviceClass            2 Communications
  bDeviceSubClass         0 [unknown]
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x5345 Owon
  idProduct          0x1234 PDS6062T Oscilloscope
  bcdDevice           10.01
  iManufacturer           1 S
  iProduct                2 U
  iSerial                 3 0
  bNumConfigurations      1

Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0029
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 50mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 5 Physical Interface Device
bInterfaceSubClass 6 [unknown]
bInterfaceProtocol 80
iInterface 0
** UNRECOGNIZED: 09 21 00 01 00 01 22 00 00 Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
cannot read device status, Resource temporarily unavailable (11)
-----------------------------------------------------------------------

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220193

--- Comment #7 from Wei Huang ([email protected]) --- Hi leStoppe,

No worries about the delay - and thanks, the dump is exactly what was needed.

Quick summary of where this landed: the interface tuple is what distinguishes the VDS1022 (class 5, subclass 6, protocol 0x50) from the HDS200 series (class 5, subclass 0, protocol 0, per the HDS272S dump in the commit message of the original driver). So the fix is to match the HDS200's full tuple, which leaves the VDS1022 unclaimed and lets your libusb tool work out of the box again.

I've submitted the updated patch (v2) on the linux-usb mailing list with this analysis and both descriptor dumps as evidence:
https://lore.kernel.org/linux-usb/[email protected]/

Thanks again - this settled the last open question from the review.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220193

Craig H ([email protected]) changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]

--- Comment #8 from Craig H ([email protected]) --- I did a bit more digging and found two problematic scenarios.

There seems to be some VDS1022I, that has been supported by the GitHub project, that identifies as the following:

  bInterfaceClass         5 Physical Interface Device
  bInterfaceSubClass      0
  bInterfaceProtocol      0

From:
https://github.com/florentbr/OWON-VDS1022/issues/54#issuecomment-1120191539

I have also found a owon serial driver user whose OWON SDS1102 identifies as the following:

bInterfaceClass 5 Physical Interface Device
bInterfaceSubClass 6 [unknown]
bInterfaceProtocol 80

From:
https://github.com/lucky62/OWON_SDS1102_Linux_Capture/issues/1

All variants:
https://github.com/linux4life798/owon-hds200-capture/blob/main/driver/USB_DESCRIPTORS.md

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220193

--- Comment #9 from Wei Huang ([email protected]) --- Hi Craig,

Thanks for the additional device data - this is very helpful, and it changes the picture significantly.

The VDS1022I reporting the same (5, 0, 0) tuple as the HDS200 means the interface-level narrowing approach I proposed doesn't reliably separate the device families. I've posted the analysis and options on the mailing list:

https://lore.kernel.org/linux-usb/[email protected]/

In short: OWON reuses the same tuples across devices with different userspace needs, so there may be no clean kernel-side fix. The question is now with the USB serial maintainer on how to proceed.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.