Lines Matching +full:2 +full:- +full:layered
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
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.
50 The gadget API resembles the host side Linux-USB API in that both use
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.
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
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
124 - user mode code, using generic (gadgetfs) or application specific
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
170 hardware-specific, any more than network protocols like X11, HTTP, or
171 NFS are. Such gadget-side interface drivers should eventually be
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
223 Like the Linux-USB host side API, this API exposes the "chunky" nature
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
236 -----------------
250 2. Register a gadget driver that implements some higher level device
298 only the HNP-related differences are particularly visible to driver
304 -------------------------------------
312 ------------------------
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
334 --------------------------
338 multi-configuration devices (also more than one function, but not
349 .. kernel-doc:: include/linux/usb/composite.h
352 .. kernel-doc:: drivers/usb/gadget/composite.c
356 --------------------------
359 to this framework. Near-term plans include converting all of them,
373 "Goku-S" (``goku_udc``), Renesas SH7705/7727 (``sh_udc``), MediaQ 11xx
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)
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
472 - Gadget drivers may need changes to support the two new OTG protocols,
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`
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