On Wed, Feb 25, 2009 at 10:36:19AM -0500, Alan Stern wrote: > On Tue, 24 Feb 2009, Sarah Sharp wrote: > > > A couple months ago, I started on a tool to automatically test and enable > > automatic power management for USB devices. The USB Power Management tool (USB > > PM tool) is now mostly complete, and is available for download: > > > > git clone git://git.moblin.org/usb-pm-tool.git > > > > I would love for people to start testing USB devices with this tool. I haven't > > yet found any devices that can't handle selective suspend, so I really need > > testers with broken USB devices. > > Does your tool also test remote wakeup? In many cases selective > suspend is useless without it. The tool prompts the person to actively use the USB device after it successfully autosuspended. It does mention that some devices have remote wakeup and they could activate it by clicking a button on their mouse, etc. Remote wakeup is enabled by the kernel by default, correct? I haven't thought too much about the remote wakeup side. Are there pitfalls for devices that use remote wakeup that we've seen? I want to be sure that when we get a report of a good device from a user that the device won't break when woken up in a different fashion (and thus shouldn't be on the whitelist). I'm aware that Oliver found some USB mice that would wakeup only when a button was clicked but not when they were moved. I'm not sure whether such a mouse should be added to the whitelist; on one hand auto-suspend does work in a limited sense, but the user might notice a new "failure" and assume they need to change their mice batteries. If this semi-broken device shouldn't be added to the whitelist I could add special prompts for HID devices. Are there any other examples where remote wakeup might be an issue? > At the moment there can't be very many devices to test. Only a > handful of USB drivers support autosuspend. Yes, it's true that not many drivers implement autosuspend. However, I think the USB HID auto-suspend support will be merged soon. Jiri pulled Oliver's final auto-suspend patch into the HID tree on Jan. 16th to pull into -next; would that mean it gets into 2.6.30? (I'm still slightly confused about what the role of the -next tree.) I do want users to be able to enable auto-suspend for all the devices that support it. I had hoped the tool would have some of the same effect powertop has; if a developer finds that the driver for their device doesn't support auto-suspend, they may might be motivated to add auto-suspend support to the driver themselves, or try to get the driver maintainer to fix it. Making USB power management visible to the average user was the goal of this tool. Sarah -- 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
