Commit 4cc01410e1c1 ("USB: serial: simple: add OWON HDS200 series
oscilloscope support") added a USB_DEVICE() match on VID:PID
0x5345:0x1234. OWON uses this same VID:PID across multiple device
families (HDS, VDS, SDS, PDS), so the overly broad match causes the
owon driver to also bind to devices like the VDS1022, which previously
worked fine with the generic usbserial driver.

Narrow the match to use USB_DEVICE_AND_INTERFACE_INFO() with the
Physical Interface Device class (bInterfaceClass=0x05,
bInterfaceSubClass=0x00, bInterfaceProtocol=0x00) as reported in the
HDS200 USB descriptor. Devices that use a different interface class
(e.g. vendor-specific 0xff) will no longer be claimed by the owon
driver and will fall back to the generic driver as before.

Reported-by: leStoppe <lestoppe@gmail.com>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220193
Signed-off-by: Huang Wei <huangwei@kylinos.cn>
---
 drivers/usb/serial/usb-serial-simple.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/serial/usb-serial-simple.c b/drivers/usb/serial/usb-serial-simple.c
index a0afaf254d12..82509669347e 100644
--- a/drivers/usb/serial/usb-serial-simple.c
+++ b/drivers/usb/serial/usb-serial-simple.c
@@ -100,9 +100,15 @@ DEVICE(nokia, NOKIA_IDS);
 	{ USB_DEVICE(0x09d7, 0x0100) }	/* NovAtel FlexPack GPS */
 DEVICE_N(novatel_gps, NOVATEL_IDS, 3);
 
-/* OWON electronic test and measurement equipment driver */
+/* OWON electronic test and measurement equipment driver.
+ * OWON uses the same VID:PID (0x5345:0x1234) for multiple device families
+ * (HDS, VDS, SDS, PDS). Match on the Physical Interface Device class (0x05)
+ * used by the HDS200 series to avoid binding devices that use a different
+ * interface class (e.g. vendor-specific 0xff) and may require different
+ * handling.
+ */
 #define OWON_IDS()			\
-	{ USB_DEVICE(0x5345, 0x1234) } /* HDS200 oscilloscopes and others */
+	{ USB_DEVICE_AND_INTERFACE_INFO(0x5345, 0x1234, 0x05, 0x00, 0x00) }
 DEVICE(owon, OWON_IDS);
 
 /* Siemens USB/MPI adapter */
-- 
2.25.1

[ +CC: Craig ]

On Mon, Aug 10, 2026 at 05:13:22PM +0800, Huang Wei wrote:
> Commit 4cc01410e1c1 ("USB: serial: simple: add OWON HDS200 series
> oscilloscope support") added a USB_DEVICE() match on VID:PID
> 0x5345:0x1234. OWON uses this same VID:PID across multiple device
> families (HDS, VDS, SDS, PDS), so the overly broad match causes the
> owon driver to also bind to devices like the VDS1022, which previously
> worked fine with the generic usbserial driver.

If it worked fine with the generic usbserial driver then it works fine
with the owon "simple" driver as it's effectively currently just an
alias for the generic driver but with automatic binding.

But based on the rest of the thread, it seems that you perhaps wanted to
say that it worked fine with a libusb based userspace driver?

> Narrow the match to use USB_DEVICE_AND_INTERFACE_INFO() with the
> Physical Interface Device class (bInterfaceClass=0x05,
> bInterfaceSubClass=0x00, bInterfaceProtocol=0x00) as reported in the
> HDS200 USB descriptor. Devices that use a different interface class
> (e.g. vendor-specific 0xff) will no longer be claimed by the owon
> driver and will fall back to the generic driver as before.

There is no fallback to any generic driver if you narrow the match.

And how do you know that won't cause regressions for users that have
started relying on the new driver?

For completeness, could you post the usb-devices (or lsusb -v) output
for the VDS1022?

Doesn't that device also support the SCPI protocol and should generally
work with the owon driver?

> Reported-by: leStoppe <lestoppe@gmail.com>
> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220193
> Signed-off-by: Huang Wei <huangwei@kylinos.cn>
> ---
>  drivers/usb/serial/usb-serial-simple.c | 10 ++++++++--
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/serial/usb-serial-simple.c b/drivers/usb/serial/usb-serial-simple.c
> index a0afaf254d12..82509669347e 100644
> --- a/drivers/usb/serial/usb-serial-simple.c
> +++ b/drivers/usb/serial/usb-serial-simple.c
> @@ -100,9 +100,15 @@ DEVICE(nokia, NOKIA_IDS);
>  	{ USB_DEVICE(0x09d7, 0x0100) }	/* NovAtel FlexPack GPS */
>  DEVICE_N(novatel_gps, NOVATEL_IDS, 3);
>  
> -/* OWON electronic test and measurement equipment driver */
> +/* OWON electronic test and measurement equipment driver.
> + * OWON uses the same VID:PID (0x5345:0x1234) for multiple device families
> + * (HDS, VDS, SDS, PDS). Match on the Physical Interface Device class (0x05)
> + * used by the HDS200 series to avoid binding devices that use a different
> + * interface class (e.g. vendor-specific 0xff) and may require different
> + * handling.
> + */

Multi-line comments should start with /* on its own line.

>  #define OWON_IDS()			\
> -	{ USB_DEVICE(0x5345, 0x1234) } /* HDS200 oscilloscopes and others */
> +	{ USB_DEVICE_AND_INTERFACE_INFO(0x5345, 0x1234, 0x05, 0x00, 0x00) }

And this should be USB_DEVICE_INTERFACE_CLASS().

>  DEVICE(owon, OWON_IDS);
>  
>  /* Siemens USB/MPI adapter */

Johan

Hi Johan,

Thanks for the review.

You're right that the owon 'simple' driver is effectively an alias for
the generic usbserial driver, so a VDS1022 used through a kernel tty
would not have been broken by the new match. The reporter's breakage is
therefore most likely due to a libusb-based userspace tool, which can
no longer claim the interface once the kernel driver binds to it -
before commit 4cc01410e1c1 nothing claimed these interfaces in-kernel,
so such tools worked out of the box.

leStoppe, to figure out the right fix, could you share:

 1. which userspace software you use with the VDS1022 (is it a
    libusb-based tool?);
 2. the output of "lsusb -v" (or "usb-devices") for the VDS1022;
 3. whether the VDS1022 supports the same SCPI command set as the
    HDS200 series.

Craig, was the intent of 4cc01410e1c1 to cover only the HDS200 series,
or the whole range of OWON scopes sharing this VID:PID?

I'll follow up with a v2 that switches to USB_DEVICE_INTERFACE_CLASS(),
fixes the comment style, and drops the wording about falling back to a
generic driver.

Best regards,
Huang Wei

On Mon, Aug 10, 2026 at 05:13:22PM +0800, Huang Wei wrote:
> Commit 4cc01410e1c1 ("USB: serial: simple: add OWON HDS200 series
> oscilloscope support") added a USB_DEVICE() match on VID:PID
> 0x5345:0x1234. OWON uses this same VID:PID across multiple device
> families (HDS, VDS, SDS, PDS), so the overly broad match causes the
> owon driver to also bind to devices like the VDS1022, which previously
> worked fine with the generic usbserial driver.

Where is the "owon driver" located at?  Is it just a userspace program
or a real kernel driver?

thanks,

greg k-h

On Mon, Aug 10, 2026 at 07:43:33PM +0200, Greg Kroah-Hartman wrote:
> Where is the "owon driver" located at? Is it just a userspace program
> or a real kernel driver?

Sorry for the unclear wording. The "owon driver" refers to the
owon_device usb_serial_driver registered in
drivers/usb/serial/usb-serial-simple.c. It is a real kernel driver,
added by the same commit 4cc01410e1c1 that introduced the regression.
I'll reword the commit message to avoid the ambiguity if a v2 is
needed.

> thanks,
> greg k-h

To address Michal's point: the VDS1022 community indeed has a libusb
based userspace tool [1], which needs direct USB access. Before commit
4cc01410e1c1, the owon driver did not exist and the device was not
claimed by any specific kernel driver. After that commit, the broad
USB_DEVICE() match caused the owon driver to claim the VDS1022 as
well, preventing the userspace tool from accessing it.

This patch restores the pre-regression behavior by narrowing the
match to the HDS200's interface class (0x05). The reporter has
confirmed that the VDS1022 now falls back to the generic usbserial
driver and works again [2].

[1] https://github.com/florentbr/OWON-VDS1022
[2] https://lore.kernel.org/linux-usb/20260810091322.2201740-1-huangwei@kylinos.cn/

As for the broader kernel-vs-libusb conflict Michal raised, it is
valid but predates this regression and is outside the scope of this
fix. The generic usbserial driver can be prevented from claiming the
device at the user's discretion (e.g. via unbinding or a udev rule)
if direct libusb access is needed.

Best regards,
Huang Wei

On Mon, 10 Aug 2026 13:43:33 +0200, Greg Kroah-Hartman wrote:
> On Mon, Aug 10, 2026 at 05:13:22PM +0800, Huang Wei wrote:
> > Commit 4cc01410e1c1 ("USB: serial: simple: add OWON HDS200 series
> > oscilloscope support") added a USB_DEVICE() match on VID:PID
> > 0x5345:0x1234. OWON uses this same VID:PID across multiple device
> > families (HDS, VDS, SDS, PDS), so the overly broad match causes the
> > owon driver to also bind to devices like the VDS1022, which
> > previously worked fine with the generic usbserial driver.

Did they really work with usbserial?

> Where is the "owon driver" located at?  Is it just a userspace program
> or a real kernel driver?

Looks like some people want to support these devices in userspace
with usb-serial-simple and others with libusb, and they are getting
in each other's way.

libusb: https://github.com/florentbr/OWON-VDS1022/issues/109
serial: https://github.com/linux4life798/owon-hds200-capture

Maybe let's ask those people what they think. Not sure how much they
overlap in their scope (heh), but it's possible that patches to remove
and re-add IDs will keep flowing if the kernel keeps applying them
but conflicting userspace tools don't sort it out.

Regards,
Michal

Hi Huang Wei,

     I've tested the patch and it solves the issue.

regards,
leStoppe

Hi leStoppe,

Thanks for testing! Could you provide a formal Tested-by tag so I
can add it to the patch? You can simply reply with:

  Tested-by: leStoppe <lestoppe@gmail.com>

Best regards,
Huang Wei

Hi Huang Wei,
	
	Sure, here you go!:

	Tested-by: leStoppe <lestoppe@gmail.com> [Debian Bookworm Kernel
	6.1.176 ]

regards,
leStoppe

On Tue, 11 Aug 2026 21:17:29 +0800
Huang Wei <huangwei@kylinos.cn> wrote:

> Hi leStoppe,
> 
> Thanks for testing! Could you provide a formal Tested-by tag so I
> can add it to the patch? You can simply reply with:
> 
>   Tested-by: leStoppe <lestoppe@gmail.com>
> 
> Best regards,
> Huang Wei