Am Mittwoch, 10. Februar 2010 16:29:16 schrieb Alan Stern: > 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? For starters we should be as conservative as possible. That means any open() should mean the device is busy for purposes of autosuspend. That means for sd and sr that we don't autosuspend mounted devices, but for the basic case of readers without a medium that is good enough. > 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. There is the possibility of data loss. Regards Oliver -- 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
