On Thu, 26 Aug 2010, Oliver Neukum wrote: > Am Donnerstag, 26. August 2010, 16:58:34 schrieb Alan Stern: > > On Thu, 26 Aug 2010, Mohammed Amine IL Idrissi wrote: > > > > > From: Mohamed Amine IL Idrissi > > > Sometimes, usb devices won't be powered off at shutdown. This change > > > will make it power off. > > > > How do you know that the devices get powered off when the patch is > > applied? The fact that an LED goes out does not mean the device is > > powered off. For a rigorous test you should measure the voltage on the > > USB bus. > > > > My guess is that the devices remain powered on either way. The > > difference is that with the patch the device decides to suspend, so it > > turns off the LED and uses less power -- but it still uses some power. > > Why would that be? If you stop SOF devices should suspend either way. This is very puzzling. The original code puts the controller into the RESET state, during which it asserts a reset signal on the USB bus for all ports. Probably the device sees the reset signal and leaves the LED in whatever state it was -- on or off -- before the reset began. With the patch the controller remains in the OPERATIONAL state, which means it continues to generate SOF packets. So why would the device go into suspend? Maybe this really is some weird vendor-specific thing. On Thu, 26 Aug 2010, David Brownell wrote: > NAK. Not all hubs support port power-off, so > the goal of the patch can't ever be achieved. > > Moreover, this patch is OHCI-specific, and it does > not touch the root hub port power control bits, so > it clearly doesn't do what it claims to do. > > My quick guess is that it's suspending everything, > which might be a reasonable goal ... but if so, it > should either be done in usbcore (in the generic > hub code) or as part of changing all HCDs and the > rules they must follow. At the very least, the patch description is wrong. A better description for the patch would go something like this: On some systems (those with nVidia controllers and possibly others), USB device LEDs remain on following system shutdown. This is not what users expect and it exerts a noticeable drain on laptop batteries. This patch causes ohci-hcd not to put OHCI controllers into the RESET state during shutdown; for unknown reasons that appears to solve the problem. I'm not sure whether leaving the controller in a non-RESET state is okay. Won't it continue to try doing DMA memory accesses, to update the HccaFrameNumber value for instance? That might or might not end up being dangerous, but it doesn't seem like a good idea. 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
