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

[Johan Hovold <johan@kernel.org>]

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