[PATCH v2 0/2] vf610: make the USB host port usable

[PATCH v2 0/2] vf610: make the USB host port usable

[Mehmet Fide]

From: Mehmet Fide <mehmet.fide@screeningeagle.com>

A device plugged into the host port of a Colibri VF50 or VF61 carrier is
never found, for two reasons.

The pin that switches VBUS never becomes an output: device_probe() reads
the device tree into plat data before it applies the pinctrl state, so
the fixed regulator asks for its GPIO first and the pinctrl state of the
same device then rewrites the pad. Harmless on most SoCs, where the
direction lives in the GPIO block, but on Vybrid the output buffer
enable is a bit of that pad. Patch 1 moves the call back below the
pinctrl step, where it was until 2019. Unchanged since v1.

Patch 2 makes the driver enable the vbus-supply of its port. In v1 it
guarded the regulator calls with CONFIG_IS_ENABLED(DM_REGULATOR) and a
NULL check; as Marek pointed out both are unnecessary, the calls return
-ENOSYS themselves, so it now looks like the adc-uclass example he gave.

Patch 2 applies on top of

  https://lore.kernel.org/u-boot/20260820071511.1036506-1-mehmet.fide@gmail.com/

Testing. test/py on sandbox, before and after patch 1: 11 failed, 414
passed, 210 skipped, 1 xfailed, 20 errors, the same failures both times.

On a Colibri VF50 V1.2A on an Iris carrier, U-Boot 2026.07 from NAND:
"usb start" finds a USB stick, its partition table and blocks read back,
the pad of the VBUS pin reads 0x22ef instead of 0x22ed, and Linux still
boots with Ethernet, SD card and USB working.

v1: https://lore.kernel.org/u-boot/20260819143543.427396-1-mehmet.fide@gmail.com/

Mehmet Fide (2):
  dm: core: read the device tree into plat data after pinctrl
  usb: ehci-vf: enable the vbus supply of the port

 drivers/core/device.c      |  8 ++++----
 drivers/usb/host/ehci-vf.c | 25 ++++++++++++++++++++++++-
 2 files changed, 28 insertions(+), 5 deletions(-)

-- 
2.54.0

[PATCH v2 1/2] dm: core: read the device tree into plat data after pinctrl

[Mehmet Fide]

From: Mehmet Fide <mehmet.fide@screeningeagle.com>

device_probe() calls device_of_to_plat() before it applies the "default"
pinctrl state of the device, so a driver that acquires resources there
sees them undone by the pinctrl state that follows.

It has not always been that way. When the pinctrl uclass arrived in
commit d90a5a30dec1 ("pinctrl: add pin control uclass support") the
state was selected before ->ofdata_to_platdata() was called, and it
stayed that way for four years. Commit 29f7d05a347a ("dm: core: Move
ofdata_to_platdata() call earlier") then moved the call up so that the
platform data would be read before the device is probed, which is
reasonable in itself, but it also moved it above the pinctrl state,
which nothing asked for.

GPIOs are where this hurts. On most SoCs the direction of a pin lives in
the GPIO block, so a pinctrl state cannot disturb it, but on Vybrid the
output buffer enable is a bit of the pad register that pinctrl writes as
well. A fixed regulator asks for its enable GPIO in of_to_plat(), so the
pin is configured as an output and the pinctrl state of the same device
then turns it back into an input. The USB host VBUS regulator of a
Colibri VF50 is one of those: its pad reads 0x22ed once the regulator
has been probed, the value from the device tree, output buffer disabled,
and no USB device is ever powered.

Move the call back below the pinctrl step. That is also the order Linux
uses, and the order the board code of these boards used before the
driver model: set the pin muxing up first, then take the pin. The
pinctrl step itself cannot move up instead, because it relies on
DM_FLAG_ACTIVATED having been set to break the recursion described above
it.

Nothing between the two positions needs plat data: the parent probe, the
power domain and the pinctrl call all work off the device tree.

Tested with test/py on sandbox, before and after: 11 failed, 414 passed,
210 skipped, 1 xfailed, 20 errors, the same failures both times, all of
them from tools and images missing in my environment.

Tested on a Colibri VF50 V1.2A on an Iris carrier, U-Boot 2026.07 from
NAND: the pad of the VBUS pin reads 0x22ef after "usb start" instead of
0x22ed, a USB stick in the host port enumerates, and Linux still boots
with Ethernet, SD card and USB working.

Fixes: 29f7d05a347a ("dm: core: Move ofdata_to_platdata() call earlier")
Signed-off-by: Mehmet Fide <mehmet.fide@screeningeagle.com>
---
 drivers/core/device.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/core/device.c b/drivers/core/device.c
index 6024534ff93..ccdf0ab9220 100644
--- a/drivers/core/device.c
+++ b/drivers/core/device.c
@@ -500,10 +500,6 @@ int device_probe(struct udevice *dev)
 	drv = dev->driver;
 	assert(drv);
 
-	ret = device_of_to_plat(dev);
-	if (ret)
-		goto fail;
-
 	/* Ensure all parents are probed */
 	if (dev->parent) {
 		ret = device_probe(dev->parent);
@@ -552,6 +548,10 @@ int device_probe(struct udevice *dev)
 				  dev->name, ret, errno_str(ret));
 	}
 
+	ret = device_of_to_plat(dev);
+	if (ret)
+		goto fail;
+
 	if (CONFIG_IS_ENABLED(IOMMU) && dev->parent &&
 	    (device_get_uclass_id(dev) != UCLASS_IOMMU)) {
 		ret = dev_iommu_enable(dev);
-- 
2.54.0

[PATCH v2 2/2] usb: ehci-vf: enable the vbus supply of the port

[Mehmet Fide]

From: Mehmet Fide <mehmet.fide@screeningeagle.com>

The driver never looks at the vbus-supply of its port, so on a board
where VBUS is switched by a regulator, as it is on the Colibri VF50 and
VF61 carriers, the port stays unpowered and no device is ever found.

Take the regulator the way ehci-mx6 does: look it up in probe, enable it
in host mode and disable it in device mode when the controller comes up,
and turn it off again when the controller is removed. The regulator
calls handle a missing supply and a build without DM_REGULATOR
themselves, both return -ENOSYS, so the driver only has to look at what
they return.

Signed-off-by: Mehmet Fide <mehmet.fide@screeningeagle.com>
---
 drivers/usb/host/ehci-vf.c | 25 ++++++++++++++++++++++++-
 1 file changed, 24 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/ehci-vf.c b/drivers/usb/host/ehci-vf.c
index 6c9866bfa5f..f7c10e183d0 100644
--- a/drivers/usb/host/ehci-vf.c
+++ b/drivers/usb/host/ehci-vf.c
@@ -21,6 +21,7 @@
 #include <asm/mach-imx/regs-usbphy.h>
 #include <linux/delay.h>
 #include <usb/ehci-ci.h>
+#include <power/regulator.h>
 #include <linux/libfdt.h>
 
 #include "ehci.h"
@@ -53,6 +54,7 @@ struct ehci_vf_priv_data {
 	struct anadig_reg __iomem *anatop_addr;
 	void __iomem *phy_addr;
 	void __iomem *misc_addr;
+	struct udevice *vbus_supply;
 	int portnr;
 };
 
@@ -143,6 +145,13 @@ static int ehci_vf_common_init(struct ehci_vf_priv_data *priv)
 	usb_internal_phy_clock_gate(priv->phy_addr);
 	usb_phy_enable(priv->phy_addr, priv->ehci);
 
+	ret = regulator_set_enable_if_allowed(priv->vbus_supply,
+					      priv->init_type != USB_INIT_DEVICE);
+	if (ret && ret != -ENOSYS) {
+		printf("Error enabling VBUS supply (ret=%i)\n", ret);
+		return ret;
+	}
+
 	return 0;
 }
 
@@ -284,6 +293,11 @@ static int ehci_usb_probe(struct udevice *dev)
 	struct ehci_hcor *hcor;
 	int ret;
 
+	ret = device_get_supply_regulator(dev, "vbus-supply",
+					  &priv->vbus_supply);
+	if (ret)
+		debug("%s: no vbus supply\n", dev->name);
+
 	ret = ehci_vf_common_init(priv);
 	if (ret)
 		return ret;
@@ -311,12 +325,21 @@ static const struct udevice_id vf_usb_ids[] = {
 	{ }
 };
 
+static int ehci_usb_remove(struct udevice *dev)
+{
+	struct ehci_vf_priv_data *priv = dev_get_priv(dev);
+
+	regulator_set_enable_if_allowed(priv->vbus_supply, false);
+
+	return ehci_deregister(dev);
+}
+
 U_BOOT_DRIVER(ehci_vf) = {
 	.name = "ehci_vf",
 	.id = UCLASS_USB,
 	.of_match = vf_usb_ids,
 	.probe = ehci_usb_probe,
-	.remove = ehci_deregister,
+	.remove = ehci_usb_remove,
 	.ops = &ehci_usb_ops,
 	.of_to_plat = vf_usb_of_to_plat,
 	.plat_auto	= sizeof(struct usb_plat),
-- 
2.54.0

Re: [PATCH v2 2/2] usb: ehci-vf: enable the vbus supply of the port

[Marek Vasut]

On 8/20/26 9:15 AM, Mehmet Fide wrote:

[...]

> @@ -284,6 +293,11 @@ static int ehci_usb_probe(struct udevice *dev)
>   	struct ehci_hcor *hcor;
>   	int ret;
>   
> +	ret = device_get_supply_regulator(dev, "vbus-supply",
> +					  &priv->vbus_supply);
> +	if (ret)
> +		debug("%s: no vbus supply\n", dev->name);
What happens if this returns -ENOMEM , is such an error safe to ignore too ?