System Administration Guide: Basic Administration

Overview of USB Devices

Universal Serial Bus (USB) was developed by the PC industry to provide a low-cost solution for attaching peripheral devices, such as keyboards, mouse devices, and printers, to a system.

USB connectors are designed to fit only one type of cable, one way. Devices can connect to hub devices, which connect several devices, including other hub devices. The primary design motivation for USB was to alleviate the need for multiple connector types for different devices. This design reduces the clutter on the back panel of a system. Additional advantages of using USB devices are as follows:

Sun Microsystems support for USB devices includes the following:

This table lists specific USB devices that are supported in the Solaris environment.

USB Devices 

Systems Supported 

HID control on audio devices 

SPARC based and x86 based systems. 

Hubs 

SPARC based and x86 based systems. 

Keyboards and mouse devices 

SPARC based systems with Sun USB support based on the ohci controller.

x86 based systems with a USB bus based on the uhci controller.

Only on-board USB controllers are supported.  

Mass storage devices 

SPARC based and x86 based systems. 

Printers 

SPARC based and x86 based systems. 

Speakers and microphones 

SPARC based and x86 based systems. 

Commonly Used USB Acronyms

The following table describes the USB acronyms that are used in the Solaris environment. For a complete description of USB components and acronyms, go to http://www.usb.org.

Acronym  

Definition 

USB 

Universal Serial Bus 

USBA 

Universal Serial Bus Architecture (Solaris) 

USBAI 

USBA Client Driver Interface (Solaris) 

HCD 

USB host controller driver 

USB Bus Description

The USB specification is openly available and free of royalties. The specification defines the electrical and mechanical interfaces of the bus and the connectors.

USB employs a topology in which hubs provide attachment points for USB devices. The host controller contains the root hub, which is the origin of all USB ports in the system. For more information about hubs, see USB Host Controller and Root Hub.

Figure 29–1 USB Physical Device Hierarchy

Diagram shows a system with three active USB ports that includes a compound device (hub and printer) and composite device (keyboard and mouse).

Figure 29–1 shows a system with three active USB ports. The first USB port has a Zip drive that does not have an embedded hub, so you cannot attach additional devices. The second USB port has a hub with a Jaz drive and a composite keyboard and mouse device connected. One port from the secondary hub has a keyboard with an embedded hub where the mouse is attached.

Figure 29–1 also shows an example of a hub and printer as a compound device. Both the hub and the printer are enclosed in the same plastic case, but the hub and the printer have separate USB bus addresses. The same diagram shows an example of a composite device. The composite keyboard and mouse device are also enclosed in the same plastic case, but they have the same USB bus address. A cable connects the USB mouse to the composite keyboard/controller in this figure.

The device tree path name for some of the devices that are displayed in Figure 29–1 are listed in this table.

Zip drive 

/pci@1f,4000/usb@5/storage@1

Keyboard 

/pci@1f,4000/usb@5/hub@2/device@1/keyboard@0

Mouse 

/pci@1f,4000/usb@5/hub@2/device@1/mouse@1

Jaz drive 

/pci@1f,4000/usb@5/hub@2/storage@3

Printer 

/pci@1f,4000/usb@5/hub@3/printer@1

USB Devices and Drivers

USB devices are divided into device classes. Each device class has a corresponding driver. Devices within a class are managed by the same device driver. However, the USB specification also allows for vendor-specific devices that are not part of a specific class. Devices with similar attributes and services are grouped.

The Human Interface Device (HID) class contains devices that are user-controlled such as keyboards, mouse devices, and joysticks. The Communication Device class contains devices that connect to a telephone, such as modems or an ISDN interface. Other device classes include the Audio, Monitor, Printer, and Storage Device classes. Each USB device contains descriptors that reflect the class of the device. A device class specifies how its members should behave in configuration and data transfer. You can obtain additional class information from the http://www.usb.org site.

Solaris USB Architecture (USBA)

USB devices are represented as two levels of device tree nodes. A device node represents the entire USB device. One or more child interface nodes represent the individual USB interfaces on the device. For special cases, the device nodes and interface nodes are combined into a single combined node.

Driver binding is achieved by using the compatible name properties. For more information, refer to 3.2.2.1 of the IEEE 1275 USB binding and Writing Device Drivers. A driver can either bind to the entire device and control all the interfaces. Or, a driver can bind to just one interface. For example, a keyboard or mouse. If no vendor or class driver claims the entire device, a generic USB multi-interface driver is bound to the device-level node. This driver attempts to bind drivers to each interface by using compatible names properties, as defined in section 3.3.2.1 of the 1275 binding.

The Solaris USB Architecture (USBA) adheres to the USB 1.0 and 1.1 specification plus Solaris driver requirements. The USBA model is similar to Sun Common SCSI Architecture (SCSA). The USBA is a thin layer that provides a generic USB transport-layer abstraction to the client driver.

The differences between SCSA and USBA are that the SCSA relies on .conf files to probe the bus, while USB hub drivers are self-probing nexus drivers.