On Mon, Apr 08, 2013 at 06:29:36AM -0700, Greg KH wrote: > On Mon, Apr 08, 2013 at 08:58:09PM +0800, Lan Tianyu wrote: > > On 2013/3/30 4:24, Alan Stern wrote: > > >On Fri, 29 Mar 2013, Sarah Sharp wrote: > > > > > >>>Also, bear in mind that the proposed patch does not give userspace a > > >>>way to power off ports via usbfs. What the new code does is a > > >>>power-off reset -- it turns off power to the port, waits a short time, > > >>>and then turns power back on. > > >> > > >>I think we need two separate IOCTLs: turn off the port power and turn it > > >>on. Then we get the manual port power off for our QA testing, distros > > >>can make interesting policies about manually powering off ports, and > > >>userspace can choose how long they want the port to be off. After all, > > >>different devices may need a longer powered-off period than others. > > > > > >Or one port-power IOCTL that takes the setting as an argument. Yes, > > >this would be more flexible than a power-off reset. > > Hi Alan & Sarah: > > I just recall why I put power off and power on in one ioctl. > > At first, I also tried to make power on and power off into two ioctls. > > But I found after powering off a device, the usbfs device node will > > be removed and so can't power on the port via the same usbfs node. > > > > For this point, we should add usbfs node for usb port? > > No. I agree that we shouldn't add more usbfs files without thinking very carefully about it, since lots of tools like libusb use them. However, we do need a way to manually power off a port, wait a variable length of time (or perhaps for a distro-specific event like screen unblank), and turn the port on. So how do we turn the port power back on with the options we have? Would userspace have to turn the port power off via usbfs, and then manually back on by setting the port's sysfs power/control to 'on'? Sarah Sharp -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
