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

usb: informative message if no controller

2024-06-19T04:14:55Z

The message 'No working controllers found' provides no clue that this refers to USB controllers. Provide a message that refers to USB. Signed-off-by: Heinrich Schuchardt Reviewed-by: Dragan Simic Reviewed-by: Caleb Connolly Reviewed-by: Marek Vasut Reviewed-by: Mattijs Korpershoek

Revert "Merge patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet""

2024-05-19T14:16:36Z

When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"' I failed to notice that b4 noticed it was based on next and so took that as the base commit and merged that part of next to master. This reverts commit c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35. Reported-by: Jonas Karlman Signed-off-by: Tom Rini

usb: Remove and add needed includes

2024-05-07T14:00:56Z

Remove from this driver directory and when needed add missing include files directly. Reviewed-by: Mattijs Korpershoek Signed-off-by: Tom Rini

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