[PATCH 1/1] usb: dwc3: dwc3-generic-plat: Add optional VBUS regulator support

[PATCH 1/1] usb: dwc3: dwc3-generic-plat: Add optional VBUS regulator support

[Chukun Pan]

Some boards provide USB VBUS through a controllable regulator. Add
support for the optional vbus-supply property so the regulator can
be properly managed instead of left always-on. Note that this does
not apply to USB Hub downstream ports with different VBUS supplies.

The enabled and disabled actions of the regulator are handled
automatically by devm_regulator_get_enable_optional().

Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
---
The vbus-supply property has been declared in spacemit,k1-dwc3.yaml
https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/usb/spacemit%2Ck1-dwc3.yaml#L71
---
 drivers/usb/dwc3/dwc3-generic-plat.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/usb/dwc3/dwc3-generic-plat.c b/drivers/usb/dwc3/dwc3-generic-plat.c
index e846844e0023..83b4e4d69ba9 100644
--- a/drivers/usb/dwc3/dwc3-generic-plat.c
+++ b/drivers/usb/dwc3/dwc3-generic-plat.c
@@ -12,6 +12,7 @@
 #include <linux/reset.h>
 #include <linux/regmap.h>
 #include <linux/mfd/syscon.h>
+#include <linux/regulator/consumer.h>
 #include "glue.h"
 
 #define EIC7700_HSP_BUS_FILTER_EN	BIT(0)
@@ -113,6 +114,10 @@ static int dwc3_generic_probe(struct platform_device *pdev)
 	if (ret < 0)
 		return dev_err_probe(dev, ret, "failed to get clocks\n");
 
+	ret = devm_regulator_get_enable_optional(dev, "vbus");
+	if (ret && ret != -ENODEV)
+		return dev_err_probe(dev, ret, "failed to enable VBUS\n");
+
 	dwc3g->num_clocks = ret;
 	dwc3g->dwc.dev = dev;
 	probe_data.dwc = &dwc3g->dwc;
-- 
2.34.1

Re: [PATCH 1/1] usb: dwc3: dwc3-generic-plat: Add optional VBUS regulator support

[Ze Huang]

On Mon Mar 16, 2026 at 4:00 PM CST, Chukun Pan wrote:
> Some boards provide USB VBUS through a controllable regulator. Add
> support for the optional vbus-supply property so the regulator can
> be properly managed instead of left always-on. Note that this does
> not apply to USB Hub downstream ports with different VBUS supplies.
>
> The enabled and disabled actions of the regulator are handled
> automatically by devm_regulator_get_enable_optional().
>
> Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
> ---
> The vbus-supply property has been declared in spacemit,k1-dwc3.yaml
> https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/usb/spacemit%2Ck1-dwc3.yaml#L71
> ---
>  drivers/usb/dwc3/dwc3-generic-plat.c | 5 +++++
>  1 file changed, 5 insertions(+)
>
> diff --git a/drivers/usb/dwc3/dwc3-generic-plat.c b/drivers/usb/dwc3/dwc3-generic-plat.c
> index e846844e0023..83b4e4d69ba9 100644
> --- a/drivers/usb/dwc3/dwc3-generic-plat.c
> +++ b/drivers/usb/dwc3/dwc3-generic-plat.c
> @@ -12,6 +12,7 @@
>  #include <linux/reset.h>
>  #include <linux/regmap.h>
>  #include <linux/mfd/syscon.h>
> +#include <linux/regulator/consumer.h>
>  #include "glue.h"
>  
>  #define EIC7700_HSP_BUS_FILTER_EN	BIT(0)
> @@ -113,6 +114,10 @@ static int dwc3_generic_probe(struct platform_device *pdev)
>  	if (ret < 0)
>  		return dev_err_probe(dev, ret, "failed to get clocks\n");
>  
> +	ret = devm_regulator_get_enable_optional(dev, "vbus");
> +	if (ret && ret != -ENODEV)
> +		return dev_err_probe(dev, ret, "failed to enable VBUS\n");
> +
>  	dwc3g->num_clocks = ret;
>  	dwc3g->dwc.dev = dev;
>  	probe_data.dwc = &dwc3g->dwc;

This could be useful for boards with direct-attached VBUS.

Just to clarify, the vbus-supply binding is for potential direct-attached
designs. For current boards (like K1 BPI-F3 and Jupiter) with the VL817 hub,
we'll use onboard_usb_dev instead.

Re: [PATCH 1/1] usb: dwc3: dwc3-generic-plat: Add optional VBUS regulator support

[Thinh Nguyen]

On Mon, Mar 16, 2026, Chukun Pan wrote:
> Some boards provide USB VBUS through a controllable regulator. Add

If we have a specific user, please include it in the change log. In this
case, it looks like spacemit k1 as noted under the "---" line?

> support for the optional vbus-supply property so the regulator can
> be properly managed instead of left always-on. Note that this does
> not apply to USB Hub downstream ports with different VBUS supplies.
> 
> The enabled and disabled actions of the regulator are handled
> automatically by devm_regulator_get_enable_optional().
> 
> Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
> ---
> The vbus-supply property has been declared in spacemit,k1-dwc3.yaml
> https://urldefense.com/v3/__https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/usb/spacemit*2Ck1-dwc3.yaml*L71__;JSM!!A4F2R9G_pg!eSm5G5c19zlsLK5DkD6WgQ1EgAL-mnHHd90kLRFzrgMWts8d0dfjK5HglU-SA4RLpLkgMEcA0Z2GgfsR_cBJnnub$ 
> ---
>  drivers/usb/dwc3/dwc3-generic-plat.c | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/usb/dwc3/dwc3-generic-plat.c b/drivers/usb/dwc3/dwc3-generic-plat.c
> index e846844e0023..83b4e4d69ba9 100644
> --- a/drivers/usb/dwc3/dwc3-generic-plat.c
> +++ b/drivers/usb/dwc3/dwc3-generic-plat.c
> @@ -12,6 +12,7 @@
>  #include <linux/reset.h>
>  #include <linux/regmap.h>
>  #include <linux/mfd/syscon.h>
> +#include <linux/regulator/consumer.h>
>  #include "glue.h"
>  
>  #define EIC7700_HSP_BUS_FILTER_EN	BIT(0)
> @@ -113,6 +114,10 @@ static int dwc3_generic_probe(struct platform_device *pdev)
>  	if (ret < 0)
>  		return dev_err_probe(dev, ret, "failed to get clocks\n");
>  
> +	ret = devm_regulator_get_enable_optional(dev, "vbus");
> +	if (ret && ret != -ENODEV)
> +		return dev_err_probe(dev, ret, "failed to enable VBUS\n");
> +

The name "vbus" here maybe confusing. This regulator powers the
controller chip and not neccessarily turning on VBUS of the USB bus
power line. Is there a common/different name for regulator id? At least
fix the error message.

Thanks,
Thinh

>  	dwc3g->num_clocks = ret;
>  	dwc3g->dwc.dev = dev;
>  	probe_data.dwc = &dwc3g->dwc;
> -- 
> 2.34.1
> 

Re: [PATCH 1/1] usb: dwc3: dwc3-generic-plat: Add optional VBUS regulator support

[Chukun Pan]

Hi,

> If we have a specific user, please include it in the change log. In this
> case, it looks like spacemit k1 as noted under the "---" line?

I will change it to "Some SpacemiT K1 board".

> The name "vbus" here maybe confusing. This regulator powers the
> controller chip and not neccessarily turning on VBUS of the USB bus
> power line. Is there a common/different name for regulator id?
> At least fix the error message.

Sorry, but I don't quite understand what you mean.
Taking the OrangePi RV2 [1] board as an example:

VCC_5V0 (IN) -> VCC5V0_USB3 (OUT) -> Vbus30

The VCC5V0_USB3 regulator is connected to the USB vbus pin.
I think it's okay to call it "vbus" here?

[1] https://drive.google.com/drive/folders/1pcI_U0C3VJKTCg8A1zj08CwNbohnONSR

Thanks,
Chukun

Re: [PATCH 1/1] usb: dwc3: dwc3-generic-plat: Add optional VBUS regulator support

[Thinh Nguyen]

On Wed, Mar 18, 2026, Chukun Pan wrote:
> Hi,
> 
> > If we have a specific user, please include it in the change log. In this
> > case, it looks like spacemit k1 as noted under the "---" line?
> 
> I will change it to "Some SpacemiT K1 board".
> 
> > The name "vbus" here maybe confusing. This regulator powers the
> > controller chip and not neccessarily turning on VBUS of the USB bus
> > power line. Is there a common/different name for regulator id?
> > At least fix the error message.
> 
> Sorry, but I don't quite understand what you mean.
> Taking the OrangePi RV2 [1] board as an example:
> 
> VCC_5V0 (IN) -> VCC5V0_USB3 (OUT) -> Vbus30
> 
> The VCC5V0_USB3 regulator is connected to the USB vbus pin.
> I think it's okay to call it "vbus" here?
> 

I mean this is a generic glue driver and not specific to your spacemit
k1. Some platforms use regulators to drive the vbus (e.g. dwc3 meson)
while others for internal controller supplies (e.g. dwc3 exynos). Also,
if the platform is operating in device mode, there should be no vbus.

Also do we want to disable the regulator on system suspend? If so, we
may need a regulator handle.

Perhaps can we pass the regulator id string through the
dwc3_generic_config? Create a new field to store this ID.

Something like this?

struct dwc3_generic_config {
	int (*init)(struct dwc3_generic *dwc3g);
	struct {
		const char *id;
		bool disable_on_suspend;
	} regulator;
	struct dwc3_properties properties;
};

BR,
Thinh

Re: [PATCH 1/1] usb: dwc3: dwc3-generic-plat: Add optional VBUS regulator support

[Chukun Pan]

Hi,

> I mean this is a generic glue driver and not specific to your spacemit
> k1. Some platforms use regulators to drive the vbus (e.g. dwc3 meson)
> while others for internal controller supplies (e.g. dwc3 exynos). Also,

So shouldn't the generic glue driver manage vbus, but rather the Spacemit
USB PHY driver? I don't have any good ideas about the current name.

> if the platform is operating in device mode, there should be no vbus.

Do I need to check if it's in host mode?

> Also do we want to disable the regulator on system suspend? If so, we
> may need a regulator handle.

I'll add it if you think it's necessary.

I'm not quite sure how to do it well, thank
you for taking the time to review.

Thanks,
Chukun

Re: [PATCH 1/1] usb: dwc3: dwc3-generic-plat: Add optional VBUS regulator support

[Thinh Nguyen]

On Thu, Mar 19, 2026, Chukun Pan wrote:
> Hi,
> 
> > I mean this is a generic glue driver and not specific to your spacemit
> > k1. Some platforms use regulators to drive the vbus (e.g. dwc3 meson)
> > while others for internal controller supplies (e.g. dwc3 exynos). Also,
> 
> So shouldn't the generic glue driver manage vbus, but rather the Spacemit
> USB PHY driver? I don't have any good ideas about the current name.

In my previous response, I noted to pass the name/id that best match
your platform in the dwc3_generic_config. This structure is passed as
private data corresponding to your k1 platform compatible string. That
should solve the naming issue (i.e. you can keep the name "vbus").

> 
> > if the platform is operating in device mode, there should be no vbus.
> 
> Do I need to check if it's in host mode?

Is your k1 a DRD controller, and that it can operate in device mode? If
so, does it save power to disable the regulator while operating in
device mode?

This is power saving optimization that should not impact functionality,
and it can be implemented in the future. However, it's better to keep
this in mind should this be the path forward in your future enhancement.

> 
> > Also do we want to disable the regulator on system suspend? If so, we
> > may need a regulator handle.
> 
> I'll add it if you think it's necessary.

Same comment as above, but this will be more involved. E.g. you may only
want to disable the vbus when remote wakeup is disabled and power saving
is more essential (disabling vbus will disconnect the device).

Thanks,
Thinh

> 
> I'm not quite sure how to do it well, thank
> you for taking the time to review.
> 

Re: [PATCH 1/1] usb: dwc3: dwc3-generic-plat: Add optional VBUS regulator support

[Chukun Pan]

Hi,

> In my previous response, I noted to pass the name/id that best match
> your platform in the dwc3_generic_config. This structure is passed as
> private data corresponding to your k1 platform compatible string. That
> should solve the naming issue (i.e. you can keep the name "vbus").

Thank you for your suggestion, I will change it to match compatible.

> > Do I need to check if it's in host mode?
>
> Is your k1 a DRD controller, and that it can operate in device mode?
> If so, does it save power to disable the regulator while operating in
> device mode?

It is a DRD controller that supports switching between Host and Device
modes. I will change it to enable regulator only in Host mode.

> > > Also do we want to disable the regulator on system suspend? If so,
> > > we may need a regulator handle.
> > 
> > I'll add it if you think it's necessary.
> >
> Same comment as above, but this will be more involved. E.g. you may only
> want to disable the vbus when remote wakeup is disabled and power saving
> is more essential (disabling vbus will disconnect the device).

I will consider implementing it in the future.

Thanks,
Chukun

Re: [PATCH 1/1] usb: dwc3: dwc3-generic-plat: Add optional VBUS regulator support

[Ze Huang]

On Fri Mar 20, 2026 at 2:36 PM CST, Chukun Pan wrote:
> Hi,
>
>> In my previous response, I noted to pass the name/id that best match
>> your platform in the dwc3_generic_config. This structure is passed as
>> private data corresponding to your k1 platform compatible string. That
>> should solve the naming issue (i.e. you can keep the name "vbus").
>
> Thank you for your suggestion, I will change it to match compatible.
>
>> > Do I need to check if it's in host mode?
>>
>> Is your k1 a DRD controller, and that it can operate in device mode?
>> If so, does it save power to disable the regulator while operating in
>> device mode?
>
> It is a DRD controller that supports switching between Host and Device
> modes. I will change it to enable regulator only in Host mode.
>
>> > > Also do we want to disable the regulator on system suspend? If so,
>> > > we may need a regulator handle.
>> > 
>> > I'll add it if you think it's necessary.
>> >
>> Same comment as above, but this will be more involved. E.g. you may only
>> want to disable the vbus when remote wakeup is disabled and power saving
>> is more essential (disabling vbus will disconnect the device).
>
> I will consider implementing it in the future.
>
> Thanks,
> Chukun

Hi Chukun,

I don't think it's a good idea to tie this optional VBUS regulator
implementation to the SpacemiT K1 platform.

While the K1 SoC does have a DRD controller, current boards in the wild
(like Jupiter[1], OrangePi RV2[2], and Banana Pi F3[3]) all route this
port to an onboard hub[4][5]. IMHO, managing the downstream VBUS regulator
via the onboard_usb_dev driver is the correct approach for us.

[1] https://github.com/milkv-jupiter/jupiter-files/blob/main/hardware/v1_0/jupiter-sch-v1_0.pdf (page 20)
[2] https://drive.google.com/drive/folders/1pcI_U0C3VJKTCg8A1zj08CwNbohnONSR (page 16)
[3] https://drive.google.com/file/d/19iLJ5xnCB_oK8VeQjkPGjzAn39WYyylv/view (page 24)
[4] https://www.lcsc.com/datasheet/C209756.pdf
[5] https://www.lcsc.com/datasheet/C157362.pdf

K1 platform currently does not need this feature here.

Considering the role switch, I think it would be better to hold off on this
until there is an actual board/user that relies on it.

Thanks,
Ze

Re: [PATCH 1/1] usb: dwc3: dwc3-generic-plat: Add optional VBUS regulator support

[Chukun Pan]

Hi,

> I don't think it's a good idea to tie this optional VBUS regulator
> implementation to the SpacemiT K1 platform.
>
> While the K1 SoC does have a DRD controller, current boards in the wild
> (like Jupiter[1], OrangePi RV2[2], and Banana Pi F3[3]) all route this
> port to an onboard hub[4][5]. IMHO, managing the downstream VBUS regulator
> via the onboard_usb_dev driver is the correct approach for us.

I'm sorry, but I don't quite understand why it's necessary to use
onboard_usb_dev driver instead.

The DRD controller is connected to the onboard USB hub, so it can
only operate in host mode. If all downstream ports of the USB hub
use the same VBUS supply, then what's the problem with using this?

> K1 platform currently does not need this feature here.
>
> Considering the role switch, I think it would be better to hold off on
> this until there is an actual board/user that relies on it.

There is a board without onboard USB hub, such as the OrangePi R2S.
So this is possible for boards that don't have onboard USB hub?

Thanks,
Chukun

Re: [PATCH 1/1] usb: dwc3: dwc3-generic-plat: Add optional VBUS regulator support

[Ze Huang]

Hi Chukun

On Fri Mar 20, 2026 at 4:18 PM CST, Chukun Pan wrote:
> Hi,
>
>> I don't think it's a good idea to tie this optional VBUS regulator
>> implementation to the SpacemiT K1 platform.
>>
>> While the K1 SoC does have a DRD controller, current boards in the wild
>> (like Jupiter[1], OrangePi RV2[2], and Banana Pi F3[3]) all route this
>> port to an onboard hub[4][5]. IMHO, managing the downstream VBUS regulator
>> via the onboard_usb_dev driver is the correct approach for us.
>
> I'm sorry, but I don't quite understand why it's necessary to use
> onboard_usb_dev driver instead.
>

I think it's better to align the driver with the actual hardware. I'm not
opposed to managing any regulators in usb host/device drivers. But if we
do have an onboard hub, and regulator belongs to the downstream ports of
the hub, then it's hub's job, right?

>
> The DRD controller is connected to the onboard USB hub, so it can
> only operate in host mode. If all downstream ports of the USB hub
> use the same VBUS supply, then what's the problem with using this?

It does work.

Many boards leave gpio controlled regulators always on, that's what we
want to solve. If we have to choose the parent of these regulators, why
not put them in the correct hierarchy?

>
>> K1 platform currently does not need this feature here.
>>
>> Considering the role switch, I think it would be better to hold off on
>> this until there is an actual board/user that relies on it.
>
> There is a board without onboard USB hub,

If such a board really need the regulator, IMO, your patch is the way to go.

>
> such as the OrangePi R2S.
> So this is possible for boards that don't have onboard USB hub?

OrangePi haven't released the schematic yet.

That's what I could find [1], which seems similar to RV2.

    &usb3hub {
    	vbus-gpios = <&gpio 123 0>;	/* gpio_123 for usb3 hub pwr and output vbus */
    	status = "okay";
    };

[1] https://github.com/orangepi-xunlong/linux-orangepi/blob/orange-pi-6.6-ky/arch/riscv/boot/dts/ky/x1_orangepi-r2s.dts#L762

>
> Thanks,
> Chukun

Thanks,
Ze

Re: [PATCH 1/1] usb: dwc3: dwc3-generic-plat: Add optional VBUS regulator support

[Chukun Pan]

Hi,

> I think it's better to align the driver with the actual hardware. I'm not
> opposed to managing any regulators in usb host/device drivers. But if we
> do have an onboard hub, and regulator belongs to the downstream ports of
> the hub, then it's hub's job, right?

> Many boards leave gpio controlled regulators always on, that's what we
> want to solve. If we have to choose the parent of these regulators, why
> not put them in the correct hierarchy?

I think we can manage the regulator in the USB host driver first,
and then use it after the onboard_usb_dev driver has been merged.
This is better than keeping the regulator always on.

> If such a board really need the regulator, IMO, your patch is the way to go.
>
> OrangePi haven't released the schematic yet.
>
> That's what I could find [1], which seems similar to RV2.

There is no onboard USB hub. Just check the image:

http://www.orangepi.org/img/r2s/details/17.png
http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/Orange-Pi-R2S.html

Thanks,
Chukun

Re: [PATCH 1/1] usb: dwc3: dwc3-generic-plat: Add optional VBUS regulator support

[Ze Huang]

On Fri Mar 20, 2026 at 6:40 PM CST, Chukun Pan wrote:
> Hi,
>
>> I think it's better to align the driver with the actual hardware. I'm not
>> opposed to managing any regulators in usb host/device drivers. But if we
>> do have an onboard hub, and regulator belongs to the downstream ports of
>> the hub, then it's hub's job, right?
>
>> Many boards leave gpio controlled regulators always on, that's what we
>> want to solve. If we have to choose the parent of these regulators, why
>> not put them in the correct hierarchy?
>
> I think we can manage the regulator in the USB host driver first,
> and then use it after the onboard_usb_dev driver has been merged.
> This is better than keeping the regulator always on.
>
>> If such a board really need the regulator, IMO, your patch is the way to go.
>>
>> OrangePi haven't released the schematic yet.
>>
>> That's what I could find [1], which seems similar to RV2.
>
> There is no onboard USB hub. Just check the image:
>
> http://www.orangepi.org/img/r2s/details/17.png
> http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/Orange-Pi-R2S.html
>

That's fine, thanks.

> Thanks,
> Chukun