u-boot.git/drivers/usb/host/usb-uclass.c, branch v2025.01 Unnamed repository; edit this file 'description' to name the repository. Merge tag 'v2024.07-rc5' into next 2024-06-24T19:34:52+00:00 Tom Rini trini@konsulko.com 2024-06-24T19:34:52+00:00 a7eada24327a40f7ef6c55c220e119839c9d4227 Prepare v2024.07-rc5 
Prepare v2024.07-rc5
usb: informative message if no controller 2024-06-19T04:14:55+00:00 Heinrich Schuchardt heinrich.schuchardt@canonical.com 2024-06-18T19:07:29+00:00 4477e425d5e11cd279410c76fb189f8d9e2f4704 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 <heinrich.schuchardt@canonical.com> Reviewed-by: Dragan Simic <dsimic@manjaro.org> Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org> Reviewed-by: Marek Vasut <marex@denx.de> Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> 
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 <heinrich.schuchardt@canonical.com>
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org>
Reviewed-by: Marek Vasut <marex@denx.de>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Restore patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet" 2024-05-20T19:35:03+00:00 Tom Rini trini@konsulko.com 2024-05-20T19:35:03+00:00 03de305ec48b0bb28554372abb40ccd46dbe0bf9 As part of bringing the master branch back in to next, we need to allow for all of these changes to exist here. Reported-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Tom Rini <trini@konsulko.com> 
As part of bringing the master branch back in to next, we need to allow
for all of these changes to exist here.

Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>
Revert "Merge patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"" 2024-05-19T14:16:36+00:00 Tom Rini trini@konsulko.com 2024-05-19T02:20:43+00:00 d678a59d2d719da9e807495b4b021501f2836ca5 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 <jonas@kwiboo.se> Signed-off-by: Tom Rini <trini@konsulko.com> 
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 <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>
usb: Remove <common.h> and add needed includes 2024-05-07T14:00:56+00:00 Tom Rini trini@konsulko.com 2024-05-02T01:31:30+00:00 12a8b0dcaec239c53bc69b3df0abc0f4d5454309 Remove <common.h> from this driver directory and when needed add missing include files directly. Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> Signed-off-by: Tom Rini <trini@konsulko.com> 
Remove <common.h> from this driver directory and when needed
add missing include files directly.

Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
bootstd: Keep track of use of usb stop 2023-09-21T22:05:40+00:00 Simon Glass sjg@chromium.org 2023-09-20T13:29:49+00:00 1b1d36ec58f43585081b387ee44053278e480171 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 <sjg@chromium.org> 
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 <sjg@chromium.org>
usb: check for companion controller in uclass 2023-09-04T16:25:20+00:00 Fabrice Gasnier fabrice.gasnier@foss.st.com 2023-09-01T09:52:01+00:00 5b43bc97eeb9f7618ec926c72166ebf879b9d92e 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 <fabrice.gasnier@foss.st.com> Reviewed-by: Marek Vasut <marex@denx.de> 
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 <fabrice.gasnier@foss.st.com>
Reviewed-by: Marek Vasut <marex@denx.de>
usb: Return -ENOENT when no devices are found 2023-08-09T15:31:11+00:00 Simon Glass sjg@chromium.org 2023-07-30T17:15:12+00:00 4c4ccc5a0499cf2abdca95415caf7443c760a26d 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 <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> 
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 <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
usb: Tidy up the usb_start flag 2023-05-13T13:52:32+00:00 Simon Glass sjg@chromium.org 2023-05-06T02:03:03+00:00 9fea3a799dde140f2d75eeb4560a5c3237ca991d 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 <sjg@chromium.org> Reviewed-by: Marek Vasut <marex@denx.de> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com> 
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 <sjg@chromium.org>
Reviewed-by: Marek Vasut <marex@denx.de>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
dm: usb: Mark the device name as alloced when binding 2023-01-23T23:11:40+00:00 Simon Glass sjg@chromium.org 2023-01-17T17:47:35+00:00 ecdf3ab01f66585d0cb630b3ec28981dd4e7adff 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 <sjg@chromium.org> 
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 <sjg@chromium.org>