Initial import from FreeBSD RELENG_4:
[games.git] / share / man / man4 / usb.4
1 .\" Copyright (c) 1997, 1998
2 .\"     Nick Hibma <n_hibma@FreeBSD.org>. All rights reserved.
3 .\"
4 .\" Redistribution and use in source and binary forms, with or without
5 .\" modification, are permitted provided that the following conditions
6 .\" are met:
7 .\" 1. Redistributions of source code must retain the above copyright
8 .\"    notice, this list of conditions and the following disclaimer.
9 .\" 2. Redistributions in binary form must reproduce the above copyright
10 .\"    notice, this list of conditions and the following disclaimer in the
11 .\"    documentation and/or other materials provided with the distribution.
12 .\" 3. Neither the name of the author nor the names of any co-contributors
13 .\"    may be used to endorse or promote products derived from this software
14 .\"   without specific prior written permission.
15 .\"
16 .\" THIS SOFTWARE IS PROVIDED BY NICK HIBMA AND CONTRIBUTORS ``AS IS'' AND
17 .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
18 .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
19 .\" ARE DISCLAIMED.  IN NO EVENT SHALL NICK HIBMA OR THE VOICES IN HIS HEAD
20 .\" BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
21 .\" CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
22 .\" SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
23 .\" INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
24 .\" CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
25 .\" ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
26 .\" THE POSSIBILITY OF SUCH DAMAGE.
27 .\"
28 .\" $FreeBSD: src/share/man/man4/usb.4,v 1.9.2.10 2002/12/19 20:48:25 trhodes Exp $
29 .\"
30 .Dd February 21, 1999
31 .Dt USB 4
32 .Os
33 .Sh NAME
34 .Nm usb
35 .Nd Universal Serial Bus
36 .Sh SYNOPSIS
37 .Cd "device usb"
38 .Pp
39 .In dev/usb/usb.h
40 .In dev/usb/usbhid.h
41 .Sh DESCRIPTION
42 .Fx
43 provides machine-independent bus support and drivers for
44 .Tn USB
45 devices.
46 .Pp
47 The
48 .Nm
49 driver has three layers: the controller, the bus, and the
50 device layer.
51 The controller attaches to a physical bus
52 (like
53 .Xr pci 4 ) .
54 The
55 .Tn USB
56 bus attaches to the controller, and the root hub attaches
57 to the controller.
58 Any devices attached to the bus will attach to the root hub
59 or another hub attached to the
60 .Tn USB
61 bus.
62 .Pp
63 The
64 .Nm uhub
65 device will always be present as it is needed for the
66 root hub.
67 .Sh INTRODUCTION TO USB
68 The
69 .Tn USB
70 is a 12 Mb/s serial bus (1.5 Mb/s for low speed devices).
71 Each
72 .Tn USB
73 has a host controller that is the master of the bus;
74 all other devices on the bus only speak when spoken to.
75 .Pp
76 There can be up to 127 devices (apart from the host controller)
77 on a bus, each with its own address.
78 The addresses are assigned
79 dynamically by the host when each device is attached to the bus.
80 .Pp
81 Within each device there can be up to 16 endpoints.
82 Each endpoint
83 is individually addressed and the addresses are static.
84 Each of these endpoints will communicate in one of four different modes:
85 .Em control , isochronous , bulk ,
86 or
87 .Em interrupt .
88 A device always has at least one endpoint.
89 This endpoint has address 0 and is a control
90 endpoint and is used to give commands to and extract basic data,
91 such as descriptors, from the device.
92 Each endpoint, except the control endpoint, is unidirectional.
93 .Pp
94 The endpoints in a device are grouped into interfaces.
95 An interface is a logical unit within a device; e.g.\&
96 a compound device with both a keyboard and a trackball would present
97 one interface for each.
98 An interface can sometimes be set into different modes,
99 called alternate settings, which affects how it operates.
100 Different alternate settings can have different endpoints
101 within it.
102 .Pp
103 A device may operate in different configurations.
104 Depending on the
105 configuration, the device may present different sets of endpoints
106 and interfaces.
107 .Pp
108 Each device located on a hub has several
109 .Xr config 8
110 locators:
111 .Bl -tag -compact -width xxxxxx
112 .It Cd port
113 this is the number of the port on the closest upstream hub.
114 .It Cd configuration
115 this is the configuration the device must be in for this driver to attach.
116 This locator does not set the configuration; it is iterated by the bus
117 enumeration.
118 .It Cd interface
119 this is the interface number within a device that an interface driver
120 attaches to.
121 .It Cd vendor
122 this is the 16 bit vendor id of the device.
123 .It Cd product
124 this is the 16 bit product id of the device.
125 .It Cd release
126 this is the 16 bit release (revision) number of the device.
127 .El
128 The first locator can be used to pin down a particular device
129 according to its physical position in the device tree.
130 The last three locators can be used to pin down a particular
131 device according to what device it actually is.
132 .Pp
133 The bus enumeration of the
134 .Tn USB
135 bus proceeds in several steps:
136 .Bl -enum
137 .It
138 Any device specific driver can attach to the device.
139 .It
140 If none is found, any device class specific driver can attach.
141 .It
142 If none is found, all configurations are iterated over.
143 For each configuration, all the interfaces are iterated over, and interface
144 drivers can attach.
145 If any interface driver attached in a certain
146 configuration, the iteration over configurations is stopped.
147 .It
148 If still no drivers have been found, the generic
149 .Tn USB
150 driver can attach.
151 .El
152 .Sh USB CONTROLLER INTERFACE
153 Use the following to get access to the
154 .Tn USB
155 specific structures and defines.
156 .Pp
157 .In dev/usb/usb.h
158 .Pp
159 The
160 .Pa /dev/usb Ns Ar N
161 can be opened and a few operations can be performed on it.
162 The
163 .Xr poll 2
164 system call will say that I/O is possible on the controller device when a
165 .Tn USB
166 device has been connected or disconnected to the bus.
167 .Pp
168 The following
169 .Xr ioctl 2
170 commands are supported on the controller device:
171 .Bl -tag -width xxxxxx
172 .It Dv USB_DISCOVER
173 This command will cause a complete bus discovery to be initiated.
174 If any devices attached or detached from the bus they will be
175 processed during this command.
176 This is the only way that new devices are found on the bus.
177 .It Dv USB_DEVICEINFO Vt "struct usb_device_info"
178 This command can be used to retrieve some information about a device
179 on the bus.
180 The
181 .Va addr
182 field should be filled before the call and the other fields will
183 be filled by information about the device on that address.
184 Should no such device exist, an error is reported.
185 .Bd -literal
186 struct usb_device_info {
187         u_int8_t        bus;
188         u_int8_t        addr;
189         usb_event_cookie_t cookie;
190         char            product[USB_MAX_STRING_LEN];
191         char            vendor[USB_MAX_STRING_LEN];
192         char            release[8];
193         u_int16_t       productNo;
194         u_int16_t       vendorNo;
195         u_int16_t       releaseNo;
196         u_int8_t        class;
197         u_int8_t        subclass;
198         u_int8_t        protocol;
199         u_int8_t        config;
200         u_int8_t        lowspeed;
201         int             power;
202         int             nports;
203         char            devnames[USB_MAX_DEVNAMES][USB_MAX_DEVNAMELEN];
204         u_int8_t        ports[16];
205 #define USB_PORT_ENABLED      0xff
206 #define USB_PORT_SUSPENDED    0xfe
207 #define USB_PORT_POWERED      0xfd
208 #define USB_PORT_DISABLED     0xfc
209 };
210 .Ed
211 .Pp
212 .Va bus
213 and
214 .Va addr
215 contain the topological information for the device.
216 .Va devnames
217 contains the device names of the connected drivers.
218 For example, the
219 third
220 .Tn USB
221 Zip drive connected will be
222 .Li umass2 .
223 The
224 .Va product , vendor
225 and
226 .Va release
227 fields contain self-explanatory descriptions of the device.
228 .Va productNo , vendorNo , releaseNo , class , subclass
229 and
230 .Va protocol
231 contain the corresponding values from the device descriptors.
232 The
233 .Va config
234 field shows the current configuration of the device.
235 .Pp
236 .Va lowspeed
237 indicates whether the device is a full speed (0) or low speed (1)
238 device.
239 The
240 .Va power
241 field shows the power consumption in milli-amps drawn at 5 volts,
242 or zero if the device is self powered.
243 .Pp
244 If the device is a hub, the
245 .Va nports
246 field is non-zero, and the
247 .Va ports
248 field contains the addresses of the connected devices.
249 If no device is connected to a port, one of the
250 .Dv USB_PORT_*
251 values indicates its status.
252 .It Dv USB_DEVICESTATS Vt "struct usb_device_stats"
253 This command retrieves statistics about the controller.
254 .Bd -literal
255 struct usb_device_stats {
256         u_long  requests[4];
257 };
258 .Ed
259 .Pp
260 The
261 .Va requests
262 field is indexed by the transfer kind, i.e.\&
263 .Dv UE_* ,
264 and indicates how many transfers of each kind that has been completed
265 by the controller.
266 .It Dv USB_REQUEST Vt "struct usb_ctl_request"
267 This command can be used to execute arbitrary requests on the control pipe.
268 This is
269 .Em DANGEROUS
270 and should be used with great care since it
271 can destroy the bus integrity.
272 .El
273 .Pp
274 The include file
275 .Aq Pa dev/usb/usb.h
276 contains definitions for the types used by the various
277 .Xr ioctl 2
278 calls.
279 The naming convention of the fields for the various
280 .Tn USB
281 descriptors exactly follows the naming in the
282 .Tn USB
283 specification.
284 Byte sized fields can be accessed directly, but word (16 bit)
285 sized fields must be access by the
286 .Fn UGETW field
287 and
288 .Fn USETW field value
289 macros to handle byte order and alignment properly.
290 .Pp
291 The include file
292 .Aq Pa dev/usb/usbhid.h
293 similarly contains the definitions for
294 Human Interface Devices
295 .Pq Tn HID .
296 .Sh USB EVENT INTERFACE
297 All
298 .Tn USB
299 events are reported via the
300 .Pa /dev/usb
301 device.
302 This devices can be opened for reading and each
303 .Xr read 2
304 will yield an event record (if something has happened).
305 The
306 .Xr poll 2
307 system call can be used to determine if an event record is available
308 for reading.
309 .Pp
310 The event record has the following definition:
311 .Bd -literal
312 struct usb_event {
313         int                                 ue_type;
314 #define USB_EVENT_CTRLR_ATTACH 1
315 #define USB_EVENT_CTRLR_DETACH 2
316 #define USB_EVENT_DEVICE_ATTACH 3
317 #define USB_EVENT_DEVICE_DETACH 4
318 #define USB_EVENT_DRIVER_ATTACH 5
319 #define USB_EVENT_DRIVER_DETACH 6
320         struct timespec                     ue_time;
321         union {
322                 struct {
323                         int                 ue_bus;
324                 } ue_ctrlr;
325                 struct usb_device_info      ue_device;
326                 struct {
327                         usb_event_cookie_t  ue_cookie;
328                         char                ue_devname[16];
329                 } ue_driver;
330         } u;
331 };
332 .Ed
333 The
334 .Va ue_type
335 field identifies the type of event that is described.
336 The possible events are attach/detach of a host controller,
337 a device, or a device driver.
338 The union contains information
339 pertinent to the different types of events.
340 .Pp
341 The
342 .Va ue_bus
343 contains the number of the
344 .Tn USB
345 bus for host controller events.
346 .Pp
347 The
348 .Va ue_device
349 record contains information about the device in a device event event.
350 .Pp
351 The
352 .Va ue_cookie
353 is an opaque value that uniquely determines which which
354 device a device driver has been attached to (i.e., it equals
355 the cookie value in the device that the driver attached to).
356 .Pp
357 The
358 .Va ue_devname
359 contains the name of the device (driver) as seen in, e.g.,
360 kernel messages.
361 .Pp
362 Note that there is a separation between device and device
363 driver events.
364 A device event is generated when a physical
365 .Tn USB
366 device is attached or detached.
367 A single
368 .Tn USB
369 device may
370 have zero, one, or many device drivers associated with it.
371 .Sh SEE ALSO
372 The
373 .Tn USB
374 specifications can be found at:
375 .Pp
376 .D1 Pa http://www.usb.org/developers/docs.html
377 .Pp
378 .Xr aue 4 ,
379 .Xr cue 4 ,
380 .Xr kue 4 ,
381 .Xr ohci 4 ,
382 .Xr pci 4 ,
383 .Xr ucom 4 ,
384 .Xr ugen 4 ,
385 .Xr uhci 4 ,
386 .Xr uhid 4 ,
387 .Xr ukbd 4 ,
388 .Xr ulpt 4 ,
389 .Xr umass 4 ,
390 .Xr ums 4 ,
391 .Xr urio 4 ,
392 .Xr uscanner 4 ,
393 .Xr usbd 8 ,
394 .Xr usbdevs 8
395 .Sh HISTORY
396 The
397 .Nm
398 driver first appeared in
399 .Fx 3.0 .
400 .Sh AUTHORS
401 The
402 .Nm
403 driver was written by
404 .An Lennart Augustsson Aq augustss@carlstedt.se
405 for the
406 .Nx
407 project.