struct_usb_gadget(9) [centos man page]
STRUCT
USB_GADGET(9) Kernel Mode Gadget API STRUCT USB_GADGET(9) NAME
struct_usb_gadget - represents a usb slave device SYNOPSIS
struct usb_gadget { const struct usb_gadget_ops * ops; struct usb_ep * ep0; struct list_head ep_list; enum usb_device_speed speed; enum usb_device_speed max_speed; enum usb_device_state state; unsigned sg_supported:1; unsigned is_otg:1; unsigned is_a_peripheral:1; unsigned b_hnp_enable:1; unsigned a_hnp_support:1; unsigned a_alt_hnp_support:1; const char * name; struct device dev; unsigned out_epnum; unsigned in_epnum; }; MEMBERS
ops Function pointers used to access hardware-specific operations. ep0 Endpoint zero, used when reading or writing responses to driver setup requests ep_list List of other endpoints supported by the device. speed Speed of current connection to USB host. max_speed Maximal speed the UDC can handle. UDC must support this and all slower speeds. state the state we are now (attached, suspended, configured, etc) sg_supported true if we can handle scatter-gather is_otg True if the USB device port uses a Mini-AB jack, so that the gadget driver must provide a USB OTG descriptor. is_a_peripheral False unless is_otg, the "A" end of a USB cable is in the Mini-AB jack, and HNP has been used to switch roles so that the "A" device currently acts as A-Peripheral, not A-Host. b_hnp_enable OTG device feature flag, indicating that the A-Host enabled HNP support. a_hnp_support OTG device feature flag, indicating that the A-Host supports HNP at this port. a_alt_hnp_support OTG device feature flag, indicating that the A-Host only supports HNP on a different root port. name Identifies the controller hardware type. Used in diagnostics and sometimes configuration. dev Driver model state for this abstract device. out_epnum last used out ep number in_epnum last used in ep number DESCRIPTION
Gadgets have a mostly-portable "gadget driver" implementing device functions, handling all usb configurations and interfaces. Gadget drivers talk to hardware-specific code indirectly, through ops vectors. That insulates the gadget driver from hardware details, and packages the hardware endpoints through generic i/o queues. The "usb_gadget" and "usb_ep" interfaces provide that insulation from the hardware. Except for the driver data, all fields in this structure are read-only to the gadget driver. That driver data is part of the "driver model" infrastructure in 2.6 (and later) kernels, and for earlier systems is grouped in a similar structure that's not known to the rest of the kernel. Values of the three OTG device feature flags are updated before the setup call corresponding to USB_REQ_SET_CONFIGURATION, and before driver suspend calls. They are valid only when is_otg, and when the device is acting as a B-Peripheral (so is_a_peripheral is false). AUTHOR
David Brownell <dbrownell@users.sourceforge.net> Author. COPYRIGHT
Kernel Hackers Manual 3.10 June 2014 STRUCT USB_GADGET(9)
Check Out this Related Man Page
STRUCT
USB_GADGET_DR(9) Kernel Mode Gadget API STRUCT USB_GADGET_DR(9) NAME
struct_usb_gadget_driver - driver for usb 'slave' devices SYNOPSIS
struct usb_gadget_driver { char * function; enum usb_device_speed max_speed; int (* bind) (struct usb_gadget *gadget,struct usb_gadget_driver *driver); void (* unbind) (struct usb_gadget *); int (* setup) (struct usb_gadget *,const struct usb_ctrlrequest *); void (* disconnect) (struct usb_gadget *); void (* suspend) (struct usb_gadget *); void (* resume) (struct usb_gadget *); struct device_driver driver; }; MEMBERS
function String describing the gadget's function max_speed Highest speed the driver handles. bind the driver's bind callback unbind Invoked when the driver is unbound from a gadget, usually from rmmod (after a disconnect is reported). Called in a context that permits sleeping. setup Invoked for ep0 control requests that aren't handled by the hardware level driver. Most calls must be handled by the gadget driver, including descriptor and configuration management. The 16 bit members of the setup data are in USB byte order. Called in_interrupt; this may not sleep. Driver queues a response to ep0, or returns negative to stall. disconnect Invoked after all transfers have been stopped, when the host is disconnected. May be called in_interrupt; this may not sleep. Some devices can't detect disconnect, so this might not be called except as part of controller shutdown. suspend Invoked on USB suspend. May be called in_interrupt. resume Invoked on USB resume. May be called in_interrupt. driver Driver model state for this driver. DESCRIPTION
Devices are disabled till a gadget driver successfully binds, which means the driver will handle setup requests needed to enumerate (and meet "chapter 9" requirements) then do some useful work. If gadget->is_otg is true, the gadget driver must provide an OTG descriptor during enumeration, or else fail the bind call. In such cases, no USB traffic may flow until both bind returns without having called usb_gadget_disconnect, and the USB host stack has initialized. Drivers use hardware-specific knowledge to configure the usb hardware. endpoint addressing is only one of several hardware characteristics that are in descriptors the ep0 implementation returns from setup calls. Except for ep0 implementation, most driver code shouldn't need change to run on top of different usb controllers. It'll use endpoints set up by that ep0 implementation. The usb controller driver handles a few standard usb requests. Those include set_address, and feature flags for devices, interfaces, and endpoints (the get_status, set_feature, and clear_feature requests). Accordingly, the driver's setup callback must always implement all get_descriptor requests, returning at least a device descriptor and a configuration descriptor. Drivers must make sure the endpoint descriptors match any hardware constraints. Some hardware also constrains other descriptors. (The pxa250 allows only configurations 1, 2, or 3). The driver's setup callback must also implement set_configuration, and should also implement set_interface, get_configuration, and get_interface. Setting a configuration (or interface) is where endpoints should be activated or (config 0) shut down. (Note that only the default control endpoint is supported. Neither hosts nor devices generally support control traffic except to ep0.) Most devices will ignore USB suspend/resume operations, and so will not provide those callbacks. However, some may need to change modes when the host is not longer directing those activities. For example, local controls (buttons, dials, etc) may need to be re-enabled since the (remote) host can't do that any longer; or an error state might be cleared, to make the device behave identically whether or not power is maintained. AUTHOR
David Brownell <dbrownell@users.sourceforge.net> Author. COPYRIGHT
Kernel Hackers Manual 3.10 June 2014 STRUCT USB_GADGET_DR(9)