The USB Serial Driver Layer, Part II

In the first part of this article [LJ, February 2003], I introduced the USB serial layer and the basics of how to register a driver with the layer. This article explains some of the details about how data flows through the layer and how USB serial devices show up in sysfs.

In Part I of this article, I briefly mentioned the generic USB driver in the context of getting a USB device to communicate through it easily, with no custom kernel programming. Unfortunately, I didn't explain exactly how to do this, and many people wrote in with questions.

To create a USB device that works with the generic USB serial driver, all that is needed is two bulk USB endpoints on the device, one IN and one OUT. The generic USB serial driver will bind those two endpoints together into a single tty device that can be read from and written to from user space. For example, a device with the endpoints as described by /proc/bus/usb/devices (Figure 1) shows up as a single port device and produces the following kernel message when plugged in:

Generic converter detected
Generic converter now attached to ttyUSB0
    (or usb/tts/0 for devfs)

Then any user can send data to the device through the /dev/ttyUSB0 node.

Figure 1. A Sample /proc/bus/usb/devices Entry

If a device has more than one bulk IN and bulk OUT pair, multiple ports are assigned to the device. For example, a device with the endpoints as described by /proc/bus/usb/devices (Figure 2) shows up as a two-port device and produces the following kernel messages when plugged in:

Generic converter detected
Generic converter now attached to ttyUSB0
    (or usb/tts/0 for devfs)
Generic converter now attached to ttyUSB1
    (or usb/tts/1 for devfs)

For this device, both /dev/ttyUSB0 and /dev/ttyUSB1 can be used to communicate.

Figure 2. Entry for a Two-Port Device in /proc/bus/usb/devices

The order of the endpoints is not important, so all of the IN endpoints could be first, followed by the OUT endpoints (unlike the previous examples that alternate). The USB serial core will take all of the IN and OUT endpoints and pair them up in the order they are seen. It also will assign an interrupt endpoint to a bulk pair, if one is present, but the interrupt endpoint will not be used by the generic driver; it can be used only by a USB serial driver within the kernel.

To get the generic USB serial driver to bind to the device, the USB vendor and product IDs need to be specified as a module parameter when the usbserial module is loaded. For example, to bind to the previously described device with a vendor ID of ffff and product ID of fff8, use the following command:

modprobe usbserial vendor=0xffff product=0xfff8

If the user cannot be expected to load the usbserial module with the specific device ID, or if more than one device ID should be used by the generic USB serial driver, a very tiny driver can be written. An example of this is shown in Listing 1. In this driver, no callback functions are specified, only the product and vendor IDs of the devices that should be controlled. This is shown in the declaration of the struct usb_serial_device_type:

static struct usb_serial_device_type tiny_device = {
    .owner =            THIS_MODULE,
    .name =             "Tiny USB serial",
    .short_name =       "tiny",
    .id_table =         id_table,
    .num_interrupt_in = NUM_DONT_CARE,
    .num_bulk_in =      NUM_DONT_CARE,
    .num_bulk_out =     NUM_DONT_CARE,
    .num_ports =        1,
};

static struct usb_device_id id_table [] = {
    { USB_DEVICE(MY_PRODUCT_ID, MY_DEVICE_ID1) },
    { USB_DEVICE(MY_PRODUCT_ID, MY_DEVICE_ID2) },
    { USB_DEVICE(MY_PRODUCT_ID, MY_DEVICE_ID3) },
    { }     /* Terminating entry */
};

Listing 1. The Tiny Tiny USB Serial Driver

In all, this driver contains only two functions, which are two and three lines long, and three variable definitions. With it, all of the generic USB serial driver functionality will occur for the specified devices. The driver automatically will be loaded for the device when it is plugged in to the system, which is also a nice feature. This has to be one of the smallest working Linux kernel drivers possible. Compile it with:

echo "obj-m := tiny_tiny_usbserial.o" > Makefile
make -C <path/to/kernel/src> SUBDIRS=$PWD modules

The Windows operating system also supports this kind of device interface through the Windows USB OPOS serial driver, which will create virtual “COM” ports for the device. This allows hardware vendors to create USB devices that do not require any custom driver development for both Linux and Windows machines, which can be highly desirable.