On Friday 05 August 2005 23:25, Alan Stern wrote: > On Fri, 5 Aug 2005, Vlado Handziski wrote: > > > Hi all, > > > > our research group is involved in building a large sensor node testbed, and we > > need to control the power supply of a number of USB devices by turning on/off > > the supply of the ports on the hub they are connected to. The hubs that we > > are using are DUB-H4, a self-powered 4-port USB 2.0 hub branded as D-Link, > > using a Genesys Logic controller. > > > > Unfortunately, we are having problems with getting this to work with the more > > recent linux kernels and we don't have a record of the latest working ehci > > driver version. I would be grateful for any hints about potential changes in > > the drivers (in the last 5-6 months) that could have influenced the power > > control capability. > > See this patch from May 2004 (15 months ago): > > http://linux.bkbits.net:8080/linux-2.6/[EMAIL PROTECTED]|src/| src/drivers|src/drivers/usb|src/drivers/usb/core| related/drivers/usb/core/hub.c > > > Here is some debugging information: > > > > Bus 001 Device 002: ID 05e3:0660 Genesys Logic, Inc. > > > > Sending a control message to read the hub descriptor (using usb_control_msg > > from libusb), with enabled usbfs_snoop in the usbcore module returns: > > > > usb 1-3: usbdev_ioctl: CONTROL > > usb 1-3: control read: bRequest=06 bRrequestType=a0 wValue=0000 wIndex=0000 > > usb 1-3: control read: data 09 29 04 e9 00 32 64 00 ff > > > > According to table 11.23.2.1 in the USB 2.0 spec. "e9" says that the hub > > supports individual port power switching and over-current reporting. > > > > Checking the status of port-1 on the hub after the initialisation shows: > > > > usb 1-3: usbdev_ioctl: CONTROL > > usb 1-3: control read: bRequest=00 bRrequestType=a3 wValue=0000 wIndex=0001 > > usb 1-3: control read: data 00 01 00 00 > > > > and the same with a device connected: > > > > usb 1-3: usbdev_ioctl: CONTROL > > usb 1-3: control read: bRequest=00 bRrequestType=a3 wValue=0000 wIndex=0001 > > usb 1-3: control read: data 03 01 00 00 > > > > > > If we now send a command to turn off the power of port-1: > > > > usb 1-3: control write: bRequest=01 bRrequestType=23 wValue=0008 wIndex=0001 > > usb 1-3: control write: data: > > > > the port-1 status changes into power-down state: > > > > usb 1-3: control read: bRequest=00 bRrequestType=a3 wValue=0000 wIndex=0001 > > usb 1-3: control read: data 00 00 00 00 > > > > > > Unfortunately the power (in electrical terms) is still on and the LED > > indicator remains lit. With the older kernels, at this point of time, the LED > > was turned off and the power was disconnected. > > You will find what you're looking for in the hub_port_connect_change > routine of the hub driver. If a logical or physical connect change > occurs, the driver will automatically turn the port's power back on. > > It's not clear why the connect-change event occurs. Clearly there has > been a connection change, but once power is off the port should set all > its status bits to 0, including the connect-change bit. > > If you turn on verbose USB debugging in the kernel configuration > (CONFIG_USB_DEBUG) you might learn more.
Hi Alan, Thanks for the pointers. Unfortunately, even with debugging on, I can not detect any connect-change event. As you can see above, after sending the command to turn-off the power of the port, the port status query does return "data 00 00 00 00", and it stays zero until I send a command to set the power back on. But although the status says that the power is off, the power is still on! Do you know how the port status reply is generated? I.e. Is the HW queried, or some cached values in the driver are used? It is as the commands that I am sending are never reaching the hub, but are effecting its software state. Is there a way to snoop on the complete USB traffic? Funnily, if I send the same command as above, but to the host controller to which the hub is connected, the hub powers down all ports for couple of seconds, before the driver detects too many -71 errors and the reset logic re-powers the hub. I am still completely at a loss why my commands for turning-off the power of the hub-ports are not working. I have also tried to first put the port into suspend, but nothing changed. I would be thankfull for any hints how to proceed with the debugging. Best regards, Vlado Handziski ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
