On Thu, 25 Dec 2014, Peter Chen wrote: > Thanks for explaining it, but I am still not understand why we need unbind > the interface when we go to turn the port power off or reset the port if > the port is owned by kernel. I often need to do continual plug in/out > usb device test, in order to emulate it, I just toggle the power (vbus > on <--> vbus off), I did not find anything wrong. Power management in the kernel uses a simple rule: A device has to be at full power while it is in use. A hub port is considered to be in use almost always, because a device could be plugged into it at any time. There are a few exceptions to this. For example, if a USB-2 device is plugged in then we know that nothing can be connected to its peer USB-3 port (since they use the same physical connector) and so the USB-3 port can be powered down. Or if a device is in runtime suspend and it isn't enabled for wakeup then its port can be powered off. Or if the firmware tells us that the port is not accessible to the user and nothing is plugged into it, then we know that it will never be used. Nevertheless, in general ports are always considered to be in use and therefore are not powered down. If you want to change this, you have to add a mechanism (probably a sysfs file) to allow the user to tell the kernel that a particular port will not be used. Then the kernel will be free to power-off that port. On Thu, 25 Dec 2014, Deepak Das wrote: > Above patch does make sense but the original question was the reason > behind the turning port power back on. There was a commit ca9c9d0 > which added the port power control sysfs entry, we ported that commit > back to our kernel for testing but power was turned back ON due to > above reason. Well, of course. That commit was not complete in itself; it was just part of a series. And there have been many more commits (more than 20) affecting that part of the hub driver since then. You can't expect to back-port just one commit and have it do exactly what you want. > I don't see any strong reason to keep this feature of hub reset. We keep it because the hub driver wants ports to remain powered on as long as they are in use. > In addition, Do you see any consequences if we allow userspace to control > port power if hub supports ? Yes. The kernel does not allow userspace to control power to _any_ device. The kernel controls power, and it allows userspace to set the power policy (within limits). The current port-power policy options are very limited. There is no way for the user to tell the kernel that a port isn't going to be used. As I said to Peter above, you could add such a policy mechanism. Alan Stern -- 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
