u-boot.git/drivers/usb/host/usb-uclass.c, branch v2024.01

bootstd: Keep track of use of usb stop

2023-09-21T22:05:40Z

When 'usb stop' is run, doing 'bootflow scan' does not run the USB hunter again so does not see any devices. Fix this by telling bootstd about the state of USB. Signed-off-by: Simon Glass

usb: check for companion controller in uclass

2023-09-04T16:25:20Z

EHCI is usually used with companion controller (like OHCI) as companion controller. This information on the companion is missing currently in companion drivers. So, if the usb-uclass isn't aware, it may scan busses in any order: OHCI first, then EHCI. This is seen on STM32MP1 where DT probing makes the probe order to occur by increasing address (OHCI address < EHCI address). When a low speed or full-speed device is plugged in, it's not detected as EHCI should first detect it, and give ownership (handover) to OHCI. Current situation on STM32MP1 (with a low speed device plugged-in) STM32MP> usb start starting USB... Bus usb@5800c000: USB OHCI 1.0 Bus usb@5800d000: USB EHCI 1.00 scanning bus usb@5800c000 for devices... 1 USB Device(s) found scanning bus usb@5800d000 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found The "companion" property in the device tree allow to retrieve companion controller information, from the EHCI node. This allow marking the companion driver as such. With this patch (same low speed device plugged in): STM32MP> usb start starting USB... Bus usb@5800c000: USB OHCI 1.0 Bus usb@5800d000: USB EHCI 1.00 scanning bus usb@5800d000 for devices... 1 USB Device(s) found scanning bus usb@5800c000 for devices... 2 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found STM32MP> usb tree USB device tree: 1 Hub (12 Mb/s, 0mA) | U-Boot Root Hub | +-2 Human Interface (1.5 Mb/s, 100mA) HP HP USB 1000dpi Laser Mouse 1 Hub (480 Mb/s, 0mA) u-boot EHCI Host Controller This also optimize bus scan when a High speed device is plugged in, as the usb-uclass skips OHCI in this case: STM32MP> usb reset resetting USB... Bus usb@5800c000: USB OHCI 1.0 Bus usb@5800d000: USB EHCI 1.00 scanning bus usb@5800d000 for devices... 2 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found STM32MP> usb tree USB device tree: 1 Hub (480 Mb/s, 0mA) | u-boot EHCI Host Controller | +-2 Mass Storage (480 Mb/s, 200mA) SanDisk Cruzer Blade 03003432021922011407 Signed-off-by: Fabrice Gasnier Reviewed-by: Marek Vasut

usb: Return -ENOENT when no devices are found

2023-08-09T15:31:11Z

When USB finds no devices it currently returns -EPERM which bootstd does not understand. This causes other bootdevs of the same priority to be skipped. Fix this by returning the correct error code. Signed-off-by: Simon Glass Reviewed-by: Bin Meng

usb: Tidy up the usb_start flag

2023-05-13T13:52:32Z

This should be declared in a header file so that type-checking works correctly. Add a single declaration to usb.h and remove the others. Signed-off-by: Simon Glass Reviewed-by: Marek Vasut Reviewed-by: Patrick Delaunay

dm: usb: Mark the device name as alloced when binding

2023-01-23T23:11:40Z

Since usb_find_and_bind_driver() allocates the device name it should tell driver about that, to avoid memory leaks. Fix this. Signed-off-by: Simon Glass

usb: onboard-hub: add driver to manage onboard hub supplies

2023-01-12T15:19:53Z

The main issue the driver addresses is that a USB hub needs to be powered before it can be discovered. This is often solved by using "regulator-always-on". This driver is inspired by the Linux v6.1 driver. It only enables (or disables) the hub vdd (3v3) supply, so it can be enumerated. Scanning of the device tree is done in a similar manner to the sandbox, by the usb-uclass. DT part looks like: &usbh_ehci { ... #address-cells = <1>; #size-cells = <0>; hub@1 { compatible = "usb424,2514"; reg = <1>; vdd-supply = <&v3v3>; }; }; When the bus gets probed, the driver is automatically probed/removed from the bus tree, as an example on stm32: STM32MP> usb start starting USB... STM32MP> dm tree Class Index Probed Driver Name ----------------------------------------------------------- usb 0 [ + ] ehci_generic | |-- usb@5800d000 usb_hub 0 [ + ] usb_onboard_hub | | `-- hub@1 usb_hub 1 [ + ] usb_hub | | `-- usb_hub STM32MP> usb tree USB device tree: 1 Hub (480 Mb/s, 0mA) | u-boot EHCI Host Controller | +-2 Hub (480 Mb/s, 2mA) Signed-off-by: Fabrice Gasnier Reviewed-by: Patrice Chotard Reviewed-by: Patrick Delaunay

usb: eth: Remove non-DM_ETH code

2022-12-07T21:04:17Z

As DM_ETH is required for all network drivers, it's now safe to remove the non-DM_ETH support code fro usb_ether itself. Signed-off-by: Tom Rini

usb: Expand buffer size in usb_find_and_bind_driver()

2022-11-27T11:04:36Z

The "generic_bus_%x_dev_%x" string which is printed into this buffer can be up to 34 characters long ("generic_bus_12345678_dev_12345678"). The buffer would be clipped by snprintf() if both %x were at maximum range. Make sure the buffer is long enough to cover such possibility. Signed-off-by: Marek Vasut Reviewed-by: Simon Glass

usb: Use the first available device for ehci_gadget

2022-01-25T18:47:07Z

For whatever reason, usb_setup_ehci_gadget removes and probes USB device 0. However, not all systems have a device 0. Use the first device instead. The device probed should probably have something to do with the controller (as specified by e.g. ums or fastboot ). In fact, I find it odd that we probe the USB device in the first place, because this is just to set up the gadget itself. Presumably, the controller should be probed by usb_gadget_initialize somehow. Signed-off-by: Sean Anderson Reviewed-by: Simon Glass

dm: define LOG_CATEGORY for all uclass

2021-07-06T16:38:03Z

Define LOG_CATEGORY for all uclass to allow filtering with log command. Signed-off-by: Patrick Delaunay Reviewed-by: Simon Glass