On Thu, Mar 28, 2013 at 05:00:23PM -0400, Alan Stern wrote: > On Thu, 28 Mar 2013, Sarah Sharp wrote: > > > On Thu, Mar 28, 2013 at 01:11:02AM +0800, Lan Tianyu wrote: > > > Some devices' firmware will be broken at some points. Power down > > > and power on device can help device to rework in this case. > > > > > > This patch is to add ioctl cmd USBDEVFS_POWER_RESET for usbfs node > > > to repower usb device. First, call hub_port_logical_disconnect() to > > > disconnect device. Second, Power down and up usb port. > > > > I don't think this is the right approach. We want to be able to power > > off a port, even if no devices are attached. One of the use case > > scenarios we discussed was allowing distros to turn off empty USB ports > > according to some policy (e.g. screen blank, lost bluetooth connection > > to their phone that indicates the user walked away from the computer, > > server admin wants to save power, etc). > > > > With the current patches in 3.9, I don't see a way we can do that. The > > ports have power/control, which can only be set to 'on' or 'auto'. You > > should add an 'off' option to that file. > > Won't empty ports naturally be powered off by runtime PM, so long as > there isn't a PM_QOS constraint to prevent it? The user (or system > software) may need to write "auto" to the port's power/control file, > which may require us to put the ports on the usb_bus_type or to make > them class devices. But however we do it, this should work > automatically. Now I'm a bit confused and I'll have to look at the code again. I can't remember if Tianyu made the kernel add a PM_QOS constraint to set the no power off flag for hot pluggable ports, or if we expect userspace to use the connect type sysfs file to figure out it shouldn't write auto to the file. If the kernel isn't adding that constraint, then Tianyu *really* needs to document that. 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
