DWC2 Driver: Unable to power cycle vbus regulator enabled USB port more than once.

[gizahNL]

Describe the bug

I have a CM5 where I need to switch off USB 5v VBUS to the USB2 (OTG) USB Port, this is implemented on our PCB.

While implementing my voltage regulator driver I noticed that I can only power cycle the USB port once, further power cycle requests (i.e. via uhubctl) fail to disable the regulator. And the regulator usage count stays >0.

I've asked claude for possible reasons, this is what it responded with:

● Found the definitive mechanism. dwc2_core_host_init only re-asserts HPRT0_PWR if it was cleared — and it's called from dwc2_hcd_reinit during _dwc2_hcd_resume. Now let me confirm the call
  chain and the final write at line 4548:

  The root cause is now fully identified:

  _dwc2_hcd_resume is registered as the bus_resume hook (line 5052-5053). When the USB bus resumes from a suspended state (lx_state == DWC2_L2), it does three things that fight
  ClearPortFeature(PORT_POWER):

  1. Line 4508: dwc2_hcd_reinit → dwc2_core_host_init (line 2262-2270): if op_state == OTG_STATE_A_HOST (which is always set for dr_mode = "host") and HPRT0_PWR is currently 0 — it writes it
   back to 1.
  2. Line 4538: dwc2_vbus_supply_init — unconditional regulator_enable, incrementing use_count.
  3. Line 4548: explicitly writes HPRT0_PWR | HPRT0_CONNDET | HPRT0_ENACHG to HPRT0 — forcing HPRT0_PWR = 1 regardless.

  The trigger sequence:
  1. ClearPortFeature(PORT_POWER) clears HPRT0_PWR = 0, calls dwc2_vbus_supply_exit
  2. If the bus was in lx_state = DWC2_L2 (auto-suspended), OR the device disconnect event causes the USB core to call bus_resume to process the port status change...
  3. _dwc2_hcd_resume runs: lx_state == L2 check passes, CONNSTS == 0 check passes (device just disconnected), falls through to the full resume path
  4. HPRT0_PWR is re-written to 1, use_count is incremented again

  Why the bus is in L2: USB autosuspend. When the connected device goes idle (default: 2 seconds), the USB stack auto-suspends it, then auto-suspends the root hub, calling bus_suspend →
  _dwc2_hcd_suspend → sets lx_state = L2.

  ---
  Fix: disable root hub autosuspend

  echo -1 > /sys/bus/usb/devices/usb1/power/autosuspend_delay

  With autosuspend disabled, _dwc2_hcd_suspend (bus_suspend) is never called, lx_state stays at DWC2_L0, and _dwc2_hcd_resume exits immediately at line 4455:
  if (hsotg->lx_state != DWC2_L2)
      goto unlock;  // ← exits here, no HPRT0_PWR re-assertion

  To make this permanent, add a udev rule:
  # /etc/udev/rules.d/99-usb-no-autosuspend.rules
  ACTION=="add", SUBSYSTEM=="usb", DRIVER=="usb", ATTR{idVendor}=="0000", \
      ATTR{power/autosuspend_delay}="-1"

  Or target the root hub specifically:
  ACTION=="add", SUBSYSTEM=="usb", KERNELS=="usb1", ATTR{power/autosuspend_delay}="-1"

  The deeper issue: DWC2's bus_resume is designed to unconditionally restore port power (it has no awareness that ClearPortFeature(PORT_POWER) was intentional). ClearPortFeature(PORT_POWER)
  and bus autosuspend/resume are fighting each other. Disabling autosuspend removes bus_suspend/resume from the equation entirely, leaving use_count managed only by _dwc2_hcd_start (initial
  enable) and ClearPortFeature/SetPortFeature (user's uhubctl calls).

Disabling autosuspend does indeed work around the issue.

Steps to reproduce the behaviour

Couple a regulator to the USB port via a dtoverlay (untested example!):

/dts-v1/;
/plugin/;
/{
    compatible = "brcm,bcm2708";
    fragment@0 {
    target-path = "/";
        __overlay__ {
            usb_power_regulator: fixedregulator@0 {
                compatible = "regulator-fixed";
                regulator-name = "fixed-supply";
                regulator-min-microvolt = <5000000>;
                regulator-max-microvolt = <5000000>;
                gpio = <&gpios 14 0>;
                enable-active-high;
            };
        };
    };
    fragment@1 {
        target = <&usb>;
        dwc2_usb: __overlay__ {
                power-domains = <0 0>;
                compatible = "brcm,bcm2835-usb";
                dr_mode = "host";
                g-np-tx-fifo-size = <32>;
                g-rx-fifo-size = <558>;
                g-tx-fifo-size = <512 512 512 512 512 256 256>;
                status = "okay";
                vbus-supply = <&usb_power_regulator>;
        };
    };
};

And use uhubctrl to disable the USB port (CM5):
uhubctl -l 5 -p 1 -a off
verify the regulator switched to disabled via sysfs then re-enable it:
uhubctl -l 5 -p 1 -a on

Observe the regulator is back on, then repeat and observe the regulator doesn't get disabled anymore

Device (s)

Raspberry Pi CM5

System

CM5, custom receiver PCB, Custom Yocto based OS, RPI-Linux 6.12.75

Logs

No response

Additional context

If this is by design, feel free to close, the work-around also works for me.

[lategoodbye]

I have some questions:
You said that your PCB has a OTG USB port, but dr_mode in your overlay is set to "host". This doesn't match.
Why does your overlay set the power domain with "0 0"?
AFAIK the port power and VBUS regulator are completely different things. The first is controlled by the DWC2 IP core and the second is controlled by regulator framework of the Linux kernel.
Did you tried to test the GPIO regulator instead of your custom regulator driver?

[gizahNL]

Yeah, I wasn't completely clear, with OTG I meant the USB2 port, which requires the overlay to enable. It's used in host mode.

The power domain reset is a leftover from earlier testing, to try and figure out why the power cycle only works once.

So to the best of my knowledge in the dwc2 driver you're able to point to a regulator used for vbus-supply in the DTB, which should turn off if port power is disabled via uhubctl (or sysfs), which does work in this way once, a secondary attempt at power cycling fails.

I'm happy to try with a simple gpio, I have another board which I configured today to do exactly that (with a sysfs write to set the autosuspend timer to -1 in the cycling script). With the autosuspend disabled that works as expected, I haven't tested it without that.

[gizahNL]

I've made a cut from an actual DTB I'm using on a CM4 based board:

/dts-v1/;
/plugin/;
/{
    //// GPIO PIN Configuration

    compatible = "brcm,bcm2708";
    fragment@0 {
        target = <&usb>;
        dwc2_usb: __overlay__ {
                compatible = "brcm,bcm2835-usb";
                dr_mode = "host";
                g-np-tx-fifo-size = <32>;
                g-rx-fifo-size = <558>;
                g-tx-fifo-size = <512 512 512 512 512 256 256>;
                status = "okay";
                vbus-supply = <&usb_5v>;
        };
    };

    fragment@1 {
        target-path = "/";
        __overlay__ {
            vcc_5v: regulator-vcc_5v {
                compatible = "regulator-fixed";
                regulator-name = "VCC_5V";
                regulator-min-microvolt = <5000000>;
                regulator-max-microvolt = <5000000>;
                regulator-always-on;
            };

            usb_5v: regulator_usb_5v {
                compatible = "regulator-fixed";
                regulator-name = "MODEM_VBUS";
                regulator-min-microvolt = <5000000>;
                regulator-max-microvolt = <5000000>;
                gpio = <&gpio 20 0>;
                enable-active-high;
                regulator-boot-on;
                vin-supply = <&vcc_5v>;
            };
        };
    };
};

And here is a test script (CM4, can't guarantee that the regulator index will remain the same):

#!/bin/bash

GPIOPIN=20
REGULATORINDEX=5
USBHUB=1
USBPORT=1

#echo "Disabling autosuspend"
#echo -1 > /sys/bus/usb/devices/usb${USBHUB}/power/autosuspend_delay_ms

echo "Disabling USB port power"
uhubctl -l ${USBHUB} -p ${USBPORT} -a off &> /dev/null

echo "Regulator status:"
cat /sys/class/regulator/regulator.${REGULATORINDEX}/state
echo "GPIO status:"
pinctrl get ${GPIOPIN}

echo "Waiting 1 second"
sleep 1 

echo "Turning USB back on"
uhubctl -l ${USBHUB} -p ${USBPORT} -a on &> /dev/null

echo "Regulator status:"
cat /sys/class/regulator/regulator.${REGULATORINDEX}/state
echo "GPIO status:"
pinctrl get ${GPIOPIN}

It fails when I comment out the -1 write to autosuspend_delay_ms, then the second time I run the script the regulator remains in enabled state, and the GPIO pin remains high. (a reboot might be needed to then clear this situation).

In my tests there is also a modem attached to the USB port & it actually loses power when the GPIO line goes low, which might be needed to reproduce this (not sure tbh).

[lategoodbye]

Just for understanding the USB port of the BCM271x is directly connected, there are no USB hubs between them?

[gizahNL]

Yes. Both are directly connected to a Simcom7600 modem on a MiniPCIe formfactor slot, we don't have a HUB in front.