add lvds1024*800

hc

2024-01-31 f70575805708cabdedea7498aaa3f710fde4d920

 kernel/Documentation/driver-api/usb/gadget.rst
..
..
@@ -176,9 +176,9 @@
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,8 +339,8 @@
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,