Re: [PATCH v2] usb: port: add delay after usb_hub_set_port_power()
From: Xu Yang
Date: Thu Feb 26 2026 - 05:59:02 EST
On Wed, Feb 25, 2026 at 05:13:17PM -0300, Fabio Estevam wrote:
> Hi Xu Yang,
>
> On Wed, Feb 25, 2026 at 4:47 AM Xu Yang <xu.yang_2@xxxxxxx> wrote:
> >
> > Hi Fabio,
> >
> > On Tue, Feb 24, 2026 at 09:19:51AM -0300, Fabio Estevam wrote:
> > > Hi Xu Yang,
> > >
> > > On Tue, Feb 24, 2026 at 12:17 AM Xu Yang <xu.yang_2@xxxxxxx> wrote:
> > > >
> > > > When a port is disabled, an attached device will be disconnected. This
> > > > causes a port-status-change event, which will race with hub autosuspend
> > > > (if the disabled port was the only connected port on its hub), causing
> > > > an immediate resume and a second autosuspend. Both of these can be
> > > > avoided by adding a short delay after the call to
> > > > usb_hub_set_port_power().
> > > >
> > > > Below log shows what is happening:
> > > >
> > > > $ echo 1 > usb1-port1/disable
> > > > [ 37.958239] usb 1-1: USB disconnect, device number 2
> > > > [ 37.964101] usb 1-1: unregistering device
> > > > [ 37.970070] hub 1-0:1.0: hub_suspend
> > > > [ 37.971305] hub 1-0:1.0: state 7 ports 1 chg 0000 evt 0002
> > > > [ 37.974412] usb usb1: bus auto-suspend, wakeup 1
> > > > [ 37.988175] usb usb1: suspend raced with wakeup event <---
> > > > [ 37.993947] usb usb1: usb auto-resume
> > > > [ 37.998401] hub 1-0:1.0: hub_resume
> > > > [ 38.105688] usb usb1-port1: status 0000, change 0000, 12 Mb/s
> > > > [ 38.112399] hub 1-0:1.0: state 7 ports 1 chg 0000 evt 0000
> > > > [ 38.118645] hub 1-0:1.0: hub_suspend
> > > > [ 38.122963] usb usb1: bus auto-suspend, wakeup 1
> > > > [ 38.200368] usb usb1: usb wakeup-resume
> > > > [ 38.204982] usb usb1: usb auto-resume
> > > > [ 38.209376] hub 1-0:1.0: hub_resume
> > > > [ 38.213676] usb usb1-port1: status 0101 change 0001
> > > > [ 38.321552] hub 1-0:1.0: state 7 ports 1 chg 0002 evt 0000
> > > > [ 38.327978] usb usb1-port1: status 0101, change 0000, 12 Mb/s
> > > > [ 38.457429] usb 1-1: new high-speed USB device number 3 using ci_hdrc
> > > >
> > > > Then, port change bit will be fixed to the final state and
> > > > usb_clear_port_feature() can correctly clear it after this period. This
> > > > will also avoid usb runtime suspend routine to run because
> > > > usb_autopm_put_interface() not run yet.
> > > >
> > > > Fixes: f061f43d7418 ("usb: hub: port: add sysfs entry to switch port power")
> > > > Cc: stable@xxxxxxxxxx
> > > > Signed-off-by: Xu Yang <xu.yang_2@xxxxxxx>
> > >
> > > On an imx6x-sdb board, I still get the inconsistency below even after
> > > applying your patch:
> > >
> > > # echo 1 > /sys/bus/usb/devices/1-0\:1.0/usb1-port1/disable
> > > [ 20.656414] usb 1-1: USB disconnect, device number 2
> > >
> > > # echo 1 > /sys/bus/usb/devices/1-0\:1.0/usb1-port1/disable
> > > [ 28.263516] usb 1-1: new high-speed USB device number 3 using ci_hdrc
> > > [ 28.466813] usb 1-1: New USB device found, idVendor=0457,
> > > idProduct=0151, bcdDevice= 1.00
> > > [ 28.466949] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> > > [ 28.467039] usb 1-1: Product: USB Mass Storage Device
> > > [ 28.467086] usb 1-1: Manufacturer: USBest Technology
> > > [ 28.467126] usb 1-1: SerialNumber: 000000000003FF
> > > [ 28.501826] usb-storage 1-1:1.0: USB Mass Storage device detected
> > > [ 28.510452] usb-storage 1-1:1.0: Quirks match for vid 0457 pid 0151: 80
> > > [ 28.517597] scsi host0: usb-storage 1-1:1.0
> > > [ 28.524066] usb 1-1: USB disconnect, device number 3
> >
> > It's another different problem.
> >
> > For ports which VBUS are not controlled by PORTSC.PP (always on VBUS
> > regulator or Type-C controlled VBUS), they are still powered on after
> > you disable the ports. This will cause PORTSC.CCS still be set after it.
> >
> > When usb_autopm_get_interface() gets called, hub_resume will check CCS
> > bit and check new connection again. So you see new device is reported.
> >
> > Below patch will be a workaround for the issue when you disable the port
> > many times:
> > https://lore.kernel.org/linux-usb/20260223-v6-16-topic-usb-onboard-dev-v5-1-28d3018a8026@xxxxxxxxxxxxxx/
>
> I applied Marco's patch, and it fixes the inconsistent state that I
> reported before on the imx6sx-sdb:
>
> # echo 1 > /sys/bus/usb/devices/1-0\:1.0/usb1-port1/disable
> [ 110.494838] usb 1-1: USB disconnect, device number 3
> # echo 1 > /sys/bus/usb/devices/1-0\:1.0/usb1-port1/disable
> # echo 1 > /sys/bus/usb/devices/1-0\:1.0/usb1-port1/disable
> # echo 1 > /sys/bus/usb/devices/1-0\:1.0/usb1-port1/disable
> # echo 1 > /sys/bus/usb/devices/1-0\:1.0/usb1-port1/disable
> # echo 1 > /sys/bus/usb/devices/1-0\:1.0/usb1-port1/disable
>
> Now I want the USB OTG2 VBUS to be turned off.
>
> I understand that the chipidea driver does not turn off VBUS when
> vbus-supply is passed, so I tried using the pin as
> MX6SX_PAD_GPIO1_IO12__USB_OTG2_PWR:
No. You can't do this because CI_HDRC_TURN_VBUS_EARLY_ON won't take effect
as we talked in previous thread. Then, USB phy will work abnormally.
I recommend to unbind/bind the device for switching VBUS off/on.
Thanks,
Xu Yang