Scribd
Upload
19 views

Device Descriptors

USB host api and device enumeration

Uploaded by

jinyunzhao266
Copyright
© © All Rights Reserved
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
19 views

Device Descriptors

USB host api and device enumeration

Uploaded by

jinyunzhao266
Copyright
© © All Rights Reserved
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
You are on page 1/ 3

Standard Descriptors

A Device Descriptor describes general information about a USB device. It includes


information that applies globally to the device and all of the device s
configurations. A USB device has only one device descriptor.

The Configuration Descriptor gives information about a specific device


configuration. A USB device has one or more configuration descriptors. Each
configuration has one or more interfaces and each interface has zero or more
endpoints. An endpoint is not shared among different interfaces within a single
configuration, although a single interface can have several alternate settings
which may use the same endpoint. Endpoints may be shared among interfaces that are
part of different configurations without this restriction. Configurations can only
be activated by the standard control transfer set_configuration. Different
configurations can be used to change global device settings, such as power
consumption.

An Interface Descriptor describes a specific interface within a configuration. A


configuration provides one or more interfaces, each with zero or more endpoint
descriptors describing a unique set of endpoints within the configuration. An
interface may include alternate settings that allow the endpoints and/or their
characteristics to be varied after the device has been configured. The default
setting for an interface is always alternate setting zero. Alternate settings can
be selected exclusively by the standard control transfer set_interface. For example
a multifunctional device like a video camera with internal microphone could have
three alternate settings to change the bandwidth allocation on the bus.

Camera activated
Microphone activated
Camera and microphone activated
An Endpoint Descriptor contains information required by the host to determine the
bandwidth requirements of each endpoint. An endpoint represents a logical data
source or sink of a USB device. The endpoint zero is used for all control transfers
and there is never a descriptor for this endpoint. The USB specification uses the
terms pipe and endpoint interchangably.

String Descriptors are optional and provide additional information in human


readable unicode format. They can be used for vendor and device names or serial
numbers.

Device Classes
The standard device and interface descriptors contain fields that are related to
classification: class, sub-class and protocol. These fields may be used by a host
system to associate a device or interface to a driver, depending on how they are
specified by the class specification. Valid values for the class fields of the
device and interface descriptors are defined by the USB Device Working Group.

Grouping devices or interfaces together in classes and then specifying the


characteristics in a Class Specification allows the development of host software
which can manage multiple implementations based on that class. Such host software
adapts its operation to a specific device or interface using descriptive
information presented by the device. A class specification serves as a framework
defining the minimum operation of all devices or interfaces which identify
themselves as members of the class.

Human Interface Devices (HID)


The HID class consists primarily of devices that are used by humans to control the
operation of computer systems. Typical examples of HID class devices include:
Keyboards and pointing devices for example, standard mouse devices, trackballs, and
joysticks.
Front-panel controls for example: knobs, switches, buttons, and sliders.
Controls that might be found on devices such as telephones, VCR remote controls,
games or simulation devices for example: data gloves, throttles, steering wheels,
and rudder pedals.

Introduction to USB on Linux


A Universal Serial Bus (USB) is used to connect a host, such as a PC or
workstation, to a number of peripheral devices. USB uses a tree structure, with the
host as the root (the system’s master), hubs as interior nodes, and peripherals as
leaves (and slaves). Modern PCs support several such trees of USB devices, usually
a few USB 3.0 (5 GBit/s) or USB 3.1 (10 GBit/s) and some legacy USB 2.0 (480
MBit/s) busses just in case.

That master/slave asymmetry was designed-in for a number of reasons, one being ease
of use. It is not physically possible to mistake upstream and downstream or it does
not matter with a type C plug (or they are built into the peripheral). Also, the
host software doesn’t need to deal with distributed auto-configuration since the
pre-designated master node manages all that.

Kernel developers added USB support to Linux early in the 2.2 kernel series and
have been developing it further since then. Besides support for each new generation
of USB, various host controllers gained support, new drivers for peripherals have
been added and advanced features for latency measurement and improved power
management introduced.

Linux can run inside USB devices as well as on the hosts that control the devices.
But USB device drivers running inside those peripherals don’t do the same things as
the ones running inside hosts, so they’ve been given a different name: gadget
drivers. This document does not cover gadget drivers.

USB Host-Side API Model


Host-side drivers for USB devices talk to the “usbcore” APIs. There are two. One is
intended for general-purpose drivers (exposed through driver frameworks), and the
other is for drivers that are part of the core. Such core drivers include the hub
driver (which manages trees of USB devices) and several different kinds of host
controller drivers, which control individual busses.

The device model seen by USB drivers is relatively complex.

USB supports four kinds of data transfers (control, bulk, interrupt, and
isochronous). Two of them (control and bulk) use bandwidth as it’s available, while
the other two (interrupt and isochronous) are scheduled to provide guaranteed
bandwidth.

The device description model includes one or more “configurations” per device, only
one of which is active at a time. Devices are supposed to be capable of operating
at lower than their top speeds and may provide a BOS descriptor showing the lowest
speed they remain fully operational at.

From USB 3.0 on configurations have one or more “functions”, which provide a common
functionality and are grouped together for purposes of power management.

Configurations or functions have one or more “interfaces”, each of which may have
“alternate settings”. Interfaces may be standardized by USB “Class” specifications,
or may be specific to a vendor or device.

USB device drivers actually bind to interfaces, not devices. Think of them as
“interface drivers”, though you may not see many devices where the distinction is
important. Most USB devices are simple, with only one function, one configuration,
one interface, and one alternate setting.

Interfaces have one or more “endpoints”, each of which supports one type and
direction of data transfer such as “bulk out” or “interrupt in”. The entire
configuration may have up to sixteen endpoints in each direction, allocated as
needed among all the interfaces.

Data transfer on USB is packetized; each endpoint has a maximum packet size.
Drivers must often be aware of conventions such as flagging the end of bulk
transfers using “short” (including zero length) packets.

The Linux USB API supports synchronous calls for control and bulk messages. It also
supports asynchronous calls for all kinds of data transfer, using request
structures called “URBs” (USB Request Blocks).

Accordingly, the USB Core API exposed to device drivers covers quite a lot of
territory. You’ll probably need to consult the USB 3.0 specification, available
online from www.usb.org at no cost, as well as class or device specifications.

The only host-side drivers that actually touch hardware (reading/writing registers,
handling IRQs, and so on) are the HCDs. In theory, all HCDs provide the same
functionality through the same API. In practice, that’s becoming more true, but
there are still differences that crop up especially with fault handling on the less
common controllers. Different controllers don’t necessarily report the same aspects
of failures, and recovery from faults (including software-induced ones like
unlinking an URB) isn’t yet fully consistent. Device driver authors should make a
point of doing disconnect testing (while the device is active) with each different
host controller driver, to make sure drivers don’t have bugs of their own as well
as to make sure they aren’t relying on some HCD-specific behavior.

You might also like