[PATCH v2 1/2] gpib: lpvo_usb: fix unintended binding of FTDI 8U232AM devices

[PATCH v2 1/2] gpib: lpvo_usb: fix unintended binding of FTDI 8U232AM devices

[Johan Hovold]

The LPVO USB GPIB adapter apparently uses an FTDI 8U232AM with the
default PID, but this device id is already handled by the ftdi_sio
serial driver.

Stop binding to the default PID to avoid breaking existing setups with
FTDI 8U232AM.

Anyone using this driver should blacklist the ftdi_sio driver and add
the device id manually through sysfs (e.g. using udev rules).

Fixes: fce79512a96a ("staging: gpib: Add LPVO DIY USB GPIB driver")
Fixes: e6ab504633e4 ("staging: gpib: Destage gpib")
Cc: Dave Penkler <dpenkler@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Johan Hovold <johan@kernel.org>
---
 drivers/gpib/lpvo_usb_gpib/lpvo_usb_gpib.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpib/lpvo_usb_gpib/lpvo_usb_gpib.c b/drivers/gpib/lpvo_usb_gpib/lpvo_usb_gpib.c
index 6fc4e3452b88..ee781d2f0b8e 100644
--- a/drivers/gpib/lpvo_usb_gpib/lpvo_usb_gpib.c
+++ b/drivers/gpib/lpvo_usb_gpib/lpvo_usb_gpib.c
@@ -38,8 +38,10 @@ MODULE_DESCRIPTION("GPIB driver for LPVO usb devices");
 /*
  * Table of devices that work with this driver.
  *
- * Currently, only one device is known to be used in the
- * lpvo_usb_gpib adapter (FTDI 0403:6001).
+ * Currently, only one device is known to be used in the lpvo_usb_gpib
+ * adapter (FTDI 0403:6001) but as this device id is already handled by the
+ * ftdi_sio USB serial driver the LPVO driver must not bind to it by default.
+ *
  * If your adapter uses a different chip, insert a line
  * in the following table with proper <Vendor-id>, <Product-id>.
  *
@@ -50,7 +52,6 @@ MODULE_DESCRIPTION("GPIB driver for LPVO usb devices");
  */
 
 static const struct usb_device_id skel_table[] = {
-	{ USB_DEVICE(0x0403, 0x6001) },
 	{ }					   /* Terminating entry */
 };
 MODULE_DEVICE_TABLE(usb, skel_table);
-- 
2.52.0

Re: [PATCH v2 1/2] gpib: lpvo_usb: fix unintended binding of FTDI 8U232AM devices

[Greg Kroah-Hartman]

On Thu, Mar 05, 2026 at 04:17:28PM +0100, Johan Hovold wrote:
> The LPVO USB GPIB adapter apparently uses an FTDI 8U232AM with the
> default PID, but this device id is already handled by the ftdi_sio
> serial driver.
> 
> Stop binding to the default PID to avoid breaking existing setups with
> FTDI 8U232AM.
> 
> Anyone using this driver should blacklist the ftdi_sio driver and add
> the device id manually through sysfs (e.g. using udev rules).
> 
> Fixes: fce79512a96a ("staging: gpib: Add LPVO DIY USB GPIB driver")
> Fixes: e6ab504633e4 ("staging: gpib: Destage gpib")
> Cc: Dave Penkler <dpenkler@gmail.com>
> Cc: stable@vger.kernel.org
> Signed-off-by: Johan Hovold <johan@kernel.org>
> ---
>  drivers/gpib/lpvo_usb_gpib/lpvo_usb_gpib.c | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpib/lpvo_usb_gpib/lpvo_usb_gpib.c b/drivers/gpib/lpvo_usb_gpib/lpvo_usb_gpib.c
> index 6fc4e3452b88..ee781d2f0b8e 100644
> --- a/drivers/gpib/lpvo_usb_gpib/lpvo_usb_gpib.c
> +++ b/drivers/gpib/lpvo_usb_gpib/lpvo_usb_gpib.c
> @@ -38,8 +38,10 @@ MODULE_DESCRIPTION("GPIB driver for LPVO usb devices");
>  /*
>   * Table of devices that work with this driver.
>   *
> - * Currently, only one device is known to be used in the
> - * lpvo_usb_gpib adapter (FTDI 0403:6001).
> + * Currently, only one device is known to be used in the lpvo_usb_gpib
> + * adapter (FTDI 0403:6001) but as this device id is already handled by the
> + * ftdi_sio USB serial driver the LPVO driver must not bind to it by default.
> + *
>   * If your adapter uses a different chip, insert a line
>   * in the following table with proper <Vendor-id>, <Product-id>.
>   *
> @@ -50,7 +52,6 @@ MODULE_DESCRIPTION("GPIB driver for LPVO usb devices");
>   */
>  
>  static const struct usb_device_id skel_table[] = {
> -	{ USB_DEVICE(0x0403, 0x6001) },

With this change, the driver now "does nothing".  Should we just mark it
as CONFIG_BROKEN as well?

thanks,

greg k-h

Re: [PATCH v2 1/2] gpib: lpvo_usb: fix unintended binding of FTDI 8U232AM devices

[Johan Hovold]

On Wed, Mar 11, 2026 at 03:21:52PM +0100, Greg Kroah-Hartman wrote:
> On Thu, Mar 05, 2026 at 04:17:28PM +0100, Johan Hovold wrote:
> > The LPVO USB GPIB adapter apparently uses an FTDI 8U232AM with the
> > default PID, but this device id is already handled by the ftdi_sio
> > serial driver.
> > 
> > Stop binding to the default PID to avoid breaking existing setups with
> > FTDI 8U232AM.
> > 
> > Anyone using this driver should blacklist the ftdi_sio driver and add
> > the device id manually through sysfs (e.g. using udev rules).

> > @@ -38,8 +38,10 @@ MODULE_DESCRIPTION("GPIB driver for LPVO usb devices");
> >  /*
> >   * Table of devices that work with this driver.
> >   *
> > - * Currently, only one device is known to be used in the
> > - * lpvo_usb_gpib adapter (FTDI 0403:6001).
> > + * Currently, only one device is known to be used in the lpvo_usb_gpib
> > + * adapter (FTDI 0403:6001) but as this device id is already handled by the
> > + * ftdi_sio USB serial driver the LPVO driver must not bind to it by default.
> > + *
> >   * If your adapter uses a different chip, insert a line
> >   * in the following table with proper <Vendor-id>, <Product-id>.
> >   *
> > @@ -50,7 +52,6 @@ MODULE_DESCRIPTION("GPIB driver for LPVO usb devices");
> >   */
> >  
> >  static const struct usb_device_id skel_table[] = {
> > -	{ USB_DEVICE(0x0403, 0x6001) },
> 
> With this change, the driver now "does nothing".  Should we just mark it
> as CONFIG_BROKEN as well?

That would prevent people with this device from using the driver by
manually adding the device id through sysfs.

Some FTDI devices can be programmed with product specific PIDs, but not
sure about 8U232AM. Or if whoever built this is still around to care
enough.

When I saw the skeleton driver included verbatim, including the
example minor number (which has been reserved for something else, but I
guess that's less of an issue these days), and that it was binding to
the default FTDI PID, my initial thought was just to drop the driver (or
move it back to staging, but then we'd still need to drop the device
id).

Johan

Re: [PATCH v2 1/2] gpib: lpvo_usb: fix unintended binding of FTDI 8U232AM devices

[Dave Penkler]

On Wed, Mar 11, 2026 at 04:28:50PM +0100, Johan Hovold wrote:
> On Wed, Mar 11, 2026 at 03:21:52PM +0100, Greg Kroah-Hartman wrote:
> > On Thu, Mar 05, 2026 at 04:17:28PM +0100, Johan Hovold wrote:
> > > The LPVO USB GPIB adapter apparently uses an FTDI 8U232AM with the
> > > default PID, but this device id is already handled by the ftdi_sio
> > > serial driver.
> > > 
> > > Stop binding to the default PID to avoid breaking existing setups with
> > > FTDI 8U232AM.
> > > 
> > > Anyone using this driver should blacklist the ftdi_sio driver and add
> > > the device id manually through sysfs (e.g. using udev rules).
> 
> > > @@ -38,8 +38,10 @@ MODULE_DESCRIPTION("GPIB driver for LPVO usb devices");
> > >  /*
> > >   * Table of devices that work with this driver.
> > >   *
> > > - * Currently, only one device is known to be used in the
> > > - * lpvo_usb_gpib adapter (FTDI 0403:6001).
> > > + * Currently, only one device is known to be used in the lpvo_usb_gpib
> > > + * adapter (FTDI 0403:6001) but as this device id is already handled by the
> > > + * ftdi_sio USB serial driver the LPVO driver must not bind to it by default.
> > > + *
> > >   * If your adapter uses a different chip, insert a line
> > >   * in the following table with proper <Vendor-id>, <Product-id>.
> > >   *
> > > @@ -50,7 +52,6 @@ MODULE_DESCRIPTION("GPIB driver for LPVO usb devices");
> > >   */
> > >  
> > >  static const struct usb_device_id skel_table[] = {
> > > -	{ USB_DEVICE(0x0403, 0x6001) },
> > 
> > With this change, the driver now "does nothing".  Should we just mark it
> > as CONFIG_BROKEN as well?
> 
> That would prevent people with this device from using the driver by
> manually adding the device id through sysfs.
> 
> Some FTDI devices can be programmed with product specific PIDs, but not
> sure about 8U232AM. Or if whoever built this is still around to care
> enough.

We are testing udev rules to bind the driver in sysfs for the lpvo_usb_gpib
driver for inclusion in the user space package. Removing the binding for this
driver is the right thing to do. Belatedly:

Acked-by: Dave Penkler <dpenkler@gmail.com>

> 
> When I saw the skeleton driver included verbatim, including the
> example minor number (which has been reserved for something else, but I
> guess that's less of an issue these days), and that it was binding to
> the default FTDI PID, my initial thought was just to drop the driver (or
> move it back to staging, but then we'd still need to drop the device
> id).
> 
> Johan