On Tue, 9 Feb 2010, Sarah Sharp wrote: > Hi Alan, > > Back in October, there was a discussion about USB storage autosuspend. > The general consensus seemed to be that we should convert the USB and > SCSI subsystems over to the runtime PM framework and then implement USB > storage autosuspend, instead of doing an autosuspend hack with layering > violations. > > I'm being nudged to do such a hack, because a lot of netbooks have SD > card readers that are empty most of the time. I would rather not do > such a hack if a better solution exists. What are your plans with USB > storage autosuspend? There's more than one problem involved here, and the solutions are not clear. The best approach is, as you say, to implement the runtime PM framework for SCSI devices and then to implement usb-storage autosuspend based on that. There would still be problems, but they would tend to be at the SCSI level rather than the USB level, so we wouldn't have to worry about them so much. :-) In particular, when should a SCSI device be autosuspended? Only when the device file is closed? Or when the device hasn't been used for I/O in a while? What about something like a SCSI CD drive, which can play music autonomously without constantly sending commands back and forth? Alternatively, we can implement usb-storage autosuspend independently of the SCSI layer. In essence, this means suspending the USB transport while leaving the device on the end of that transport at full power. This is subject to difficulties if the device is bus-powered or if it takes special actions on its own (like spinning down) when the bus interface is suspended. Unfortunately the kernel has no way to know whether or not a device has these issues. We could leave the decision up to the user by providing a sysfs attribute to enable unilateral usb-storage autosuspend. Finally, most desktop/laptop systems have something like HAL that constantly probes the status of USB mass-storage devices to check for the presence of removable media. Typically these probes occur at a rate around once per second. This will defeat our normal autosuspend implementation, which uses a two-second inactivity delay timer. Of course the user can tell HAL to stop this probing, but then cards inserted into readers won't automatically be detected and mounted (and card removal won't automatically be detected either). For the moment, it's possible to autosuspend a card reader by setting its power/level attribute to "auto" and unbinding it from usb-storage. Obviously this isn't suitable as a long-term solution but maybe it will help satisfy the people nudging you. 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
