Lines Matching refs:which

94 	as a work-around for controllers which can act as USB devices in OTG
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
119 possible to power up a hub and find out which of its ports have devices
138 (1.5Mbps), full (12Mbps), high (480Mbps) which is only available with USB2
139 and newer (EHCI), and super (5Gbps) which is only available with USB3 and
151 U-Boot simply finds the controller to which the device is attached, and sends
153 properly. Having said that, the USB device which should receive the message
163 These methods use a 'pipe' which is a collection of bit fields used to
171 USB devices are found using a simple algorithm which works through the
179 The enumeration process needs to work out which driver to attach to each USB
184 devices, and it will be used for all USB devices which match.
197 - This calls usb_init() which works through each controller in turn
210 existing device which matches the one we just found on the bus. This can
214 usb_find_and_bind_driver() which tries to bind one
227 - then we call device_probe() which probes the device
231 USB this calls usb_child_pre_probe() which grabs the information that was
233 (which is struct usb_device, a real one this time). It then calls
252 - usb_hub_post_probe() calls usb_hub_scan() to scan the hub, which in turn
324 each bus and manually figures out which are Ethernet devices in the ways of
340 emulation drivers which pretend to be USB devices. Emulations are provided
342 (defined by the sandbox device tree sandbox.dts) which can be scanned and
368 This defines a single controller, containing a root hub (which is required).
400 statically declared in the device tree (which is acceptable for production