doc/driver-model/usb-info.txt

58 This can hold run-time information needed by the driver for operation. It
59 exists when the device is probed (not when it is bound) and is removed when
63 in USB device mode (OTG operation). It can be omitted if that is not
67 call ehci_register() to register itself as an EHCI device. It should call
71 The old ehci_hcd_init() function is no-longer used. Nor is it necessary to
86 	have this structure. You can access it for a device 'dev' with
87 	dev_get_parent_priv(dev). It matches the old structure except that the
98 	This holds platform data for a device. You can access it for a
99 	device 'dev' with dev_get_parent_platdata(dev). It holds the device
106 	controller uclass. It is mostly used to keep track of the next
115 Given a controller, you know the bus - it is the one attached to the
117 root hub attached to it. This hub, which is itself a USB device, can provide
118 one or more 'ports' to which additional devices can be attached. It is
152 the message there with an appropriate 'pipe' value so it can be addressed
155 is open for review and the code impact of changing it is small since the
160 since XHCI needs to allocate a device context before it can even read the
176 By the time the device's probe() method is called, it is enumerated and is
180 device. It does this by examining the device class, interface class, vendor
184 devices, and it will be used for all USB devices which match.
191 It is useful to understand precisely how a USB bus is enumerating to avoid
207 udevice for it. But we do have the descriptor in struct usb_device so we can
216 with USB_DEVICE()). If it finds a match it binds that driver to create a new
218 - If it does not, it binds a generic driver. A generic driver is good enough
219 to allow access to the device (sending it packets, etc.) but all
225 speed) in its parent platform data. We cannot store it its private data
232 stored in the parent platform data and stores it in the parent private data
233 (which is struct usb_device, a real one this time). It then calls
241 - the device's probe() method is then called. It can send messages and do
242 whatever else it wants to make the device work.
246 given it address 1 and set the configuration.
259 - you will recognise usb_scan_device() from the steps above. It sets up the
260 device ready for use. If it is a hub, it will scan that hub before it
290 As an example of a USB device driver, see usb_storage.c. It uses its own
313 bInterfaceClass value of USB_CLASS_MASS_STORAGE, it will automatically find
314 this driver and use it.
329 that it will be found as part of normal USB enumeration. Then, instead of a
345 Tests in test/dm/usb.c make use of this feature. It allows much of the USB
381 This may look confusing. Most of it mirrors the device tree, but the
385 USB device driver that talks to it.
391 It is pretty uncommon to have a large USB bus with lots of hubs on an
393 it would be possible to speed up enumeration in two ways: