Chapter 6: Device Drivers
sent always reach their destination unchanged.^24 Devices such as scanners or mass storage
expansions use this mode.
❑ Interrupt transfersare similar to bulk transfers but are repeated at periodic intervals. The interval
length can be freely defined (within certain limits) by the driver. This transfer mode is used by
preference by network cards and similar devices.
❑ A special role is played byisochronous transferas this is the only way of setting up a transfer that
although unreliable makes use of a fixed, pre-defined bandwidth (in certain respects, this mode
can be compared with the datagram technique for network cards as discussed in Chapter 12).
This transfer mode is best used in situations where it is important to guarantee a continuous
data stream and where the occasional loss of data is acceptable. A prime example of where this
mode is used are Webcams that send video data via the USB bus.Managementof Drivers
The USB bus system is implemented in two layers in the kernel.❑ A driver must be available for the host adapter. The adapter must provide a connection option
for the USB chain and assume responsibility for electrical communication with the terminated
devices; the adapter itself must be connected to another system bus (currently, three different
host adapter types called OHCI, EHCI, and UHCI are available; they cover all controller types
offered on the market).
❑ Device drivers communicate with individual USB devices and export their functionality to other
parts of the kernel respectively into userspace. These drivers interact with the host controllers
via a standardized interface so that the controller type is irrelevant to the USB driver. Any
other approach is obviously impractical because it would then be necessary to develop a host
controller-dependent driver for each USB device.Below I shall examine the structure and mode of operation of USB drivers. In doing so, I shall regard the
host controller simply as a transparent interface without discussing the details of its implementation.Although the structure and layout of the USB subsystem are closely based on the USB standard in terms
of the contents of data structures and the names of constants, account must be taken of several subtle
details during the practical development of USB drivers. To keep the following information as concise
as possible, I shall limit our discussion to the core aspects of the USB subsystem. Consequently, I have
‘‘relieved‘‘ the data elements I examine of their less relevant members. Once the structure of the subsys-
tem has become clear, it is a simple matter to look up the corresponding details in the kernel sources.The USB subsystem performs four principal tasks.❑ Registering and managing the device drivers present.
❑ Finding a suitable driver for a USB device plus initialization and configuration.
❑ Representing the device tree in kernel memory.
❑ Communicating with the device (exchanging data).(^24) Assuming, of course, that there are no hardware faults or other effects offorce majeure.