1 <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook V3.1//EN"[]>
2 <book id="USB-Gadget-API">
4 <title>USB Gadget API for Linux</title>
5 <date>20 August 2004</date>
6 <edition>20 August 2004</edition>
10 This documentation is free software; you can redistribute
11 it and/or modify it under the terms of the GNU General Public
12 License as published by the Free Software Foundation; either
13 version 2 of the License, or (at your option) any later
18 This program is distributed in the hope that it will be
19 useful, but WITHOUT ANY WARRANTY; without even the implied
20 warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
21 See the GNU General Public License for more details.
25 You should have received a copy of the GNU General Public
26 License along with this program; if not, write to the Free
27 Software Foundation, Inc., 59 Temple Place, Suite 330, Boston,
32 For more details see the file COPYING in the source
33 distribution of Linux.
37 <year>2003-2004</year>
38 <holder>David Brownell</holder>
42 <firstname>David</firstname>
43 <surname>Brownell</surname>
45 <address><email>dbrownell@users.sourceforge.net</email></address>
52 <chapter><title>Introduction</title>
54 <para>This document presents a Linux-USB "Gadget"
56 API, for use within peripherals and other USB devices
58 It provides an overview of the API structure,
59 and shows how that fits into a system development project.
60 This is the first such API released on Linux to address
61 a number of important problems, including: </para>
64 <listitem><para>Supports USB 2.0, for high speed devices which
65 can stream data at several dozen megabytes per second.
67 <listitem><para>Handles devices with dozens of endpoints just as
68 well as ones with just two fixed-function ones. Gadget drivers
69 can be written so they're easy to port to new hardware.
71 <listitem><para>Flexible enough to expose more complex USB device
72 capabilities such as multiple configurations, multiple interfaces,
74 and alternate interface settings.
76 <listitem><para>USB "On-The-Go" (OTG) support, in conjunction
77 with updates to the Linux-USB host side.
79 <listitem><para>Sharing data structures and API models with the
80 Linux-USB host side API. This helps the OTG support, and
81 looks forward to more-symmetric frameworks (where the same
82 I/O model is used by both host and device side drivers).
84 <listitem><para>Minimalist, so it's easier to support new device
85 controller hardware. I/O processing doesn't imply large
86 demands for memory or CPU resources.
91 <para>Most Linux developers will not be able to use this API, since they
92 have USB "host" hardware in a PC, workstation, or server.
93 Linux users with embedded systems are more likely to
94 have USB peripheral hardware.
95 To distinguish drivers running inside such hardware from the
96 more familiar Linux "USB device drivers",
97 which are host side proxies for the real USB devices,
98 a different term is used:
99 the drivers inside the peripherals are "USB gadget drivers".
100 In USB protocol interactions, the device driver is the master
102 and the gadget driver is the slave (or "function driver").
105 <para>The gadget API resembles the host side Linux-USB API in that both
106 use queues of request objects to package I/O buffers, and those requests
107 may be submitted or canceled.
108 They share common definitions for the standard USB
109 <emphasis>Chapter 9</emphasis> messages, structures, and constants.
110 Also, both APIs bind and unbind drivers to devices.
111 The APIs differ in detail, since the host side's current
112 URB framework exposes a number of implementation details
113 and assumptions that are inappropriate for a gadget API.
114 While the model for control transfers and configuration
115 management is necessarily different (one side is a hardware-neutral master,
116 the other is a hardware-aware slave), the endpoint I/0 API used here
117 should also be usable for an overhead-reduced host side API.
122 <chapter id="structure"><title>Structure of Gadget Drivers</title>
124 <para>A system running inside a USB peripheral
125 normally has at least three layers inside the kernel to handle
126 USB protocol processing, and may have additional layers in
128 The "gadget" API is used by the middle layer to interact
129 with the lowest level (which directly handles hardware).
132 <para>In Linux, from the bottom up, these layers are:
138 <term><emphasis>USB Controller Driver</emphasis></term>
141 <para>This is the lowest software level.
142 It is the only layer that talks to hardware,
143 through registers, fifos, dma, irqs, and the like.
144 The <filename><linux/usb_gadget.h></filename> API abstracts
145 the peripheral controller endpoint hardware.
146 That hardware is exposed through endpoint objects, which accept
147 streams of IN/OUT buffers, and through callbacks that interact
149 Since normal USB devices only have one upstream
150 port, they only have one of these drivers.
151 The controller driver can support any number of different
152 gadget drivers, but only one of them can be used at a time.
155 <para>Examples of such controller hardware include
156 the PCI-based NetChip 2280 USB 2.0 high speed controller,
157 the SA-11x0 or PXA-25x UDC (found within many PDAs),
158 and a variety of other products.
161 </listitem></varlistentry>
164 <term><emphasis>Gadget Driver</emphasis></term>
167 <para>The lower boundary of this driver implements hardware-neutral
168 USB functions, using calls to the controller driver.
169 Because such hardware varies widely in capabilities and restrictions,
170 and is used in embedded environments where space is at a premium,
171 the gadget driver is often configured at compile time
172 to work with endpoints supported by one particular controller.
173 Gadget drivers may be portable to several different controllers,
174 using conditional compilation.
175 (Recent kernels substantially simplify the work involved in
176 supporting new hardware, by <emphasis>autoconfiguring</emphasis>
177 endpoints automatically for many bulk-oriented drivers.)
178 Gadget driver responsibilities include:
181 <listitem><para>handling setup requests (ep0 protocol responses)
182 possibly including class-specific functionality
184 <listitem><para>returning configuration and string descriptors
186 <listitem><para>(re)setting configurations and interface
187 altsettings, including enabling and configuring endpoints
189 <listitem><para>handling life cycle events, such as managing
190 bindings to hardware,
191 USB suspend/resume, remote wakeup,
192 and disconnection from the USB host.
194 <listitem><para>managing IN and OUT transfers on all currently
200 Such drivers may be modules of proprietary code, although
201 that approach is discouraged in the Linux community.
203 </listitem></varlistentry>
206 <term><emphasis>Upper Level</emphasis></term>
209 <para>Most gadget drivers have an upper boundary that connects
210 to some Linux driver or framework in Linux.
211 Through that boundary flows the data which the gadget driver
212 produces and/or consumes through protocol transfers over USB.
216 <listitem><para>user mode code, using generic (gadgetfs)
217 or application specific files in
218 <filename>/dev</filename>
220 <listitem><para>networking subsystem (for network gadgets,
221 like the CDC Ethernet Model gadget driver)
223 <listitem><para>data capture drivers, perhaps video4Linux or
224 a scanner driver; or test and measurement hardware.
226 <listitem><para>input subsystem (for HID gadgets)
228 <listitem><para>sound subsystem (for audio gadgets)
230 <listitem><para>file system (for PTP gadgets)
232 <listitem><para>block i/o subsystem (for usb-storage gadgets)
234 <listitem><para>... and more </para></listitem>
236 </listitem></varlistentry>
239 <term><emphasis>Additional Layers</emphasis></term>
242 <para>Other layers may exist.
243 These could include kernel layers, such as network protocol stacks,
244 as well as user mode applications building on standard POSIX
245 system call APIs such as
246 <emphasis>open()</emphasis>, <emphasis>close()</emphasis>,
247 <emphasis>read()</emphasis> and <emphasis>write()</emphasis>.
248 On newer systems, POSIX Async I/O calls may be an option.
249 Such user mode code will not necessarily be subject to
250 the GNU General Public License (GPL).
252 </listitem></varlistentry>
257 <para>OTG-capable systems will also need to include a standard Linux-USB
259 with <emphasis>usbcore</emphasis>,
260 one or more <emphasis>Host Controller Drivers</emphasis> (HCDs),
261 <emphasis>USB Device Drivers</emphasis> to support
262 the OTG "Targeted Peripheral List",
264 There will also be an <emphasis>OTG Controller Driver</emphasis>,
265 which is visible to gadget and device driver developers only indirectly.
266 That helps the host and device side USB controllers implement the
267 two new OTG protocols (HNP and SRP).
268 Roles switch (host to peripheral, or vice versa) using HNP
269 during USB suspend processing, and SRP can be viewed as a
270 more battery-friendly kind of device wakeup protocol.
273 <para>Over time, reusable utilities are evolving to help make some
274 gadget driver tasks simpler.
275 For example, building configuration descriptors from vectors of
276 descriptors for the configurations interfaces and endpoints is
277 now automated, and many drivers now use autoconfiguration to
278 choose hardware endpoints and initialize their descriptors.
280 A potential example of particular interest
281 is code implementing standard USB-IF protocols for
282 HID, networking, storage, or audio classes.
283 Some developers are interested in KDB or KGDB hooks, to let
284 target hardware be remotely debugged.
285 Most such USB protocol code doesn't need to be hardware-specific,
286 any more than network protocols like X11, HTTP, or NFS are.
287 Such gadget-side interface drivers should eventually be combined,
288 to implement composite devices.
294 <chapter id="api"><title>Kernel Mode Gadget API</title>
296 <para>Gadget drivers declare themselves through a
297 <emphasis>struct usb_gadget_driver</emphasis>, which is responsible for
298 most parts of enumeration for a <emphasis>struct usb_gadget</emphasis>.
299 The response to a set_configuration usually involves
300 enabling one or more of the <emphasis>struct usb_ep</emphasis> objects
301 exposed by the gadget, and submitting one or more
302 <emphasis>struct usb_request</emphasis> buffers to transfer data.
303 Understand those four data types, and their operations, and
304 you will understand how this API works.
307 <note><title>Incomplete Data Type Descriptions</title>
309 <para>This documentation was prepared using the standard Linux
310 kernel <filename>docproc</filename> tool, which turns text
311 and in-code comments into SGML DocBook and then into usable
312 formats such as HTML or PDF.
313 Other than the "Chapter 9" data types, most of the significant
314 data types and functions are described here.
317 <para>However, docproc does not understand all the C constructs
318 that are used, so some relevant information is likely omitted from
319 what you are reading.
320 One example of such information is endpoint autoconfiguration.
321 You'll have to read the header file, and use example source
322 code (such as that for "Gadget Zero"), to fully understand the API.
325 <para>The part of the API implementing some basic
326 driver capabilities is specific to the version of the
327 Linux kernel that's in use.
328 The 2.6 kernel includes a <emphasis>driver model</emphasis>
329 framework that has no analogue on earlier kernels;
330 so those parts of the gadget API are not fully portable.
331 (They are implemented on 2.4 kernels, but in a different way.)
332 The driver model state is another part of this API that is
333 ignored by the kerneldoc tools.
337 <para>The core API does not expose
338 every possible hardware feature, only the most widely available ones.
339 There are significant hardware features, such as device-to-device DMA
340 (without temporary storage in a memory buffer)
341 that would be added using hardware-specific APIs.
344 <para>This API allows drivers to use conditional compilation to handle
345 endpoint capabilities of different hardware, but doesn't require that.
346 Hardware tends to have arbitrary restrictions, relating to
347 transfer types, addressing, packet sizes, buffering, and availability.
348 As a rule, such differences only matter for "endpoint zero" logic
349 that handles device configuration and management.
350 The API supports limited run-time
351 detection of capabilities, through naming conventions for endpoints.
352 Many drivers will be able to at least partially autoconfigure
354 In particular, driver init sections will often have endpoint
355 autoconfiguration logic that scans the hardware's list of endpoints
356 to find ones matching the driver requirements
357 (relying on those conventions), to eliminate some of the most
358 common reasons for conditional compilation.
361 <para>Like the Linux-USB host side API, this API exposes
362 the "chunky" nature of USB messages: I/O requests are in terms
363 of one or more "packets", and packet boundaries are visible to drivers.
364 Compared to RS-232 serial protocols, USB resembles
365 synchronous protocols like HDLC
366 (N bytes per frame, multipoint addressing, host as the primary
367 station and devices as secondary stations)
368 more than asynchronous ones
369 (tty style: 8 data bits per frame, no parity, one stop bit).
370 So for example the controller drivers won't buffer
371 two single byte writes into a single two-byte USB IN packet,
372 although gadget drivers may do so when they implement
373 protocols where packet boundaries (and "short packets")
377 <sect1 id="lifecycle"><title>Driver Life Cycle</title>
379 <para>Gadget drivers make endpoint I/O requests to hardware without
380 needing to know many details of the hardware, but driver
381 setup/configuration code needs to handle some differences.
382 Use the API like this:
385 <orderedlist numeration='arabic'>
387 <listitem><para>Register a driver for the particular device side
388 usb controller hardware,
389 such as the net2280 on PCI (USB 2.0),
390 sa11x0 or pxa25x as found in Linux PDAs,
392 At this point the device is logically in the USB ch9 initial state
393 ("attached"), drawing no power and not usable
394 (since it does not yet support enumeration).
395 Any host should not see the device, since it's not
396 activated the data line pullup used by the host to
397 detect a device, even if VBUS power is available.
400 <listitem><para>Register a gadget driver that implements some higher level
401 device function. That will then bind() to a usb_gadget, which
402 activates the data line pullup sometime after detecting VBUS.
405 <listitem><para>The hardware driver can now start enumerating.
406 The steps it handles are to accept USB power and set_address requests.
407 Other steps are handled by the gadget driver.
408 If the gadget driver module is unloaded before the host starts to
409 enumerate, steps before step 7 are skipped.
412 <listitem><para>The gadget driver's setup() call returns usb descriptors,
413 based both on what the bus interface hardware provides and on the
414 functionality being implemented.
415 That can involve alternate settings or configurations,
416 unless the hardware prevents such operation.
417 For OTG devices, each configuration descriptor includes
421 <listitem><para>The gadget driver handles the last step of enumeration,
422 when the USB host issues a set_configuration call.
423 It enables all endpoints used in that configuration,
424 with all interfaces in their default settings.
425 That involves using a list of the hardware's endpoints, enabling each
426 endpoint according to its descriptor.
427 It may also involve using <function>usb_gadget_vbus_draw</function>
428 to let more power be drawn from VBUS, as allowed by that configuration.
429 For OTG devices, setting a configuration may also involve reporting
430 HNP capabilities through a user interface.
433 <listitem><para>Do real work and perform data transfers, possibly involving
434 changes to interface settings or switching to new configurations, until the
435 device is disconnect()ed from the host.
436 Queue any number of transfer requests to each endpoint.
437 It may be suspended and resumed several times before being disconnected.
438 On disconnect, the drivers go back to step 3 (above).
441 <listitem><para>When the gadget driver module is being unloaded,
442 the driver unbind() callback is issued. That lets the controller
448 <para>Drivers will normally be arranged so that just loading the
449 gadget driver module (or statically linking it into a Linux kernel)
450 allows the peripheral device to be enumerated, but some drivers
451 will defer enumeration until some higher level component (like
452 a user mode daemon) enables it.
453 Note that at this lowest level there are no policies about how
454 ep0 configuration logic is implemented,
455 except that it should obey USB specifications.
456 Such issues are in the domain of gadget drivers,
457 including knowing about implementation constraints
458 imposed by some USB controllers
459 or understanding that composite devices might happen to
460 be built by integrating reusable components.
463 <para>Note that the lifecycle above can be slightly different
465 Other than providing an additional OTG descriptor in each
466 configuration, only the HNP-related differences are particularly
467 visible to driver code.
468 They involve reporting requirements during the SET_CONFIGURATION
469 request, and the option to invoke HNP during some suspend callbacks.
470 Also, SRP changes the semantics of
471 <function>usb_gadget_wakeup</function>
477 <sect1 id="ch9"><title>USB 2.0 Chapter 9 Types and Constants</title>
480 rely on common USB structures and constants
482 <filename><linux/usb_ch9.h></filename>
483 header file, which is standard in Linux 2.6 kernels.
484 These are the same types and constants used by host
485 side drivers (and usbcore).
488 !Iinclude/linux/usb_ch9.h
491 <sect1 id="core"><title>Core Objects and Methods</title>
493 <para>These are declared in
494 <filename><linux/usb_gadget.h></filename>,
495 and are used by gadget drivers to interact with
496 USB peripheral controller drivers.
499 <!-- yeech, this is ugly in nsgmls PDF output.
501 the PDF bookmark and refentry output nesting is wrong,
502 and the member/argument documentation indents ugly.
504 plus something (docproc?) adds whitespace before the
505 descriptive paragraph text, so it can't line up right
506 unless the explanations are trivial.
509 !Iinclude/linux/usb_gadget.h
512 <sect1 id="utils"><title>Optional Utilities</title>
514 <para>The core API is sufficient for writing a USB Gadget Driver,
515 but some optional utilities are provided to simplify common tasks.
516 These utilities include endpoint autoconfiguration.
519 !Edrivers/usb/gadget/usbstring.c
520 !Edrivers/usb/gadget/config.c
521 <!-- !Edrivers/usb/gadget/epautoconf.c -->
526 <chapter id="controllers"><title>Peripheral Controller Drivers</title>
528 <para>The first hardware supporting this API was the NetChip 2280
529 controller, which supports USB 2.0 high speed and is based on PCI.
530 This is the <filename>net2280</filename> driver module.
531 The driver supports Linux kernel versions 2.4 and 2.6;
532 contact NetChip Technologies for development boards and product
536 <para>Other hardware working in the "gadget" framework includes:
537 Intel's PXA 25x and IXP42x series processors
538 (<filename>pxa2xx_udc</filename>),
539 Toshiba TC86c001 "Goku-S" (<filename>goku_udc</filename>),
540 Renesas SH7705/7727 (<filename>sh_udc</filename>),
541 MediaQ 11xx (<filename>mq11xx_udc</filename>),
542 Hynix HMS30C7202 (<filename>h7202_udc</filename>),
543 National 9303/4 (<filename>n9604_udc</filename>),
544 Texas Instruments OMAP (<filename>omap_udc</filename>),
545 Sharp LH7A40x (<filename>lh7a40x_udc</filename>),
547 Most of those are full speed controllers.
550 <para>At this writing, there are people at work on drivers in
551 this framework for several other USB device controllers,
552 with plans to make many of them be widely available.
555 <!-- !Edrivers/usb/gadget/net2280.c -->
557 <para>A partial USB simulator,
558 the <filename>dummy_hcd</filename> driver, is available.
559 It can act like a net2280, a pxa25x, or an sa11x0 in terms
560 of available endpoints and device speeds; and it simulates
561 control, bulk, and to some extent interrupt transfers.
562 That lets you develop some parts of a gadget driver on a normal PC,
563 without any special hardware, and perhaps with the assistance
564 of tools such as GDB running with User Mode Linux.
565 At least one person has expressed interest in adapting that
566 approach, hooking it up to a simulator for a microcontroller.
567 Such simulators can help debug subsystems where the runtime hardware
568 is unfriendly to software development, or is not yet available.
571 <para>Support for other controllers is expected to be developed
573 over time, as this driver framework evolves.
578 <chapter id="gadget"><title>Gadget Drivers</title>
580 <para>In addition to <emphasis>Gadget Zero</emphasis>
581 (used primarily for testing and development with drivers
582 for usb controller hardware), other gadget drivers exist.
585 <para>There's an <emphasis>ethernet</emphasis> gadget
586 driver, which implements one of the most useful
587 <emphasis>Communications Device Class</emphasis> (CDC) models.
588 One of the standards for cable modem interoperability even
589 specifies the use of this ethernet model as one of two
591 Gadgets using this code look to a USB host as if they're
593 It provides access to a network where the gadget's CPU is one host,
594 which could easily be bridging, routing, or firewalling
595 access to other networks.
596 Since some hardware can't fully implement the CDC Ethernet
597 requirements, this driver also implements a "good parts only"
598 subset of CDC Ethernet.
599 (That subset doesn't advertise itself as CDC Ethernet,
600 to avoid creating problems.)
603 <para>Support for Microsoft's <emphasis>RNDIS</emphasis>
604 protocol has been contributed by Pengutronix and Auerswald GmbH.
605 This is like CDC Ethernet, but it runs on more slightly USB hardware
606 (but less than the CDC subset).
607 However, its main claim to fame is being able to connect directly to
608 recent versions of Windows, using drivers that Microsoft bundles
609 and supports, making it much simpler to network with Windows.
612 <para>There is also support for user mode gadget drivers,
613 using <emphasis>gadgetfs</emphasis>.
614 This provides a <emphasis>User Mode API</emphasis> that presents
615 each endpoint as a single file descriptor. I/O is done using
616 normal <emphasis>read()</emphasis> and <emphasis>read()</emphasis> calls.
617 Familiar tools like GDB and pthreads can be used to
618 develop and debug user mode drivers, so that once a robust
619 controller driver is available many applications for it
620 won't require new kernel mode software.
621 Linux 2.6 <emphasis>Async I/O (AIO)</emphasis>
622 support is available, so that user mode software
623 can stream data with only slightly more overhead
624 than a kernel driver.
627 <para>There's a USB Mass Storage class driver, which provides
628 a different solution for interoperability with systems such
629 as MS-Windows and MacOS.
630 That <emphasis>File-backed Storage</emphasis> driver uses a
631 file or block device as backing store for a drive,
632 like the <filename>loop</filename> driver.
633 The USB host uses the BBB, CB, or CBI versions of the mass
634 storage class specification, using transparent SCSI commands
635 to access the data from the backing store.
638 <para>There's a "serial line" driver, useful for TTY style
640 The latest version of that driver supports CDC ACM style
641 operation, like a USB modem, and so on most hardware it can
642 interoperate easily with MS-Windows.
643 One interesting use of that driver is in boot firmware (like a BIOS),
644 which can sometimes use that model with very small systems without
648 <para>Support for other kinds of gadget is expected to
649 be developed and contributed
650 over time, as this driver framework evolves.
655 <chapter id="otg"><title>USB On-The-GO (OTG)</title>
657 <para>USB OTG support on Linux 2.6 was initially developed
658 by Texas Instruments for
659 <ulink url="http://www.omap.com">OMAP</ulink> 16xx and 17xx
661 Other OTG systems should work in similar ways, but the
662 hardware level details could be very different.
665 <para>Systems need specialized hardware support to implement OTG,
666 notably including a special <emphasis>Mini-AB</emphasis> jack
667 and associated transciever to support <emphasis>Dual-Role</emphasis>
669 they can act either as a host, using the standard
670 Linux-USB host side driver stack,
671 or as a peripheral, using this "gadget" framework.
672 To do that, the system software relies on small additions
673 to those programming interfaces,
674 and on a new internal component (here called an "OTG Controller")
675 affecting which driver stack connects to the OTG port.
676 In each role, the system can re-use the existing pool of
677 hardware-neutral drivers, layered on top of the controller
678 driver interfaces (<emphasis>usb_bus</emphasis> or
679 <emphasis>usb_gadget</emphasis>).
680 Such drivers need at most minor changes, and most of the calls
681 added to support OTG can also benefit non-OTG products.
685 <listitem><para>Gadget drivers test the <emphasis>is_otg</emphasis>
686 flag, and use it to determine whether or not to include
687 an OTG descriptor in each of their configurations.
689 <listitem><para>Gadget drivers may need changes to support the
690 two new OTG protocols, exposed in new gadget attributes
691 such as <emphasis>b_hnp_enable</emphasis> flag.
692 HNP support should be reported through a user interface
693 (two LEDs could suffice), and is triggered in some cases
694 when the host suspends the peripheral.
695 SRP support can be user-initiated just like remote wakeup,
696 probably by pressing the same button.
698 <listitem><para>On the host side, USB device drivers need
699 to be taught to trigger HNP at appropriate moments, using
700 <function>usb_suspend_device()</function>.
701 That also conserves battery power, which is useful even
702 for non-OTG configurations.
704 <listitem><para>Also on the host side, a driver must support the
705 OTG "Targeted Peripheral List". That's just a whitelist,
706 used to reject peripherals not supported with a given
708 <emphasis>This whitelist is product-specific;
709 each product must modify <filename>otg_whitelist.h</filename>
710 to match its interoperability specification.
713 <para>Non-OTG Linux hosts, like PCs and workstations,
714 normally have some solution for adding drivers, so that
715 peripherals that aren't recognized can eventually be supported.
716 That approach is unreasonable for consumer products that may
717 never have their firmware upgraded, and where it's usually
718 unrealistic to expect traditional PC/workstation/server kinds
719 of support model to work.
720 For example, it's often impractical to change device firmware
721 once the product has been distributed, so driver bugs can't
722 normally be fixed if they're found after shipment.
727 Additional changes are needed below those hardware-neutral
728 <emphasis>usb_bus</emphasis> and <emphasis>usb_gadget</emphasis>
729 driver interfaces; those aren't discussed here in any detail.
730 Those affect the hardware-specific code for each USB Host or Peripheral
731 controller, and how the HCD initializes (since OTG can be active only
733 They also involve what may be called an <emphasis>OTG Controller
734 Driver</emphasis>, managing the OTG transceiver and the OTG state
735 machine logic as well as much of the root hub behavior for the
737 The OTG controller driver needs to activate and deactivate USB
738 controllers depending on the relevant device role.
739 Some related changes were needed inside usbcore, so that it
740 can identify OTG-capable devices and respond appropriately
741 to HNP or SRP protocols.