Subject: USB feedback wanted
To: None <tech-kern@NetBSD.ORG, netbsd-developers@NetBSD.ORG>
From: Lennart Augustsson <firstname.lastname@example.org>
Date: 06/28/1998 20:32:29
I've come far enough on my USB driver work that I'd like to
put what I've got into the tree fairly soon (within a month
or two), so I'd really like some feedback. If you are at all
interested please have a look and tell me what you think.
Note that USB is a fairly complicated beast and if you don't
have some basic USB knowledge you can't expect to gain it from
reading my code. :-)
If you want to study the code start at www.carlstedt.se/~augustss/usb.html
Here's an executive summary:
What we have:
* A UHCI (the Intel standard) host controller driver.
+ A OHCI (everyone else's standard) host controller driver.
* A host controller independent framework for handling the
devices. This framework presents a mostly USBDI compliant
interface to the drivers.
+ Support for all kinds of transfers (control, interrupt, bulk,
* Power budgeting.
+ Bandwidth budgeting.
* A hub driver.
* A mouse driver.
* A keyboard driver for keyboards supporting the boot
* A generic HID (Human Interface Device) driver for
those devices that do not have a special driver.
+ A totally generic driver to handle leftover devices.
+ An audio driver.
[The + means work in progress.]
What we don't have:
- Proper handling of devices that are disconnected. NetBSD lacks
the functionality for this.
- Suspend/resume handling. I think this is simply a matter of
sitting down and writing some code.
- A printer class driver.
- A communication class driver.
- Drivers for a lot of proprietary devices.
- Loadable device drivers.
Here's an overview of the code:
The NetBSD USB driver is done in several layers (just like SCSI
The following header files are derived from the USB specs and
are used by kernel and user code.
First we have the host controller layer (cf. SCSI controllers and
PCMCIA controllers). The host controller is responsible for
handling the hardware on the host side. There are two standards
OHCI and UHCI and there is support for both of them. This layer
presents a uniform API for the next layer and also emulates the
The host controller attaches to some bus (most likely PCI) and that
bus attachment is broken out into separate files.
Attaching to the host controller is the USB "bus" (cf. scsibus? and
pcmcia?). The devices (you'll probably only have one) called usb?.
This layer handles all kinds of functionality that is common to all
USB devices, e.g., getting various kind of descriptors, power
budgeting, part of bandwidth budgeting ...
The interface to the device layer follows USBDI (which is the
slowly emerging standard for USB device drivers) fairly well.
Next is the device driver layer (cf. SCSI devices and PCMCIA devices).
It contains code for handling the actual USB devices.
So far there are only a few drivers:
Hub driver. There must always be a hub driver since all USB systems
have at least one hub (the root hub). The hub driver is responsible
for connecting and disconnecting devices and also handles to bus
enumeration and probe/attach. Even though devices physically
attach to a hub the logical attachment is still to `usb?'
Mouse driver. Supports any (reasonable) USB mice.
Not implemented yet: attaching wscons mouse.
Keyboard driver. Supports USB keyboard that speak the boot protocol.
Not implemented yet: attaching wscons keyboard.
Generic HID (Human Interface Device). Handles HID device (mouse,
keyboard, joystick, monitors, LEDs, buttons, game controllers etc.)
that do not have any special driver.
More drivers are on their way.
There are actually two kind of USB devcie driver, device drivers
and interface drivers. A device driver recognizes a USB device as
a whole unit (could be based on product/vendor codes, but could
also just be based on the device class). An interface driver
attaches to a specific interface on a device (of which there may be
many) based on the interface class. The hub driver is a device
driver and the rest are interface drivers. So a physical USB device
which is a keyboard with a built in touch pad would present two
interface and it would get both a keyboard driver and a mouse driver
attached to it.
So this is how the attachment could look
uhci0 at pci0 Host controller
usb0 at uhci0 The "bus"
uhub0 at usb0 Root hub
uhub1 at usb0 Other hub
ums0 at usb0 Mouse
ukbd0 at usb0 Keyboard
uaudio0 at usb0 Speakers
audio0 at uaudio0
uhid0 at usb0 Joystick
uhid1 at usb0 ...
In /dev some new devices are needed:
/dev/usbN The device the usbd demon talks to for
handling connect and disconnect.
/dev/uhidN Generic HID devices, supports reading and
writing to the device as well as ioctl
to get descriptors.
Currently (goes away with wscons) there are also