.. | .. |
---|
176 | 176 | |
---|
177 | 177 | Gadget drivers declare themselves through a struct |
---|
178 | 178 | :c:type:`usb_gadget_driver`, which is responsible for most parts of enumeration |
---|
179 | | -for a struct :c:type:`usb_gadget`. The response to a set_configuration usually |
---|
180 | | -involves enabling one or more of the struct :c:type:`usb_ep` objects exposed by |
---|
181 | | -the gadget, and submitting one or more struct :c:type:`usb_request` buffers to |
---|
| 179 | +for a struct usb_gadget. The response to a set_configuration usually |
---|
| 180 | +involves enabling one or more of the struct usb_ep objects exposed by |
---|
| 181 | +the gadget, and submitting one or more struct usb_request buffers to |
---|
182 | 182 | transfer data. Understand those four data types, and their operations, |
---|
183 | 183 | and you will understand how this API works. |
---|
184 | 184 | |
---|
.. | .. |
---|
339 | 339 | necessarily sharing a given configuration). There is however an optional |
---|
340 | 340 | framework which makes it easier to reuse and combine functions. |
---|
341 | 341 | |
---|
342 | | -Devices using this framework provide a struct :c:type:`usb_composite_driver`, |
---|
343 | | -which in turn provides one or more struct :c:type:`usb_configuration` |
---|
| 342 | +Devices using this framework provide a struct usb_composite_driver, |
---|
| 343 | +which in turn provides one or more struct usb_configuration |
---|
344 | 344 | instances. Each such configuration includes at least one struct |
---|
345 | 345 | :c:type:`usb_function`, which packages a user visible role such as "network |
---|
346 | 346 | link" or "mass storage device". Management functions may also exist, |
---|