hc
2023-12-11 d2ccde1c8e90d38cee87a1b0309ad2827f3fd30d
kernel/Documentation/driver-api/usb/gadget.rst
....@@ -176,9 +176,9 @@
176176
177177 Gadget drivers declare themselves through a struct
178178 :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
182182 transfer data. Understand those four data types, and their operations,
183183 and you will understand how this API works.
184184
....@@ -339,8 +339,8 @@
339339 necessarily sharing a given configuration). There is however an optional
340340 framework which makes it easier to reuse and combine functions.
341341
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
344344 instances. Each such configuration includes at least one struct
345345 :c:type:`usb_function`, which packages a user visible role such as "network
346346 link" or "mass storage device". Management functions may also exist,