usb1_drvvbus let me control USB VBUS ?

In my cape I need to turn on/off a USB device which is connected to the USB host port of the Bone. So I added my own TPS2051 to control this.

But fiddling with OMAP MUX I found this:

/sys/kernel/debug/omap_mux/usb1_drvvbus which by defaults is in mode 0:

cat /sys/kernel/debug/omap_mux/usb1_drvvbus
name: usb1_drvvbus.usb1_drvvbus (0x44e10a34/0xa34 = 0x0000), b NA, t NA
mode: OMAP_PIN_OUTPUT | OMAP_MUX_MODE0
signals: usb1_drvvbus | NA | NA | NA | NA | NA | NA | gpio3_13

Ahaha ! I said I can set that to mode 7 and the control GPIO3_13 to turn VBUS on/off on that port. Nice !

As soon I made:

echo 7 > /sys/kernel/debug/omap_mux/usb1_drvvbus

Indeed VBUS on the port got to 0V and I suppose my device got disconnected but my logs fills with:

[ 2569.940362] hub 1-0:1.0: over-current condition on port 1
[ 2570.200331] hub 1-0:1.0: over-current condition on port 1
[ 2570.460414] hub 1-0:1.0: over-current condition on port 1
[ 2570.720308] hub 1-0:1.0: over-current condition on port 1

After reenable usb1_drvvbus:

echo 0 > /sys/kernel/debug/omap_mux/usb1_drvvbus

My device is reconnected:

[ 2570.980409] hub 1-0:1.0: over-current condition on port 1
[ 2571.095959] usb 1-1: USB disconnect, device number 4
[ 2571.410356] usb 1-1: new high-speed USB device number 5 using musb-hdrc
[ 2571.556404] usb 1-1: New USB device found, idVendor=1bc7, idProduct=0021

But I was specting that after enabling mode 7 I get a USB disconnect, but here I got an overcurrent message (but VBUS dropped to 0V) and after reenabling my USB just got re-detected.

Is that the idea of that mix of usb1_drvvbus (that goes to the TPS2051 on schematics) and GPIO3_13 mix ?

A couple of notes:

1- Kernel 3.2.28-psp21
2- My USB device is self powered by the SYS 5V of the cape.

Thanks in advance.