[PATCH v3 0/5] Extend usb_onboard_hub driver to support Cypress HX3 hub family

[PATCH v3 0/5] Extend usb_onboard_hub driver to support Cypress HX3 hub family

[Lukasz Czechowski]

This patch series extends the usb_onboard_hub driver to allow for
support of more types of onboard hub devices, and adds the Cypress
HX3 hub family.

First patch in the series updates the bind function, so that it no
longer uses hardcoded compatible strings.
Next patch simplifies the code, by removing unnecessary dm_gpio
function call.
Third patch updates the remove function, which allows the prevent
issues with usb devices reenumeration, in case of calling
"usb reset". Although the issue could still occur in case of invalid
initial state of reset gpio, it is minimized with no impact on main
usb_hub driver.
Fourth patch extends the driver with support for multiple power
supplies, the same way it is done in kernel driver.
Finally, last patch provides hub data and of_match table entries
for Cypress HX3

Signed-off-by: Lukasz Czechowski <lukasz.czechowski@thaumatec.com>
---
Changes in v3:
- Rebased on top of latest master
- Updated usb_onboard_hub_power_off function to print error
  message in case regulator_set_enable_if_allowed call fails,
  as suggested by Quentin.
- Link to v2: https://lore.kernel.org/r/20250526-usb_onboard_hub_cypress_hx3-v2-0-f382415da84f@thaumatec.com

Changes in v2:
- Replaced the method for finding hub in bind function with
  uclass_find_device_by_ofnode, which seems more appropriate 
- Added new patch that removes unnecessary dm_gpio_free call
  in usb_onboard_hub_remove
- Create separate static method for disabling supply regulators
- Update error handling in probe function 
- Link to v1: https://lore.kernel.org/r/20250425-usb_onboard_hub_cypress_hx3-v1-0-3cc5a06087cf@thaumatec.com

---
Lukasz Czechowski (5):
      usb: onboard-hub: Use the ofnode to check if the peer-hub was probed
      usb: onboard-hub: Use devm API do automatically free the reset GPIO
      usb: onboard-hub: Set the reset gpio pin before freeing
      usb: onboard-hub: Add support for multiple power supplies
      usb: onboard-hub: Add support for Cypress HX3 family

 common/usb_onboard_hub.c | 101 ++++++++++++++++++++++++++++++++++++-----------
 drivers/usb/Kconfig      |   1 +
 2 files changed, 79 insertions(+), 23 deletions(-)
---
base-commit: 5a8dd2e0c848135b5c96af291aa96e79acc923ec
change-id: 20250425-usb_onboard_hub_cypress_hx3-2831983f1ede

Best regards,
-- 
Lukasz Czechowski <lukasz.czechowski@thaumatec.com>

[PATCH v3 1/5] usb: onboard-hub: Use the ofnode to check if the peer-hub was probed

[Lukasz Czechowski]

Currently the check in usb_onboard_hub_bind is relying on specific
compatible string for the Michrochip USB5744. Replace this with
more generic approach that will allow to add new types of devices
to the of_match table. Because the driver only needs to bind one
"half" of the hub, the peer-hub node is used to find out if it
was already done. In case peer-hub was bound, -ENODEV is returned.

Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Lukasz Czechowski <lukasz.czechowski@thaumatec.com>
---
 common/usb_onboard_hub.c | 15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/common/usb_onboard_hub.c b/common/usb_onboard_hub.c
index d17c85dd6225..7606362a4ee6 100644
--- a/common/usb_onboard_hub.c
+++ b/common/usb_onboard_hub.c
@@ -10,6 +10,7 @@
 #include <asm/gpio.h>
 #include <dm.h>
 #include <dm/device_compat.h>
+#include <dm/uclass-internal.h>
 #include <i2c.h>
 #include <linux/delay.h>
 #include <power/regulator.h>
@@ -179,8 +180,8 @@ err:
 static int usb_onboard_hub_bind(struct udevice *dev)
 {
 	struct ofnode_phandle_args phandle;
-	const void *fdt = gd->fdt_blob;
-	int ret, off;
+	struct udevice *peerdev;
+	int ret;
 
 	ret = dev_read_phandle_with_args(dev, "peer-hub", NULL, 0, 0, &phandle);
 	if (ret == -ENOENT) {
@@ -193,10 +194,14 @@ static int usb_onboard_hub_bind(struct udevice *dev)
 		return ret;
 	}
 
-	off = ofnode_to_offset(phandle.node);
-	ret = fdt_node_check_compatible(fdt, off, "usb424,5744");
-	if (!ret)
+	ret = uclass_find_device_by_ofnode(UCLASS_USB_HUB, phandle.node, &peerdev);
+	if (ret) {
+		dev_dbg(dev, "binding before peer-hub %s\n",
+			ofnode_get_name(phandle.node));
 		return 0;
+	}
+
+	dev_dbg(dev, "peer-hub %s has been bound\n", peerdev->name);
 
 	return -ENODEV;
 }

-- 
2.43.0

[PATCH v3 2/5] usb: onboard-hub: Use devm API do automatically free the reset GPIO

[Lukasz Czechowski]

The reset GPIO is obtained during driver probing by the function
devm_gpiod_get_optional, which means the GPIO will be automatically
freed when the device is removed. Because of this, explicit call
to free the reset GPIO in hub remove function is not needed.
To support the Managed device resources, the DEVRES config must
be enabled, otherwise the devres functions fall back to non-managed
variants. Set the necessary dependency to DEVRES in Kconfig.

Signed-off-by: Lukasz Czechowski <lukasz.czechowski@thaumatec.com>
---
 common/usb_onboard_hub.c | 3 ---
 drivers/usb/Kconfig      | 1 +
 2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/common/usb_onboard_hub.c b/common/usb_onboard_hub.c
index 7606362a4ee6..c6379192fe8f 100644
--- a/common/usb_onboard_hub.c
+++ b/common/usb_onboard_hub.c
@@ -211,9 +211,6 @@ static int usb_onboard_hub_remove(struct udevice *dev)
 	struct onboard_hub *hub = dev_get_priv(dev);
 	int ret = 0;
 
-	if (hub->reset_gpio)
-		dm_gpio_free(hub->reset_gpio->dev, hub->reset_gpio);
-
 	if (hub->vdd) {
 		ret = regulator_set_enable_if_allowed(hub->vdd, false);
 		if (ret)
diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index 99c6649e4178..daf2240ffd92 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -112,6 +112,7 @@ config USB_KEYBOARD
 config USB_ONBOARD_HUB
 	bool "Onboard USB hub support"
 	depends on DM_USB
+	select DEVRES
 	---help---
 	  Say Y here if you want to support discrete onboard USB hubs that
 	  don't require an additional control bus for initialization, but

-- 
2.43.0

Re: [PATCH v3 2/5] usb: onboard-hub: Use devm API do automatically free the reset GPIO

[Quentin Schulz]

Hi Lukasz,

On 6/10/25 10:02 AM, Lukasz Czechowski wrote:
> The reset GPIO is obtained during driver probing by the function
> devm_gpiod_get_optional, which means the GPIO will be automatically
> freed when the device is removed. Because of this, explicit call
> to free the reset GPIO in hub remove function is not needed.
> To support the Managed device resources, the DEVRES config must
> be enabled, otherwise the devres functions fall back to non-managed
> variants. Set the necessary dependency to DEVRES in Kconfig.
> 
> Signed-off-by: Lukasz Czechowski <lukasz.czechowski@thaumatec.com>

Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>

Thanks!
Quentin

[PATCH v3 3/5] usb: onboard-hub: Set the reset gpio pin before freeing

[Lukasz Czechowski]

In the usb_onboard_hub_remove, the reset gpio, if available, is
freed. The pin state however, remains unchanged, as set in the
usb_onboard_hub_reset. The hub is then left enabled.

During second onboard hub probing, the hub is initially enabled
(reset pin in state "0"), and then it is being reset by the reset
function (transition to "1" and then to "0"). Because of this,
the hub first disconnects from root hub, and then it connects again.

When the devices are being discovered in the usb_scan_port in the
usb_hub driver, initially there is the USB_PORT_STAT_CONNECTION bit
not set in portstatus, but USB_PORT_STAT_C_CONNECTION set in
portchange data (which is because disconnect event occurred first).
In this condition, the driver does not wait for devices to appear.
This can cause the hub (and all child devices) to be not enumerated
when rescanning on "usb reset" command.

To fix this, set the reset gpio to active in usb_onboard_hub_remove,
to put the hub into reset state.
However, in case the hub reset pin is by default held in high
state by HW before U-Boot takes over, in which case the USB hub is
active, then during the first probe it gets reset and we might get
into the same issue of the hub being not enumerated.

Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Lukasz Czechowski <lukasz.czechowski@thaumatec.com>
---
 common/usb_onboard_hub.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/common/usb_onboard_hub.c b/common/usb_onboard_hub.c
index c6379192fe8f..046831d09668 100644
--- a/common/usb_onboard_hub.c
+++ b/common/usb_onboard_hub.c
@@ -211,6 +211,13 @@ static int usb_onboard_hub_remove(struct udevice *dev)
 	struct onboard_hub *hub = dev_get_priv(dev);
 	int ret = 0;
 
+	if (hub->reset_gpio) {
+		ret = dm_gpio_set_value(hub->reset_gpio, 1);
+		if (ret)
+			dev_err(dev, "can't set gpio %s: %d\n", hub->reset_gpio->dev->name,
+				ret);
+	}
+
 	if (hub->vdd) {
 		ret = regulator_set_enable_if_allowed(hub->vdd, false);
 		if (ret)

-- 
2.43.0

[PATCH v3 4/5] usb: onboard-hub: Add support for multiple power supplies

[Lukasz Czechowski]

Some of the onboard hubs require multiple power supplies, so extend
the driver to support them.
The implementation is inspired by the kernel driver, as introduced
by commit [1] in the v6.10 kernel.

[1] https://github.com/torvalds/linux/commit/ec1848cd5df426f57a7f6a8a6b95b69259c52cfc
Signed-off-by: Lukasz Czechowski <lukasz.czechowski@thaumatec.com>
---
 common/usb_onboard_hub.c | 67 ++++++++++++++++++++++++++++++++++++------------
 1 file changed, 50 insertions(+), 17 deletions(-)

diff --git a/common/usb_onboard_hub.c b/common/usb_onboard_hub.c
index 046831d09668..273b626dbaee 100644
--- a/common/usb_onboard_hub.c
+++ b/common/usb_onboard_hub.c
@@ -20,14 +20,18 @@
 #define USB5744_CONFIG_REG_ACCESS	0x0037
 #define USB5744_CONFIG_REG_ACCESS_LSB	0x99
 
+#define MAX_SUPPLIES 2
+
 struct onboard_hub {
-	struct udevice *vdd;
+	struct udevice *vdd[MAX_SUPPLIES];
 	struct gpio_desc *reset_gpio;
 };
 
 struct onboard_hub_data {
 	unsigned long reset_us;
 	unsigned long power_on_delay_us;
+	unsigned int num_supplies;
+	const char * const supply_names[MAX_SUPPLIES];
 	int (*init)(struct udevice *dev);
 };
 
@@ -139,30 +143,58 @@ int usb_onboard_hub_reset(struct udevice *dev)
 	return 0;
 }
 
+static int usb_onboard_hub_power_off(struct udevice *dev)
+{
+	struct onboard_hub_data *data =
+		(struct onboard_hub_data *)dev_get_driver_data(dev);
+	struct onboard_hub *hub = dev_get_priv(dev);
+	int ret = 0, ret2;
+	int i;
+
+	for (i = data->num_supplies - 1; i >= 0; i--)
+		if (hub->vdd[i]) {
+			ret2 = regulator_set_enable_if_allowed(hub->vdd[i], false);
+			if (ret2 && ret2 != -ENOSYS) {
+				dev_err(dev, "can't disable %s: %d\n", data->supply_names[i], ret2);
+				ret |= ret2;
+			}
+		}
+
+	return ret;
+}
+
 static int usb_onboard_hub_probe(struct udevice *dev)
 {
 	struct onboard_hub_data *data =
 		(struct onboard_hub_data *)dev_get_driver_data(dev);
 	struct onboard_hub *hub = dev_get_priv(dev);
+	unsigned int i;
 	int ret;
 
-	ret = device_get_supply_regulator(dev, "vdd-supply", &hub->vdd);
-	if (ret && ret != -ENOENT && ret != -ENOSYS) {
-		dev_err(dev, "can't get vdd-supply: %d\n", ret);
-		return ret;
+	if (data->num_supplies > MAX_SUPPLIES) {
+		dev_err(dev, "invalid supplies number, max supported: %d\n", MAX_SUPPLIES);
+		return -EINVAL;
 	}
 
-	if (hub->vdd) {
-		ret = regulator_set_enable_if_allowed(hub->vdd, true);
-		if (ret && ret != -ENOSYS) {
-			dev_err(dev, "can't enable vdd-supply: %d\n", ret);
-			return ret;
+	for (i = 0; i < data->num_supplies; i++) {
+		ret = device_get_supply_regulator(dev, data->supply_names[i], &hub->vdd[i]);
+		if (ret && ret != -ENOENT && ret != -ENOSYS) {
+			dev_err(dev, "can't get %s: %d\n", data->supply_names[i], ret);
+			goto err_supply;
+		}
+
+		if (hub->vdd[i]) {
+			ret = regulator_set_enable_if_allowed(hub->vdd[i], true);
+			if (ret && ret != -ENOSYS) {
+				dev_err(dev, "can't enable %s: %d\n", data->supply_names[i], ret);
+				goto err_supply;
+			}
 		}
 	}
 
 	ret = usb_onboard_hub_reset(dev);
 	if (ret)
-		return ret;
+		goto err_supply;
 
 	if (data->init) {
 		ret = data->init(dev);
@@ -174,6 +206,8 @@ static int usb_onboard_hub_probe(struct udevice *dev)
 	return 0;
 err:
 	dm_gpio_set_value(hub->reset_gpio, 0);
+err_supply:
+	usb_onboard_hub_power_off(dev);
 	return ret;
 }
 
@@ -218,24 +252,23 @@ static int usb_onboard_hub_remove(struct udevice *dev)
 				ret);
 	}
 
-	if (hub->vdd) {
-		ret = regulator_set_enable_if_allowed(hub->vdd, false);
-		if (ret)
-			dev_err(dev, "can't disable vdd-supply: %d\n", ret);
-	}
-
+	ret |= usb_onboard_hub_power_off(dev);
 	return ret;
 }
 
 static const struct onboard_hub_data usb2514_data = {
 	.power_on_delay_us = 500,
 	.reset_us = 1,
+	.num_supplies = 1,
+	.supply_names = { "vdd-supply" },
 };
 
 static const struct onboard_hub_data usb5744_data = {
 	.init = usb5744_i2c_init,
 	.power_on_delay_us = 1000,
 	.reset_us = 5,
+	.num_supplies = 1,
+	.supply_names = { "vdd-supply" },
 };
 
 static const struct udevice_id usb_onboard_hub_ids[] = {

-- 
2.43.0

Re: [PATCH v3 4/5] usb: onboard-hub: Add support for multiple power supplies

[Quentin Schulz]

Hi Lukasz,

On 6/10/25 10:02 AM, Lukasz Czechowski wrote:
> Some of the onboard hubs require multiple power supplies, so extend
> the driver to support them.
> The implementation is inspired by the kernel driver, as introduced
> by commit [1] in the v6.10 kernel.
> 
> [1] https://github.com/torvalds/linux/commit/ec1848cd5df426f57a7f6a8a6b95b69259c52cfc
> Signed-off-by: Lukasz Czechowski <lukasz.czechowski@thaumatec.com>
> ---
>   common/usb_onboard_hub.c | 67 ++++++++++++++++++++++++++++++++++++------------
>   1 file changed, 50 insertions(+), 17 deletions(-)
> 
> diff --git a/common/usb_onboard_hub.c b/common/usb_onboard_hub.c
> index 046831d09668..273b626dbaee 100644
> --- a/common/usb_onboard_hub.c
> +++ b/common/usb_onboard_hub.c
> @@ -20,14 +20,18 @@
>   #define USB5744_CONFIG_REG_ACCESS	0x0037
>   #define USB5744_CONFIG_REG_ACCESS_LSB	0x99
>   
> +#define MAX_SUPPLIES 2
> +
>   struct onboard_hub {
> -	struct udevice *vdd;
> +	struct udevice *vdd[MAX_SUPPLIES];
>   	struct gpio_desc *reset_gpio;
>   };
>   
>   struct onboard_hub_data {
>   	unsigned long reset_us;
>   	unsigned long power_on_delay_us;
> +	unsigned int num_supplies;
> +	const char * const supply_names[MAX_SUPPLIES];
>   	int (*init)(struct udevice *dev);
>   };
>   
> @@ -139,30 +143,58 @@ int usb_onboard_hub_reset(struct udevice *dev)
>   	return 0;
>   }
>   
> +static int usb_onboard_hub_power_off(struct udevice *dev)
> +{
> +	struct onboard_hub_data *data =
> +		(struct onboard_hub_data *)dev_get_driver_data(dev);
> +	struct onboard_hub *hub = dev_get_priv(dev);
> +	int ret = 0, ret2;
> +	int i;

Could be on the same line with ret and ret2.

I assume this was maybe due to using an unsigned int in the beginning 
but then the descending for-loop just below would never return because 
"i" would never be less than 0?

An option could be to have i represent the index + 1 and then whenever 
you use i to access an item in the array, you use i-1 instead.

So something like

for (i = data->num_supplies; i > 0; i--) {
     if (hub->vdd[i - 1]) {
         ret2 = regulator_set_enable_if_allowed(hub->vdd[i - 1], false);
         if (ret2 && ret2 != -ENOSYS) {
             dev_err(dev, "can't disable %s: %d\n", data->supply_names[i 
- 1], ret2);
             ret |= ret2;
         }
     }
}

instead maybe? No strong opinion on my side on that. We could probably 
even go for an u8 instead since it's very unlikely we'll have more than 
255 supplies for a given hub :)

> +
> +	for (i = data->num_supplies - 1; i >= 0; i--)
> +		if (hub->vdd[i]) {
> +			ret2 = regulator_set_enable_if_allowed(hub->vdd[i], false);
> +			if (ret2 && ret2 != -ENOSYS) {
> +				dev_err(dev, "can't disable %s: %d\n", data->supply_names[i], ret2);
> +				ret |= ret2;
> +			}
> +		}
> +

Please have the for-loop have curly brackets.

Aside from those minor nitpicks, looks good to me so:

Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>

Thanks!
Quentin

[PATCH v3 5/5] usb: onboard-hub: Add support for Cypress HX3 family

[Lukasz Czechowski]

The HX3 is a family of USB3.0 hub controllers that comes in
different variants: CYUSB330x/CYUSB331x/CYUSB332x/CYUSB230x.
To support this hub, controlling of reset pin and two
power supplies is required.
The reset time is set to 10ms, based on the datasheet [1].
Power-on delay time is not required, so it is set to 0.
The compatible strings added to of_match table are
compliant with usb/cypress,hx3.yaml bindings.

[1] https://www.infineon.com/dgdl/Infineon-HX3_USB_3_0_Hub_Consumer_Industrial-DataSheet-v22_00-EN.pdf?fileId=8ac78c8c7d0d8da4017d0ecb53f644b8
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Lukasz Czechowski <lukasz.czechowski@thaumatec.com>
---
 common/usb_onboard_hub.c | 15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/common/usb_onboard_hub.c b/common/usb_onboard_hub.c
index 273b626dbaee..eb0694f1a44b 100644
--- a/common/usb_onboard_hub.c
+++ b/common/usb_onboard_hub.c
@@ -271,6 +271,12 @@ static const struct onboard_hub_data usb5744_data = {
 	.supply_names = { "vdd-supply" },
 };
 
+static const struct onboard_hub_data usbhx3_data = {
+	.reset_us = 10000,
+	.num_supplies = 2,
+	.supply_names = { "vdd-supply", "vdd2-supply" },
+};
+
 static const struct udevice_id usb_onboard_hub_ids[] = {
 	/* Use generic usbVID,PID dt-bindings (usb-device.yaml) */
 	{	.compatible = "usb424,2514",	/* USB2514B USB 2.0 */
@@ -281,7 +287,14 @@ static const struct udevice_id usb_onboard_hub_ids[] = {
 	}, {
 		.compatible = "usb424,5744",	/* USB5744 USB 3.0 */
 		.data = (ulong)&usb5744_data,
-	}
+	}, {
+		.compatible = "usb4b4,6504",	/* Cypress HX3 USB 3.0 */
+		.data = (ulong)&usbhx3_data,
+	}, {
+		.compatible = "usb4b4,6506",	/* Cypress HX3 USB 2.0 */
+		.data = (ulong)&usbhx3_data,
+	},
+	{ /* sentinel */ }
 };
 
 U_BOOT_DRIVER(usb_onboard_hub) = {

-- 
2.43.0

Re: [PATCH v3 0/5] Extend usb_onboard_hub driver to support Cypress HX3 hub family

[Quentin Schulz]

Hi Lukasz,

On 6/10/25 10:02 AM, Lukasz Czechowski wrote:
> This patch series extends the usb_onboard_hub driver to allow for
> support of more types of onboard hub devices, and adds the Cypress
> HX3 hub family.
> 
> First patch in the series updates the bind function, so that it no
> longer uses hardcoded compatible strings.
> Next patch simplifies the code, by removing unnecessary dm_gpio
> function call.
> Third patch updates the remove function, which allows the prevent
> issues with usb devices reenumeration, in case of calling
> "usb reset". Although the issue could still occur in case of invalid
> initial state of reset gpio, it is minimized with no impact on main
> usb_hub driver.
> Fourth patch extends the driver with support for multiple power
> supplies, the same way it is done in kernel driver.
> Finally, last patch provides hub data and of_match table entries
> for Cypress HX3
> 
> Signed-off-by: Lukasz Czechowski <lukasz.czechowski@thaumatec.com>

For general information: this patch series is required for RK3399 Puma 
once devicetree-rebasing is updated to 6.16+ since we have 
non-backward-compatible DT changes. We should be able to anticipate the 
breakage by simply enabling USB_ONBOARD_HUB in 
configs/puma-rk3399_defconfig. I'll send a patch once this gets merged.

For the whole series:

Tested-by: Quentin Schulz <quentin.schulz@cherry.de> # RK3399 Puma Haikou

How I tested:

- Apply the series on top of master
- Set config to puma-rk3399_defconfig
- Enable USB_ONBOARD_HUB via menuconfig
- tools/update-subtree.sh pick dts 0fe42d171081426ab119ca5c0eb130e5f3a9a805
- tools/update-subtree.sh pick dts 53aacaed0ad140b017c803d9777473c6c62f5352
- tools/update-subtree.sh pick dts 932da7a8df7b6b43453d640b383d0076d5a7d9a5

Connect a USB stick to Q7 USB P0, P2 and P3.

When in U-Boot run:

"""
=> usb tree
USB device tree:
   1  Hub (480 Mb/s, 0mA)
      u-boot EHCI Host Controller

   1  Hub (480 Mb/s, 0mA)
      u-boot EHCI Host Controller

   1  Hub (5 Gb/s, 0mA)
   |  U-Boot XHCI Host Controller
   |
   +-2  Hub (480 Mb/s, 0mA)
   | |
   | +-4  Mass Storage (480 Mb/s, 0mA)
   | |    SanDisk USB Extreme Pro 54A45678CACF
   | |
   | +-7  Vendor specific (12 Mb/s, 100mA)
   |      Theobroma Systems Mule USB/CAN Adapter 002A00244356530720323439
   |
   +-3  Hub (5 Gb/s, 0mA)
     |
     +-5  Mass Storage (5 Gb/s, 224mA)
     |     USB  SanDisk 3.2Gen1 0101b5ceeeaf252dc220834775927a7
     |
     +-6  Mass Storage (5 Gb/s, 224mA)
           USB  SanDisk 3.2Gen1 01013e8773b9dc4a14a4278d7dd42fc

=> usb storage
   Device 0: Vendor: SanDisk  Rev: 0    Prod: Extreme Pro
             Type: Removable Hard Disk
             Capacity: 122112.0 MB = 119.2 GB (250085376 x 512)
   Device 1: Vendor:  USB Rev: 1.00 Prod:  SanDisk 3.2Gen1
             Type: Removable Hard Disk
             Capacity: 29340.0 MB = 28.6 GB (60088320 x 512)
   Device 2: Vendor:  USB Rev: 1.00 Prod:  SanDisk 3.2Gen1
             Type: Removable Hard Disk
             Capacity: 29358.0 MB = 28.6 GB (60125184 x 512)
=> usb info
1: Hub,  USB Revision 2.0
  - u-boot EHCI Host Controller
  - Class: Hub
  - PacketSize: 64  Configurations: 1
  - Vendor: 0x0000  Product 0x0000 Version 1.0
    Configuration: 1
    - Interfaces: 1 Self Powered 0mA
      Interface: 0
      - Alternate Setting 0, Endpoints: 1
      - Class Hub
      - Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms

1: Hub,  USB Revision 2.0
  - u-boot EHCI Host Controller
  - Class: Hub
  - PacketSize: 64  Configurations: 1
  - Vendor: 0x0000  Product 0x0000 Version 1.0
    Configuration: 1
    - Interfaces: 1 Self Powered 0mA
      Interface: 0
      - Alternate Setting 0, Endpoints: 1
      - Class Hub
      - Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms

1: Hub,  USB Revision 3.0
  - U-Boot XHCI Host Controller
  - Class: Hub
  - PacketSize: 512  Configurations: 1
  - Vendor: 0x0000  Product 0x0000 Version 1.0
    Configuration: 1
    - Interfaces: 1 Self Powered 0mA
      Interface: 0
      - Alternate Setting 0, Endpoints: 1
      - Class Hub
      - Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms

2: Hub,  USB Revision 2.10
  - Class: Hub
  - PacketSize: 64  Configurations: 1
  - Vendor: 0x04b4  Product 0x6502 Version 80.16
    Configuration: 1
    - Interfaces: 1 Self Powered Remote Wakeup 0mA
      Interface: 0
      - Alternate Setting 0, Endpoints: 1
      - Class Hub
      - Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms
      - Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms

4: Mass Storage,  USB Revision 2.10
  - SanDisk USB Extreme Pro 54A45678CACF
  - Class: (from Interface) Mass Storage
  - PacketSize: 64  Configurations: 1
  - Vendor: 0x0781  Product 0x5588 Version 1.0
    Configuration: 1
    - Interfaces: 1 Self Powered 0mA
      Interface: 0
      - Alternate Setting 0, Endpoints: 2
      - Class Mass Storage, Transp. SCSI, Bulk only
      - Endpoint 1 In Bulk MaxPacket 512
      - Endpoint 2 Out Bulk MaxPacket 512

7: Vendor specific,  USB Revision 2.0
  - Theobroma Systems Mule USB/CAN Adapter 002A00244356530720323439
  - Class: (from Interface) Vendor specific
  - PacketSize: 64  Configurations: 2
  - Vendor: 0x2294  Product 0x425a Version 3.4
    Configuration: 1
    - Interfaces: 1 Self Powered 100mA
      Interface: 0
      - Alternate Setting 0, Endpoints: 2
      - Class Vendor specific
      - String: "UCAN Interface"
      - Endpoint 1 In Bulk MaxPacket 64
      - Endpoint 1 Out Bulk MaxPacket 16

3: Hub,  USB Revision 3.0
  - Class: Hub
  - PacketSize: 512  Configurations: 1
  - Vendor: 0x04b4  Product 0x6500 Version 80.16
    Configuration: 1
    - Interfaces: 1 Self Powered Remote Wakeup 0mA
      Interface: 0
      - Alternate Setting 0, Endpoints: 1
      - Class Hub
      - Endpoint 1 In Interrupt MaxPacket 2 Interval 8ms

5: Mass Storage,  USB Revision 3.20
  -  USB  SanDisk 3.2Gen1 0101b5ceeeaf252dc220834775927a7
  - Class: (from Interface) Mass Storage
  - PacketSize: 512  Configurations: 1
  - Vendor: 0x0781  Product 0x5591 Version 1.0
    Configuration: 1
    - Interfaces: 1 Bus Powered 224mA
      Interface: 0
      - Alternate Setting 0, Endpoints: 2
      - Class Mass Storage, Transp. SCSI, Bulk only
      - Endpoint 1 In Bulk MaxPacket 1024
      - Endpoint 2 Out Bulk MaxPacket 1024

6: Mass Storage,  USB Revision 3.20
  -  USB  SanDisk 3.2Gen1 01013e8773b9dc4a14a4278d7dd42fc
  - Class: (from Interface) Mass Storage
  - PacketSize: 512  Configurations: 1
  - Vendor: 0x0781  Product 0x5591 Version 1.0
    Configuration: 1
    - Interfaces: 1 Bus Powered 224mA
      Interface: 0
      - Alternate Setting 0, Endpoints: 2
      - Class Mass Storage, Transp. SCSI, Bulk only
      - Endpoint 1 In Bulk MaxPacket 1024
      - Endpoint 2 Out Bulk MaxPacket 102
"""

and

"""
for dev in 0 1 2; do usb reset; random $loadaddr 0x8000; mw.q 
$kernel_addr_r 0xffffffffffffffff 0x1000; usb dev ${dev}; usb write 
$loadaddr 0 0x40; usb read $kernel_addr_r 0 0x40; cmp.q $loadaddr 
$kernel_addr_r 0x1000; done
"""

which writes random data to and reads back from each USB stick, you 
should have three occurrences of:

Total of 4096 double word(s) were the same

The reset isn't technically required for each device (only one `usb 
start` or `usb reset` should be enough) but it allows to make sure it 
actually works (since one of the patches in this series claimed it 
wasn't working before).

Thanks!
Quentin