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, in one way. 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.

Devices connect to USB ports on external USB hubs, or on a root hub that is located on the computer itself. Since hubs have several ports, several branches of a device tree can stem from a hub.

For more information, see usba(7D) or go to the following site:

http://www.usb.org

Commonly Used USB Acronyms

The following table describes the USB acronyms that are used in the Solaris OS. For a complete description of USB components and acronyms, go to:

http://www.usb.org

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 Hubs.

Figure 7–1 USB Physical Device Hierarchy

Figure 7–1 shows a system with three active USB ports. The first USB port connects a USB memory stick. The second USB port connects an external hub, which in turn, connects a cdrw device and a composite keyboard/mouse device. As a composite device, this keyboard contains a USB controller, which operates both the keyboard and an attached mouse. The keyboard and the mouse share a common USB bus address because they are directed by the same USB controller.

Figure 7–1 also shows an example of a hub and a printer as a compound device. The hub is an external hub that is enclosed in the same casing as the printer. The printer is permanently connected to the hub. The hub and printer have separate USB bus addresses.

The device tree path name for some of the devices that are displayed in Figure 7–1 are listed here.

Memory stick

/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

cdrw device

/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 with similar attributes and services are grouped into device classes. Each device class has a corresponding driver. Devices within a class are managed by the same device driver pair. However, the USB specification also allows for vendor-specific devices that are not part of a specific class.

The Human Interface Device (HID) class contains devices that are user-controlled such as the following devices:

• Keyboards

• Mouse devices

• Joysticks

The Communication Device class includes the following devices:

• Modems

• Ethernet adapters

Other device classes include the following classes:

• Audio

• Monitor

• Printer

• Storage Device

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:

http://www.usb.org

For more information about USB devices supported in the Solaris release, see usb(7D).

USB Driver Enhancements

The following USB driver enhancements are included.

• USB CDC ACM device support – The acm driver can work with devices that are compliant with the USB Communication Class Device specification's Abstract Control Model and some PCMCIA cards that have modem capabilities.

  The pppd daemon can access these devices through the /dev/term/[0~9]* entries. For more information, see pppd(1M).

  For more information, see usbsacm(7D).

• Generic USB driver – USB devices can now be accessed and manipulated by applications using standard UNIX® read(2) and write(2) system calls, and without writing a special kernel driver. Additional features include:

  • Applications have access to raw device data and device status.

  • The driver supports control, bulk, and interrupt (in and out) transfers.

  Starting in the Solaris 10 6/06 release, the ugen driver no longer needs to bind explicitly to a device. By default, usb_mid binds to devices that lack a class driver and exports a ugen interface that works with libusb. For example, you can plug in a USB camera that is not a mass-storage device and use a libusb application to access it. In addition, both scsa2usb and usbprn drivers export ugen interfaces and libusb applications can be used on these classes of devices directly.

  For more information, refer to ugen(7D).

• USB serial driver support

  • Digi Edgeport USB support – The Edgeport USB driver only works with Edgeport devices and not with other USB serial devices.

    • New devices are accessed as /dev/term/[0-9]* and /dev/cua/[0-9]*.

    • USB serial ports are usable as any other serial port would be, except that they cannot serve as a local serial console. The fact that their data is run through a USB port is transparent to the user.

    For more information, see usbser_edge(7D), or go to the following sites:

    • http://www.digi.com

    • http://www.sun.com/io

  • Keyspan – The Keyspan USB serial driver only works with Keyspan devices, which currently supports the USA-19HS and USA-49WLC models.

    For more information, see usbsksp(7D).

  • Prolific – The Prolific USB serial driver only works with devices based on the PL2303 chipset.

    For more information, see usbsprl(7D).

  For more information about the USB to serial devices support, go to the following site:

  http://www.sun.com/io_technologies/usb/USB-Faq.html

• Documentation and binary support for user-written kernel and userland drivers – For up-to-date information on USB driver development, go to:

  • http://www.sun.com/io_technologies/usb/USB-Faq.html

  • http://developers.sun.com/solaris/developer/support/driver/usb.html

  • Chapter 21, USB Drivers, in Writing Device Drivers

  • Appendix C, Making a Device Driver 64-Bit Ready, in Writing Device Drivers

  • Device Driver Tutorial

  • Intro(7), Intro(9F), and Intro(9S)

  • http://developers.sun.com/prodtech/solaris/driverdev/reference/codesamples/usb_security/index.html

The EHCI, OHCI, and UHCI Drivers

Features of the EHCI driver include:

• Complies with enhanced host controller interface that supports USB 2.0.

• Supports high-speed control, bulk, interrupt, and isochronous transfers.

• The USB 2.0 chip has one EHCI controller and one or more OHCI or UHCI controllers.

• A USB 1.1 device is dynamically assigned to the OHCI or UHCI controller when it is plugged in. A USB 2.0 device is dynamically assigned to the EHCI controller when it is plugged in.

Use the prtconf command output to identify whether your system supports USB 1.1 or USB 2.0 devices. For example:

# prtconf  -D | egrep "ehci|ohci|uhci"

If your prtconf output identifies an EHCI controller, your system supports USB 2.0 devices.

If your prtconf output identifies an OHCI or UHCI controller, your system supports USB 1.1 devices.

Solaris USB Architecture (USBA)

USB devices can be 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.

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 can bind to just one interface. 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 IEEE 1275 binding specification.

The Solaris USB Architecture (USBA) adheres to the USB 1.1 and USB 2.0 specifications and is part of the Solaris Device Driver Interface (DDI). The USBA model is similar to Sun Common SCSI Architecture (SCSA). As the following figure shows, the USBA is a thin layer that provides a generic USB transport-layer abstraction to client drivers, providing them with services that implement core generic USB functionality.

Figure 7–2 Solaris USB Architecture (USBA)