1STRUCT USB_GADGET_DR(9)     Kernel Mode Gadget API     STRUCT USB_GADGET_DR(9)
2
3
4

NAME

6       struct_usb_gadget_driver - driver for usb 'slave' devices
7

SYNOPSIS

9       struct usb_gadget_driver {
10         char * function;
11         enum usb_device_speed max_speed;
12         int (* bind) (struct usb_gadget *gadget,struct usb_gadget_driver *driver);
13         void (* unbind) (struct usb_gadget *);
14         int (* setup) (struct usb_gadget *,const struct usb_ctrlrequest *);
15         void (* disconnect) (struct usb_gadget *);
16         void (* suspend) (struct usb_gadget *);
17         void (* resume) (struct usb_gadget *);
18         struct device_driver driver;
19       };
20

MEMBERS

22       function
23           String describing the gadget's function
24
25       max_speed
26           Highest speed the driver handles.
27
28       bind
29           the driver's bind callback
30
31       unbind
32           Invoked when the driver is unbound from a gadget, usually from
33           rmmod (after a disconnect is reported). Called in a context that
34           permits sleeping.
35
36       setup
37           Invoked for ep0 control requests that aren't handled by the
38           hardware level driver. Most calls must be handled by the gadget
39           driver, including descriptor and configuration management. The 16
40           bit members of the setup data are in USB byte order. Called
41           in_interrupt; this may not sleep. Driver queues a response to ep0,
42           or returns negative to stall.
43
44       disconnect
45           Invoked after all transfers have been stopped, when the host is
46           disconnected. May be called in_interrupt; this may not sleep. Some
47           devices can't detect disconnect, so this might not be called except
48           as part of controller shutdown.
49
50       suspend
51           Invoked on USB suspend. May be called in_interrupt.
52
53       resume
54           Invoked on USB resume. May be called in_interrupt.
55
56       driver
57           Driver model state for this driver.
58

DESCRIPTION

60       Devices are disabled till a gadget driver successfully binds, which
61       means the driver will handle setup requests needed to enumerate (and
62       meet “chapter 9” requirements) then do some useful work.
63
64       If gadget->is_otg is true, the gadget driver must provide an OTG
65       descriptor during enumeration, or else fail the bind call. In such
66       cases, no USB traffic may flow until both bind returns without having
67       called usb_gadget_disconnect, and the USB host stack has initialized.
68
69       Drivers use hardware-specific knowledge to configure the usb hardware.
70       endpoint addressing is only one of several hardware characteristics
71       that are in descriptors the ep0 implementation returns from setup
72       calls.
73
74       Except for ep0 implementation, most driver code shouldn't need change
75       to run on top of different usb controllers. It'll use endpoints set up
76       by that ep0 implementation.
77
78       The usb controller driver handles a few standard usb requests. Those
79       include set_address, and feature flags for devices, interfaces, and
80       endpoints (the get_status, set_feature, and clear_feature requests).
81
82       Accordingly, the driver's setup callback must always implement all
83       get_descriptor requests, returning at least a device descriptor and a
84       configuration descriptor. Drivers must make sure the endpoint
85       descriptors match any hardware constraints. Some hardware also
86       constrains other descriptors. (The pxa250 allows only configurations 1,
87       2, or 3).
88
89       The driver's setup callback must also implement set_configuration, and
90       should also implement set_interface, get_configuration, and
91       get_interface. Setting a configuration (or interface) is where
92       endpoints should be activated or (config 0) shut down.
93
94       (Note that only the default control endpoint is supported. Neither
95       hosts nor devices generally support control traffic except to ep0.)
96
97       Most devices will ignore USB suspend/resume operations, and so will not
98       provide those callbacks. However, some may need to change modes when
99       the host is not longer directing those activities. For example, local
100       controls (buttons, dials, etc) may need to be re-enabled since the
101       (remote) host can't do that any longer; or an error state might be
102       cleared, to make the device behave identically whether or not power is
103       maintained.
104

AUTHOR

106       David Brownell <dbrownell@users.sourceforge.net>
107           Author.
108

110Kernel Hackers Manual 3.10         June 2019           STRUCT USB_GADGET_DR(9)
Impressum