10e8c46d0SMauro Carvalho Chehab.. _writing-usb-driver: 20e8c46d0SMauro Carvalho Chehab 34ad4b21bSMauro Carvalho Chehab========================== 44ad4b21bSMauro Carvalho ChehabWriting USB Device Drivers 54ad4b21bSMauro Carvalho Chehab========================== 64ad4b21bSMauro Carvalho Chehab 74ad4b21bSMauro Carvalho Chehab:Author: Greg Kroah-Hartman 84ad4b21bSMauro Carvalho Chehab 94ad4b21bSMauro Carvalho ChehabIntroduction 104ad4b21bSMauro Carvalho Chehab============ 114ad4b21bSMauro Carvalho Chehab 124ad4b21bSMauro Carvalho ChehabThe Linux USB subsystem has grown from supporting only two different 134ad4b21bSMauro Carvalho Chehabtypes of devices in the 2.2.7 kernel (mice and keyboards), to over 20 144ad4b21bSMauro Carvalho Chehabdifferent types of devices in the 2.4 kernel. Linux currently supports 154ad4b21bSMauro Carvalho Chehabalmost all USB class devices (standard types of devices like keyboards, 164ad4b21bSMauro Carvalho Chehabmice, modems, printers and speakers) and an ever-growing number of 174ad4b21bSMauro Carvalho Chehabvendor-specific devices (such as USB to serial converters, digital 184ad4b21bSMauro Carvalho Chehabcameras, Ethernet devices and MP3 players). For a full list of the 194ad4b21bSMauro Carvalho Chehabdifferent USB devices currently supported, see Resources. 204ad4b21bSMauro Carvalho Chehab 214ad4b21bSMauro Carvalho ChehabThe remaining kinds of USB devices that do not have support on Linux are 224ad4b21bSMauro Carvalho Chehabalmost all vendor-specific devices. Each vendor decides to implement a 234ad4b21bSMauro Carvalho Chehabcustom protocol to talk to their device, so a custom driver usually 244ad4b21bSMauro Carvalho Chehabneeds to be created. Some vendors are open with their USB protocols and 254ad4b21bSMauro Carvalho Chehabhelp with the creation of Linux drivers, while others do not publish 264ad4b21bSMauro Carvalho Chehabthem, and developers are forced to reverse-engineer. See Resources for 274ad4b21bSMauro Carvalho Chehabsome links to handy reverse-engineering tools. 284ad4b21bSMauro Carvalho Chehab 294ad4b21bSMauro Carvalho ChehabBecause each different protocol causes a new driver to be created, I 304ad4b21bSMauro Carvalho Chehabhave written a generic USB driver skeleton, modelled after the 314ad4b21bSMauro Carvalho Chehabpci-skeleton.c file in the kernel source tree upon which many PCI 324ad4b21bSMauro Carvalho Chehabnetwork drivers have been based. This USB skeleton can be found at 334ad4b21bSMauro Carvalho Chehabdrivers/usb/usb-skeleton.c in the kernel source tree. In this article I 344ad4b21bSMauro Carvalho Chehabwill walk through the basics of the skeleton driver, explaining the 354ad4b21bSMauro Carvalho Chehabdifferent pieces and what needs to be done to customize it to your 364ad4b21bSMauro Carvalho Chehabspecific device. 374ad4b21bSMauro Carvalho Chehab 384ad4b21bSMauro Carvalho ChehabLinux USB Basics 394ad4b21bSMauro Carvalho Chehab================ 404ad4b21bSMauro Carvalho Chehab 414ad4b21bSMauro Carvalho ChehabIf you are going to write a Linux USB driver, please become familiar 424ad4b21bSMauro Carvalho Chehabwith the USB protocol specification. It can be found, along with many 434ad4b21bSMauro Carvalho Chehabother useful documents, at the USB home page (see Resources). An 444ad4b21bSMauro Carvalho Chehabexcellent introduction to the Linux USB subsystem can be found at the 454ad4b21bSMauro Carvalho ChehabUSB Working Devices List (see Resources). It explains how the Linux USB 464ad4b21bSMauro Carvalho Chehabsubsystem is structured and introduces the reader to the concept of USB 474ad4b21bSMauro Carvalho Chehaburbs (USB Request Blocks), which are essential to USB drivers. 484ad4b21bSMauro Carvalho Chehab 494ad4b21bSMauro Carvalho ChehabThe first thing a Linux USB driver needs to do is register itself with 504ad4b21bSMauro Carvalho Chehabthe Linux USB subsystem, giving it some information about which devices 514ad4b21bSMauro Carvalho Chehabthe driver supports and which functions to call when a device supported 524ad4b21bSMauro Carvalho Chehabby the driver is inserted or removed from the system. All of this 530e8c46d0SMauro Carvalho Chehabinformation is passed to the USB subsystem in the :c:type:`usb_driver` 540e8c46d0SMauro Carvalho Chehabstructure. The skeleton driver declares a :c:type:`usb_driver` as:: 554ad4b21bSMauro Carvalho Chehab 564ad4b21bSMauro Carvalho Chehab static struct usb_driver skel_driver = { 574ad4b21bSMauro Carvalho Chehab .name = "skeleton", 584ad4b21bSMauro Carvalho Chehab .probe = skel_probe, 594ad4b21bSMauro Carvalho Chehab .disconnect = skel_disconnect, 60296ecb35SPhilipp Hortmann .suspend = skel_suspend, 61296ecb35SPhilipp Hortmann .resume = skel_resume, 62296ecb35SPhilipp Hortmann .pre_reset = skel_pre_reset, 63296ecb35SPhilipp Hortmann .post_reset = skel_post_reset, 644ad4b21bSMauro Carvalho Chehab .id_table = skel_table, 65296ecb35SPhilipp Hortmann .supports_autosuspend = 1, 664ad4b21bSMauro Carvalho Chehab }; 674ad4b21bSMauro Carvalho Chehab 684ad4b21bSMauro Carvalho Chehab 694ad4b21bSMauro Carvalho ChehabThe variable name is a string that describes the driver. It is used in 704ad4b21bSMauro Carvalho Chehabinformational messages printed to the system log. The probe and 714ad4b21bSMauro Carvalho Chehabdisconnect function pointers are called when a device that matches the 720e8c46d0SMauro Carvalho Chehabinformation provided in the ``id_table`` variable is either seen or 734ad4b21bSMauro Carvalho Chehabremoved. 744ad4b21bSMauro Carvalho Chehab 754ad4b21bSMauro Carvalho ChehabThe fops and minor variables are optional. Most USB drivers hook into 764ad4b21bSMauro Carvalho Chehabanother kernel subsystem, such as the SCSI, network or TTY subsystem. 774ad4b21bSMauro Carvalho ChehabThese types of drivers register themselves with the other kernel 784ad4b21bSMauro Carvalho Chehabsubsystem, and any user-space interactions are provided through that 794ad4b21bSMauro Carvalho Chehabinterface. But for drivers that do not have a matching kernel subsystem, 804ad4b21bSMauro Carvalho Chehabsuch as MP3 players or scanners, a method of interacting with user space 814ad4b21bSMauro Carvalho Chehabis needed. The USB subsystem provides a way to register a minor device 820e8c46d0SMauro Carvalho Chehabnumber and a set of :c:type:`file_operations` function pointers that enable 830e8c46d0SMauro Carvalho Chehabthis user-space interaction. The skeleton driver needs this kind of 844ad4b21bSMauro Carvalho Chehabinterface, so it provides a minor starting number and a pointer to its 850e8c46d0SMauro Carvalho Chehab:c:type:`file_operations` functions. 864ad4b21bSMauro Carvalho Chehab 87*33ef2986SPhilipp HortmannThe USB driver is then registered with a call to usb_register(), 880e8c46d0SMauro Carvalho Chehabusually in the driver's init function, as shown here:: 894ad4b21bSMauro Carvalho Chehab 904ad4b21bSMauro Carvalho Chehab static int __init usb_skel_init(void) 914ad4b21bSMauro Carvalho Chehab { 924ad4b21bSMauro Carvalho Chehab int result; 934ad4b21bSMauro Carvalho Chehab 944ad4b21bSMauro Carvalho Chehab /* register this driver with the USB subsystem */ 954ad4b21bSMauro Carvalho Chehab result = usb_register(&skel_driver); 964ad4b21bSMauro Carvalho Chehab if (result < 0) { 974ad4b21bSMauro Carvalho Chehab err("usb_register failed for the "__FILE__ "driver." 984ad4b21bSMauro Carvalho Chehab "Error number %d", result); 994ad4b21bSMauro Carvalho Chehab return -1; 1004ad4b21bSMauro Carvalho Chehab } 1014ad4b21bSMauro Carvalho Chehab 1024ad4b21bSMauro Carvalho Chehab return 0; 1034ad4b21bSMauro Carvalho Chehab } 1044ad4b21bSMauro Carvalho Chehab module_init(usb_skel_init); 1054ad4b21bSMauro Carvalho Chehab 1064ad4b21bSMauro Carvalho Chehab 1074ad4b21bSMauro Carvalho ChehabWhen the driver is unloaded from the system, it needs to deregister 108*33ef2986SPhilipp Hortmannitself with the USB subsystem. This is done with usb_deregister() 1090e8c46d0SMauro Carvalho Chehabfunction:: 1104ad4b21bSMauro Carvalho Chehab 1114ad4b21bSMauro Carvalho Chehab static void __exit usb_skel_exit(void) 1124ad4b21bSMauro Carvalho Chehab { 1134ad4b21bSMauro Carvalho Chehab /* deregister this driver with the USB subsystem */ 1144ad4b21bSMauro Carvalho Chehab usb_deregister(&skel_driver); 1154ad4b21bSMauro Carvalho Chehab } 1164ad4b21bSMauro Carvalho Chehab module_exit(usb_skel_exit); 1174ad4b21bSMauro Carvalho Chehab 1184ad4b21bSMauro Carvalho Chehab 1194ad4b21bSMauro Carvalho ChehabTo enable the linux-hotplug system to load the driver automatically when 1200e8c46d0SMauro Carvalho Chehabthe device is plugged in, you need to create a ``MODULE_DEVICE_TABLE``. 1214ad4b21bSMauro Carvalho ChehabThe following code tells the hotplug scripts that this module supports a 1220e8c46d0SMauro Carvalho Chehabsingle device with a specific vendor and product ID:: 1234ad4b21bSMauro Carvalho Chehab 1244ad4b21bSMauro Carvalho Chehab /* table of devices that work with this driver */ 1254ad4b21bSMauro Carvalho Chehab static struct usb_device_id skel_table [] = { 1264ad4b21bSMauro Carvalho Chehab { USB_DEVICE(USB_SKEL_VENDOR_ID, USB_SKEL_PRODUCT_ID) }, 1274ad4b21bSMauro Carvalho Chehab { } /* Terminating entry */ 1284ad4b21bSMauro Carvalho Chehab }; 1294ad4b21bSMauro Carvalho Chehab MODULE_DEVICE_TABLE (usb, skel_table); 1304ad4b21bSMauro Carvalho Chehab 1314ad4b21bSMauro Carvalho Chehab 1320e8c46d0SMauro Carvalho ChehabThere are other macros that can be used in describing a struct 1330e8c46d0SMauro Carvalho Chehab:c:type:`usb_device_id` for drivers that support a whole class of USB 1340e8c46d0SMauro Carvalho Chehabdrivers. See :ref:`usb.h <usb_header>` for more information on this. 1354ad4b21bSMauro Carvalho Chehab 1364ad4b21bSMauro Carvalho ChehabDevice operation 1374ad4b21bSMauro Carvalho Chehab================ 1384ad4b21bSMauro Carvalho Chehab 1394ad4b21bSMauro Carvalho ChehabWhen a device is plugged into the USB bus that matches the device ID 1404ad4b21bSMauro Carvalho Chehabpattern that your driver registered with the USB core, the probe 1410e8c46d0SMauro Carvalho Chehabfunction is called. The :c:type:`usb_device` structure, interface number and 1420e8c46d0SMauro Carvalho Chehabthe interface ID are passed to the function:: 1434ad4b21bSMauro Carvalho Chehab 1444ad4b21bSMauro Carvalho Chehab static int skel_probe(struct usb_interface *interface, 1454ad4b21bSMauro Carvalho Chehab const struct usb_device_id *id) 1464ad4b21bSMauro Carvalho Chehab 1474ad4b21bSMauro Carvalho Chehab 1484ad4b21bSMauro Carvalho ChehabThe driver now needs to verify that this device is actually one that it 1494ad4b21bSMauro Carvalho Chehabcan accept. If so, it returns 0. If not, or if any error occurs during 1504ad4b21bSMauro Carvalho Chehabinitialization, an errorcode (such as ``-ENOMEM`` or ``-ENODEV``) is 1514ad4b21bSMauro Carvalho Chehabreturned from the probe function. 1524ad4b21bSMauro Carvalho Chehab 1534ad4b21bSMauro Carvalho ChehabIn the skeleton driver, we determine what end points are marked as 1544ad4b21bSMauro Carvalho Chehabbulk-in and bulk-out. We create buffers to hold the data that will be 1554ad4b21bSMauro Carvalho Chehabsent and received from the device, and a USB urb to write data to the 1564ad4b21bSMauro Carvalho Chehabdevice is initialized. 1574ad4b21bSMauro Carvalho Chehab 1584ad4b21bSMauro Carvalho ChehabConversely, when the device is removed from the USB bus, the disconnect 1594ad4b21bSMauro Carvalho Chehabfunction is called with the device pointer. The driver needs to clean 1604ad4b21bSMauro Carvalho Chehabany private data that has been allocated at this time and to shut down 1614ad4b21bSMauro Carvalho Chehabany pending urbs that are in the USB system. 1624ad4b21bSMauro Carvalho Chehab 1634ad4b21bSMauro Carvalho ChehabNow that the device is plugged into the system and the driver is bound 1640e8c46d0SMauro Carvalho Chehabto the device, any of the functions in the :c:type:`file_operations` structure 1654ad4b21bSMauro Carvalho Chehabthat were passed to the USB subsystem will be called from a user program 1664ad4b21bSMauro Carvalho Chehabtrying to talk to the device. The first function called will be open, as 1674ad4b21bSMauro Carvalho Chehabthe program tries to open the device for I/O. We increment our private 1684ad4b21bSMauro Carvalho Chehabusage count and save a pointer to our internal structure in the file 1694ad4b21bSMauro Carvalho Chehabstructure. This is done so that future calls to file operations will 1704ad4b21bSMauro Carvalho Chehabenable the driver to determine which device the user is addressing. All 1710e8c46d0SMauro Carvalho Chehabof this is done with the following code:: 1724ad4b21bSMauro Carvalho Chehab 1734ad4b21bSMauro Carvalho Chehab /* increment our usage count for the module */ 1744ad4b21bSMauro Carvalho Chehab ++skel->open_count; 1754ad4b21bSMauro Carvalho Chehab 1764ad4b21bSMauro Carvalho Chehab /* save our object in the file's private structure */ 1774ad4b21bSMauro Carvalho Chehab file->private_data = dev; 1784ad4b21bSMauro Carvalho Chehab 1794ad4b21bSMauro Carvalho Chehab 1804ad4b21bSMauro Carvalho ChehabAfter the open function is called, the read and write functions are 1810e8c46d0SMauro Carvalho Chehabcalled to receive and send data to the device. In the ``skel_write`` 1824ad4b21bSMauro Carvalho Chehabfunction, we receive a pointer to some data that the user wants to send 1834ad4b21bSMauro Carvalho Chehabto the device and the size of the data. The function determines how much 1844ad4b21bSMauro Carvalho Chehabdata it can send to the device based on the size of the write urb it has 1854ad4b21bSMauro Carvalho Chehabcreated (this size depends on the size of the bulk out end point that 1864ad4b21bSMauro Carvalho Chehabthe device has). Then it copies the data from user space to kernel 1874ad4b21bSMauro Carvalho Chehabspace, points the urb to the data and submits the urb to the USB 1880e8c46d0SMauro Carvalho Chehabsubsystem. This can be seen in the following code:: 1894ad4b21bSMauro Carvalho Chehab 1904ad4b21bSMauro Carvalho Chehab /* we can only write as much as 1 urb will hold */ 1914ad4b21bSMauro Carvalho Chehab bytes_written = (count > skel->bulk_out_size) ? skel->bulk_out_size : count; 1924ad4b21bSMauro Carvalho Chehab 1934ad4b21bSMauro Carvalho Chehab /* copy the data from user space into our urb */ 1944ad4b21bSMauro Carvalho Chehab copy_from_user(skel->write_urb->transfer_buffer, buffer, bytes_written); 1954ad4b21bSMauro Carvalho Chehab 1964ad4b21bSMauro Carvalho Chehab /* set up our urb */ 1974ad4b21bSMauro Carvalho Chehab usb_fill_bulk_urb(skel->write_urb, 1984ad4b21bSMauro Carvalho Chehab skel->dev, 1994ad4b21bSMauro Carvalho Chehab usb_sndbulkpipe(skel->dev, skel->bulk_out_endpointAddr), 2004ad4b21bSMauro Carvalho Chehab skel->write_urb->transfer_buffer, 2014ad4b21bSMauro Carvalho Chehab bytes_written, 2024ad4b21bSMauro Carvalho Chehab skel_write_bulk_callback, 2034ad4b21bSMauro Carvalho Chehab skel); 2044ad4b21bSMauro Carvalho Chehab 2054ad4b21bSMauro Carvalho Chehab /* send the data out the bulk port */ 2064ad4b21bSMauro Carvalho Chehab result = usb_submit_urb(skel->write_urb); 2074ad4b21bSMauro Carvalho Chehab if (result) { 2084ad4b21bSMauro Carvalho Chehab err("Failed submitting write urb, error %d", result); 2094ad4b21bSMauro Carvalho Chehab } 2104ad4b21bSMauro Carvalho Chehab 2114ad4b21bSMauro Carvalho Chehab 2124ad4b21bSMauro Carvalho ChehabWhen the write urb is filled up with the proper information using the 2130e8c46d0SMauro Carvalho Chehab:c:func:`usb_fill_bulk_urb` function, we point the urb's completion callback 2140e8c46d0SMauro Carvalho Chehabto call our own ``skel_write_bulk_callback`` function. This function is 2154ad4b21bSMauro Carvalho Chehabcalled when the urb is finished by the USB subsystem. The callback 2164ad4b21bSMauro Carvalho Chehabfunction is called in interrupt context, so caution must be taken not to 2174ad4b21bSMauro Carvalho Chehabdo very much processing at that time. Our implementation of 2180e8c46d0SMauro Carvalho Chehab``skel_write_bulk_callback`` merely reports if the urb was completed 2194ad4b21bSMauro Carvalho Chehabsuccessfully or not and then returns. 2204ad4b21bSMauro Carvalho Chehab 2214ad4b21bSMauro Carvalho ChehabThe read function works a bit differently from the write function in 2224ad4b21bSMauro Carvalho Chehabthat we do not use an urb to transfer data from the device to the 2230e8c46d0SMauro Carvalho Chehabdriver. Instead we call the :c:func:`usb_bulk_msg` function, which can be used 2244ad4b21bSMauro Carvalho Chehabto send or receive data from a device without having to create urbs and 2250e8c46d0SMauro Carvalho Chehabhandle urb completion callback functions. We call the :c:func:`usb_bulk_msg` 2264ad4b21bSMauro Carvalho Chehabfunction, giving it a buffer into which to place any data received from 2274ad4b21bSMauro Carvalho Chehabthe device and a timeout value. If the timeout period expires without 2284ad4b21bSMauro Carvalho Chehabreceiving any data from the device, the function will fail and return an 2290e8c46d0SMauro Carvalho Chehaberror message. This can be shown with the following code:: 2304ad4b21bSMauro Carvalho Chehab 2314ad4b21bSMauro Carvalho Chehab /* do an immediate bulk read to get data from the device */ 2324ad4b21bSMauro Carvalho Chehab retval = usb_bulk_msg (skel->dev, 2334ad4b21bSMauro Carvalho Chehab usb_rcvbulkpipe (skel->dev, 2344ad4b21bSMauro Carvalho Chehab skel->bulk_in_endpointAddr), 2354ad4b21bSMauro Carvalho Chehab skel->bulk_in_buffer, 2364ad4b21bSMauro Carvalho Chehab skel->bulk_in_size, 2374ad4b21bSMauro Carvalho Chehab &count, HZ*10); 2384ad4b21bSMauro Carvalho Chehab /* if the read was successful, copy the data to user space */ 2394ad4b21bSMauro Carvalho Chehab if (!retval) { 2404ad4b21bSMauro Carvalho Chehab if (copy_to_user (buffer, skel->bulk_in_buffer, count)) 2414ad4b21bSMauro Carvalho Chehab retval = -EFAULT; 2424ad4b21bSMauro Carvalho Chehab else 2434ad4b21bSMauro Carvalho Chehab retval = count; 2444ad4b21bSMauro Carvalho Chehab } 2454ad4b21bSMauro Carvalho Chehab 2464ad4b21bSMauro Carvalho Chehab 2470e8c46d0SMauro Carvalho ChehabThe :c:func:`usb_bulk_msg` function can be very useful for doing single reads 2480e8c46d0SMauro Carvalho Chehabor writes to a device; however, if you need to read or write constantly to 2494ad4b21bSMauro Carvalho Chehaba device, it is recommended to set up your own urbs and submit them to 2504ad4b21bSMauro Carvalho Chehabthe USB subsystem. 2514ad4b21bSMauro Carvalho Chehab 2524ad4b21bSMauro Carvalho ChehabWhen the user program releases the file handle that it has been using to 2534ad4b21bSMauro Carvalho Chehabtalk to the device, the release function in the driver is called. In 2544ad4b21bSMauro Carvalho Chehabthis function we decrement our private usage count and wait for possible 2550e8c46d0SMauro Carvalho Chehabpending writes:: 2564ad4b21bSMauro Carvalho Chehab 2574ad4b21bSMauro Carvalho Chehab /* decrement our usage count for the device */ 2584ad4b21bSMauro Carvalho Chehab --skel->open_count; 2594ad4b21bSMauro Carvalho Chehab 2604ad4b21bSMauro Carvalho Chehab 2614ad4b21bSMauro Carvalho ChehabOne of the more difficult problems that USB drivers must be able to 2624ad4b21bSMauro Carvalho Chehabhandle smoothly is the fact that the USB device may be removed from the 2634ad4b21bSMauro Carvalho Chehabsystem at any point in time, even if a program is currently talking to 2644ad4b21bSMauro Carvalho Chehabit. It needs to be able to shut down any current reads and writes and 2654ad4b21bSMauro Carvalho Chehabnotify the user-space programs that the device is no longer there. The 2660e8c46d0SMauro Carvalho Chehabfollowing code (function ``skel_delete``) is an example of how to do 2670e8c46d0SMauro Carvalho Chehabthis:: 2684ad4b21bSMauro Carvalho Chehab 2694ad4b21bSMauro Carvalho Chehab static inline void skel_delete (struct usb_skel *dev) 2704ad4b21bSMauro Carvalho Chehab { 2714ad4b21bSMauro Carvalho Chehab kfree (dev->bulk_in_buffer); 2724ad4b21bSMauro Carvalho Chehab if (dev->bulk_out_buffer != NULL) 2734ad4b21bSMauro Carvalho Chehab usb_free_coherent (dev->udev, dev->bulk_out_size, 2744ad4b21bSMauro Carvalho Chehab dev->bulk_out_buffer, 2754ad4b21bSMauro Carvalho Chehab dev->write_urb->transfer_dma); 2764ad4b21bSMauro Carvalho Chehab usb_free_urb (dev->write_urb); 2774ad4b21bSMauro Carvalho Chehab kfree (dev); 2784ad4b21bSMauro Carvalho Chehab } 2794ad4b21bSMauro Carvalho Chehab 2804ad4b21bSMauro Carvalho Chehab 2814ad4b21bSMauro Carvalho ChehabIf a program currently has an open handle to the device, we reset the 2824ad4b21bSMauro Carvalho Chehabflag ``device_present``. For every read, write, release and other 2834ad4b21bSMauro Carvalho Chehabfunctions that expect a device to be present, the driver first checks 2844ad4b21bSMauro Carvalho Chehabthis flag to see if the device is still present. If not, it releases 2850e8c46d0SMauro Carvalho Chehabthat the device has disappeared, and a ``-ENODEV`` error is returned to the 2864ad4b21bSMauro Carvalho Chehabuser-space program. When the release function is eventually called, it 2874ad4b21bSMauro Carvalho Chehabdetermines if there is no device and if not, it does the cleanup that 2880e8c46d0SMauro Carvalho Chehabthe ``skel_disconnect`` function normally does if there are no open files 2894ad4b21bSMauro Carvalho Chehabon the device (see Listing 5). 2904ad4b21bSMauro Carvalho Chehab 2914ad4b21bSMauro Carvalho ChehabIsochronous Data 2924ad4b21bSMauro Carvalho Chehab================ 2934ad4b21bSMauro Carvalho Chehab 2944ad4b21bSMauro Carvalho ChehabThis usb-skeleton driver does not have any examples of interrupt or 2954ad4b21bSMauro Carvalho Chehabisochronous data being sent to or from the device. Interrupt data is 2964ad4b21bSMauro Carvalho Chehabsent almost exactly as bulk data is, with a few minor exceptions. 2974ad4b21bSMauro Carvalho ChehabIsochronous data works differently with continuous streams of data being 2984ad4b21bSMauro Carvalho Chehabsent to or from the device. The audio and video camera drivers are very 2994ad4b21bSMauro Carvalho Chehabgood examples of drivers that handle isochronous data and will be useful 3004ad4b21bSMauro Carvalho Chehabif you also need to do this. 3014ad4b21bSMauro Carvalho Chehab 3024ad4b21bSMauro Carvalho ChehabConclusion 3034ad4b21bSMauro Carvalho Chehab========== 3044ad4b21bSMauro Carvalho Chehab 3054ad4b21bSMauro Carvalho ChehabWriting Linux USB device drivers is not a difficult task as the 3064ad4b21bSMauro Carvalho Chehabusb-skeleton driver shows. This driver, combined with the other current 3074ad4b21bSMauro Carvalho ChehabUSB drivers, should provide enough examples to help a beginning author 3084ad4b21bSMauro Carvalho Chehabcreate a working driver in a minimal amount of time. The linux-usb-devel 3094ad4b21bSMauro Carvalho Chehabmailing list archives also contain a lot of helpful information. 3104ad4b21bSMauro Carvalho Chehab 3114ad4b21bSMauro Carvalho ChehabResources 3124ad4b21bSMauro Carvalho Chehab========= 3134ad4b21bSMauro Carvalho Chehab 3144ad4b21bSMauro Carvalho ChehabThe Linux USB Project: 3150e8c46d0SMauro Carvalho Chehabhttp://www.linux-usb.org/ 3164ad4b21bSMauro Carvalho Chehab 3174ad4b21bSMauro Carvalho ChehabLinux Hotplug Project: 3180e8c46d0SMauro Carvalho Chehabhttp://linux-hotplug.sourceforge.net/ 3194ad4b21bSMauro Carvalho Chehab 32019905fe6SJoakim Lönnegrenlinux-usb Mailing List Archives: 32119905fe6SJoakim Lönnegrenhttps://lore.kernel.org/linux-usb/ 3224ad4b21bSMauro Carvalho Chehab 3234ad4b21bSMauro Carvalho ChehabProgramming Guide for Linux USB Device Drivers: 324d3603f4cSAlexander A. Klimovhttps://lmu.web.psi.ch/docu/manuals/software_manuals/linux_sl/usb_linux_programming_guide.pdf 3254ad4b21bSMauro Carvalho Chehab 326d3603f4cSAlexander A. KlimovUSB Home Page: https://www.usb.org 327