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@xxxxxxxxx>

> 
> 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