The VCP drivers seams to be loaded after remove command

pluis · October 14, 2022, 12:54pm

Hi everyone.
I am using a Beaglebone Green connected to my PC with the USB serial. Then I need to connect in the host USB connector a device that needs FTDI D2XX drivers. These drivers are installed according FTDI procedure. What appends is that I run the commands ‘sudo rmmod ftdi_sio’ and sudo rmmod usbserial’ to allow the D2XX drivers to work but when I connect the device in the USB host port it seams that the ftdi_sio is still active because it detects the device. It seams that the VCP drivers are reloaded every time I connect the device. Does any one have a clue why this appends ?

Thanks

zmatt · October 19, 2022, 1:57pm

Kernel drivers are loaded automatically upon detection of a device.

You shouldn’t need to have to manually unload drivers. If libftd2xx wants to directly access the usb device it can detach the ftdi_sio kernel driver itself, e.g. as seen in libftdi (an open-source alternative to libftd2xx):

github.com

lipro/libftdi/blob/v1.2/src/ftdi.c#L551


      
          libusb_free_config_descriptor (config0);
          
          
// Try to detach ftdi_sio kernel module.
          //
          // The return code is kept in a separate variable and only parsed
          // if usb_set_configuration() or usb_claim_interface() fails as the
          // detach operation might be denied and everything still works fine.
          // Likely scenario is a static ftdi_sio kernel module.
          if (ftdi->module_detach_mode == AUTO_DETACH_SIO_MODULE)
          {
              if (libusb_detach_kernel_driver(ftdi->usb_dev, ftdi->interface) !=0)
                  detach_errno = errno;
          }
          
          
if (libusb_get_configuration (ftdi->usb_dev, &cfg) < 0)
              ftdi_error_return(-12, "libusb_get_configuration () failed");
          // set configuration (needed especially for windows)
          // tolerate EBUSY: one device with one configuration, but two interfaces
          //    and libftdi sessions to both interfaces (e.g. FT2232)
          if (desc.bNumConfigurations > 0 && cfg != cfg0)
          {

If libftd2xx fails to do this, that would simply be a bug in libftd2xx.

zmatt · October 19, 2022, 2:04pm

Note that you don’t need ftdi_sio to communicate with a beaglebone unless you’re using an ftdi usb-serial cable to connect to the beaglebone’s debug serial port, which is not typical. So as an option of last resort you could just blacklist the ftdi_sio driver to prevent it from getting loaded. That can be done by creating a file /etc/modprobe.d/blacklist-ftdi_sio.conf containing the following line:

blacklist ftdi_sio

A better solution would be to use an udev rule to prevent the driver from being loaded only for the specific devices for which you want to use libd2xx. I don’t remember the details of how to do this but you can try a google search.

But like I said, in the end these are all just workarounds for bad software, they should not be needed if libd2xx is doing its job correctly.

pluis · October 21, 2022, 1:47pm

Hello zmatt, thanks for your reply.

I send a event log when I connect the device to the host usb port. Before I just removed the ftdi_sio and usbserial drivers. Repeating the rmmod command I get the message that the drivers are not loaded.

The log event list after reconnect the device is this one:

KERNEL - the kernel uevent

KERNEL[3240.693064] add KERNEL[3240.709622] add KERNEL[3240.709980] bind UDEV [3240.790288] add KERNEL[3240.822731] add KERNEL[3240.826729] add KERNEL[3240.827996] add KERNEL[3240.832655] add UDEV [3240.866928] add UDEV [3240.871552] add UDEV [3240.873689] add UDEV [3240.878810] add KERNEL[3240.890927] add UDEV [3240.895535] add KERNEL[3240.897467] add UDEV [3240.901899] add KERNEL[3240.903180] add UDEV [3240.909609] add KERNEL[3240.911708] add KERNEL[3240.920255] add KERNEL[3240.929192] bind KERNEL[3240.931559] bind UDEV [3240.934134] add UDEV [3240.943840] bind UDEV [3240.989919] add UDEV [3241.031763] add UDEV [3241.043781] bind UDEV [3241.066719] bind /devices/platform/ocp/47400000.usb/47401c00.usb/musb-hdrc.1/u sb1/1-1 (usb)
/devices/platform/ocp/47400000.usb/47401c00.usb/musb-hdrc.1/u sb1/1-1/1-1:1.0 (usb)
/devices/platform/ocp/47400000.usb/47401c00.usb/musb-hdrc.1/u sb1/1-1 (usb)
/devices/platform/ocp/47400000.usb/47401c00.usb/musb-hdrc.1/u sb1/1-1 (usb)
/module/usbserial (module)
/bus/usb-serial (bus)
/bus/usb/drivers/usbserial_generic (drivers)
/bus/usb-serial/drivers/generic (drivers)
/module/usbserial (module)
/bus/usb/drivers/usbserial_generic (drivers)
/bus/usb-serial (bus)
/bus/usb-serial/drivers/generic (drivers)
/module/ftdi_sio (module)
/module/ftdi_sio (module)
/bus/usb/drivers/ftdi_sio (drivers)
/bus/usb/drivers/ftdi_sio (drivers)
/bus/usb-serial/drivers/ftdi_sio (drivers)
/bus/usb-serial/drivers/ftdi_sio (drivers)
/devices/platform/ocp/47400000.usb/47401c00.usb/musb-hdrc.1/u sb1/1-1/1-1:1.0/ttyUSB0 (usb-serial)
/devices/platform/ocp/47400000.usb/47401c00.usb/musb-hdrc.1/u sb1/1-1/1-1:1.0/ttyUSB0/tty/ttyUSB0 (tty)
/devices/platform/ocp/47400000.usb/47401c00.usb/musb-hdrc.1/u sb1/1-1/1-1:1.0/ttyUSB0 (usb-serial)
/devices/platform/ocp/47400000.usb/47401c00.usb/musb-hdrc.1/u sb1/1-1/1-1:1.0 (usb)
/devices/platform/ocp/47400000.usb/47401c00.usb/musb-hdrc.1/u sb1/1-1/1-1:1.0 (usb)
/devices/platform/ocp/47400000.usb/47401c00.usb/musb-hdrc.1/u sb1/1-1 (usb)
/devices/platform/ocp/47400000.usb/47401c00.usb/musb-hdrc.1/u sb1/1-1/1-1:1.0/ttyUSB0 (usb-serial)
/devices/platform/ocp/47400000.usb/47401c00.usb/musb-hdrc.1/u sb1/1-1/1-1:1.0/ttyUSB0/tty/ttyUSB0 (tty)
/devices/platform/ocp/47400000.usb/47401c00.usb/musb-hdrc.1/u sb1/1-1/1-1:1.0/ttyUSB0 (usb-serial)
/devices/platform/ocp/47400000.usb/47401c00.usb/musb-hdrc.1/u

I also add the device data:

debian@beaglebone:/dev$ udevadm info -a -n ttyUSB0 | less

ATTRS{serial}=="musb-hdrc.1"
ATTRS{bDeviceProtocol}=="01"
ATTRS{bDeviceClass}=="09"
ATTRS{maxchild}=="1"
ATTRS{speed}=="480"
ATTRS{bDeviceSubClass}=="00"
ATTRS{interface_authorized_default}=="1"
ATTRS{idProduct}=="0002"

looking at parent device ‘/devices/platform/ocp/47400000.usb/47401c00.usb/musb-hdrc.1’:
KERNELS==“musb-hdrc.1”
SUBSYSTEMS==“platform”
DRIVERS==“musb-hdrc”
ATTRS{driver_override}==“(null)”
ATTRS{vbus}==“Vbus on, timeout 1100 msec”
ATTRS{mode}==“a_host”

looking at parent device ‘/devices/platform/ocp/47400000.usb/47401c00.usb’:
KERNELS==“47401c00.usb”
SUBSYSTEMS==“platform”
DRIVERS==“musb-dsps”
ATTRS{driver_override}==“(null)”

looking at parent device ‘/devices/platform/ocp/47400000.usb’:
KERNELS==“47400000.usb”
SUBSYSTEMS==“platform”
DRIVERS==“am335x-usb-childs”
ATTRS{driver_override}==“(null)”

looking at parent device ‘/devices/platform/ocp’:
KERNELS==“ocp”
SUBSYSTEMS==“platform”
DRIVERS==“”
ATTRS{driver_override}==“(null)”

looking at parent device ‘/devices/platform’:
KERNELS==“platform”
SUBSYSTEMS==“”
DRIVERS==“”

I can’t get a clue were is the rule stored that loads the device ; also I don’t know what is the device id that the OS gets or recognizes.

Thanks

zmatt · October 21, 2022, 3:08pm

USB device drivers are typically loaded based on the VID and PID of the usb device. You didn’t actually include the usb device (the parent of the ttyUSB0 device, /sys/devices/platform/ocp/47400000.usb/47401c00.usb/musb-hdrc.1/usb1/1-1/1-1:1.0) in your output. Its parents are not relevant.

pluis · October 21, 2022, 3:37pm

Hi zmatt,

I don’t know how to do it. To get these listings I just run the command 'sudo udevadm monitor ’ and then connecting the device I got the output above ( first list ).
I already run a small program using the D2xx drivers but for that I had to remove the VCP drivers more than once just before run the program. My goal is to discover a way to make a rule to avoid this loading at start up as you suggested.

Thanks

zmatt · October 21, 2022, 4:13pm

Like I said, detaching the ftdi_sio driver should be the responsibility of the library you’re using. If libftd2xx fails to do this, my recommendation would be to use libftdi instead which should properly take care of this.

If it’s not possible to use libftdi instead of libftd2xx, you should probably consider complaining to FTDI that libftd2xx should detach the kernel driver (e.g. using libusb_detach_kernel_driver() if they’re using libusb). As a workaround you can blacklist the ftdi_sio driver entirely as I already explained in an earlier reply.

I wouldn’t bother digging into udev unless you specifically need to use a mix of devices that need ftdi_sio and devices that need libftd2xx.

pluis · October 21, 2022, 4:34pm

According the FTDI manual, I need to detach the VCP drivers because it is Linux.
The libftd2xx seamed more complicated to use and that it is why I was avoiding to use ( also the device supplier has already some routines with D2xx drivers ).
I will try to blacklist the drivers.

Thanks

zmatt · October 21, 2022, 4:38pm

“VCP drivers” and “D2xx drivers” are Windows-specific terms, the linux equivalent of VCP is the ftdi_sio driver, the linux equivalent of D2xx is libftd2xx. I treated these terms as equivalent in my previous comments.

An open-source alternative to libftd2xx is libftdi.

If FTDI is saying you need to detach the ftdi_sio driver yourself then they’re simply incompetent, it’s the responsibility of their libftd2xx library. The aforementioned open source alternative, libftdi, does this correctly.

pluis · October 24, 2022, 7:49am

Hello,

Check this out.

https://ftdichip.com/wp-content/uploads/2020/08/AN_220_FTDI_Drivers_Installation_Guide_for_Linux-1.pdf

zmatt · October 25, 2022, 10:03pm

Yes that indeed confirms they’re not actually competent regarding how linux works, which also gives little confidence in their libftd2xx library, hence my recommendation to consider the open-source alternative libftdi which shouldn’t have these problems.

BTW there’s absolutely never a reason to remove the usbserial driver, I have not the slightest idea why they included that in their instructions. But even removing ftdi_sio is just a silly workaround for a problem in their library.