Lines Matching +full:composite +full:- +full:in
11 This document presents a Linux-USB "Gadget" kernel mode API, for use
17 - Supports USB 2.0, for high speed devices which can stream data at
20 - Handles devices with dozens of endpoints just as well as ones with
21 just two fixed-function ones. Gadget drivers can be written so
24 - Flexible enough to expose more complex USB device capabilities such
25 as multiple configurations, multiple interfaces, composite devices,
28 - USB "On-The-Go" (OTG) support, in conjunction with updates to the
29 Linux-USB host side.
31 - Sharing data structures and API models with the Linux-USB host side
32 API. This helps the OTG support, and looks forward to more-symmetric
36 - Minimalist, so it's easier to support new device controller hardware.
41 USB ``host`` hardware in a PC, workstation, or server. Linux users with
46 are "USB gadget drivers". In USB protocol interactions, the device
50 The gadget API resembles the host side Linux-USB API in that both use
54 bind and unbind drivers to devices. The APIs differ in detail, since the
58 necessarily different (one side is a hardware-neutral master, the other
59 is a hardware-aware slave), the endpoint I/0 API used here should also
60 be usable for an overhead-reduced host side API.
67 additional layers in user space code. The ``gadget`` API is used by the
71 In Linux, from the bottom up, these layers are:
78 objects, which accept streams of IN/OUT buffers, and through
84 Examples of such controller hardware include the PCI-based NetChip
85 2280 USB 2.0 high speed controller, the SA-11x0 or PXA-25x UDC
89 The lower boundary of this driver implements hardware-neutral USB
91 hardware varies widely in capabilities and restrictions, and is used
92 in embedded environments where space is at a premium, the gadget
97 involved in supporting new hardware, by *autoconfiguring* endpoints
98 automatically for many bulk-oriented drivers.) Gadget driver
101 - handling setup requests (ep0 protocol responses) possibly
102 including class-specific functionality
104 - returning configuration and string descriptors
106 - (re)setting configurations and interface altsettings, including
109 - handling life cycle events, such as managing bindings to
113 - managing IN and OUT transfers on all currently enabled endpoints
116 approach is discouraged in the Linux community.
120 Linux driver or framework in Linux. Through that boundary flows the
124 - user mode code, using generic (gadgetfs) or application specific
125 files in ``/dev``
127 - networking subsystem (for network gadgets, like the CDC Ethernet
130 - data capture drivers, perhaps video4Linux or a scanner driver; or
133 - input subsystem (for HID gadgets)
135 - sound subsystem (for audio gadgets)
137 - file system (for PTP gadgets)
139 - block i/o subsystem (for usb-storage gadgets)
141 - ... and more
151 OTG-capable systems will also need to include a standard Linux-USB host
159 viewed as a more battery-friendly kind of device wakeup protocol.
167 USB-IF protocols for HID, networking, storage, or audio classes. Some
168 developers are interested in KDB or KGDB hooks, to let target hardware
170 hardware-specific, any more than network protocols like X11, HTTP, or
171 NFS are. Such gadget-side interface drivers should eventually be
172 combined, to implement composite devices.
197 specific to the version of the Linux kernel that's in use. The 2.6
200 not fully portable. (They are implemented on 2.4 kernels, but in a
206 such as device-to-device DMA (without temporary storage in a memory
207 buffer) that would be added using hardware-specific APIs.
214 device configuration and management. The API supports limited run-time
217 themselves. In particular, driver init sections will often have endpoint
223 Like the Linux-USB host side API, this API exposes the "chunky" nature
224 of USB messages: I/O requests are in terms of one or more "packets", and
225 packet boundaries are visible to drivers. Compared to RS-232 serial
230 drivers won't buffer two single byte writes into a single two-byte USB
231 IN packet, although gadget drivers may do so when they implement
236 -----------------
244 found in Linux PDAs, and so on. At this point the device is logically
245 in the USB ch9 initial state (``attached``), drawing no power and not
267 in that configuration, with all interfaces in their default settings.
291 USB specifications. Such issues are in the domain of gadget drivers,
293 controllers or understanding that composite devices might happen to be
297 Other than providing an additional OTG descriptor in each configuration,
298 only the HNP-related differences are particularly visible to driver
304 -------------------------------------
306 Gadget drivers rely on common USB structures and constants defined in
307 the :ref:`linux/usb/ch9.h <usb_chapter9>` header file, which is standard in
312 ------------------------
314 These are declared in ``<linux/usb/gadget.h>``, and are used by gadget
317 .. kernel-doc:: include/linux/usb/gadget.h
321 ------------------
327 .. kernel-doc:: drivers/usb/gadget/usbstring.c
330 .. kernel-doc:: drivers/usb/gadget/config.c
333 Composite Device Framework
334 --------------------------
336 The core API is sufficient for writing drivers for composite USB devices
337 (with more than one function in a given configuration), and also
338 multi-configuration devices (also more than one function, but not
343 which in turn provides one or more struct usb_configuration
349 .. kernel-doc:: include/linux/usb/composite.h
352 .. kernel-doc:: drivers/usb/gadget/composite.c
355 Composite Device Functions
356 --------------------------
359 to this framework. Near-term plans include converting all of them,
371 Other hardware working in the ``gadget`` framework includes: Intel's PXA
373 "Goku-S" (``goku_udc``), Renesas SH7705/7727 (``sh_udc``), MediaQ 11xx
378 At this writing, there are people at work on drivers in this framework
383 act like a net2280, a pxa25x, or an sa11x0 in terms of available
388 least one person has expressed interest in adapting that approach,
399 In addition to *Gadget Zero* (used primarily for testing and development
431 solution for interoperability with systems such as MS-Windows and MacOS.
440 MS-Windows. One interesting use of that driver is in boot firmware (like
447 USB On-The-GO (OTG)
452 processors. Other OTG systems should work in similar ways, but the
456 including a special *Mini-AB* jack and associated transceiver to support
457 *Dual-Role* operation: they can act either as a host, using the standard
458 Linux-USB host side driver stack, or as a peripheral, using this
462 connects to the OTG port. In each role, the system can re-use the
463 existing pool of hardware-neutral drivers, layered on top of the
466 support OTG can also benefit non-OTG products.
468 - Gadget drivers test the ``is_otg`` flag, and use it to determine
469 whether or not to include an OTG descriptor in each of their
472 - Gadget drivers may need changes to support the two new OTG protocols,
473 exposed in new gadget attributes such as ``b_hnp_enable`` flag. HNP
475 suffice), and is triggered in some cases when the host suspends the
476 peripheral. SRP support can be user-initiated just like remote
479 - On the host side, USB device drivers need to be taught to trigger HNP
481 conserves battery power, which is useful even for non-OTG
484 - Also on the host side, a driver must support the OTG "Targeted
487 product-specific; each product must modify* ``otg_whitelist.h`` *to
490 Non-OTG Linux hosts, like PCs and workstations, normally have some
500 Additional changes are needed below those hardware-neutral :c:type:`usb_bus`
501 and :c:type:`usb_gadget` driver interfaces; those aren't discussed here in any
502 detail. Those affect the hardware-specific code for each USB Host or
509 were needed inside usbcore, so that it can identify OTG-capable devices