Am Mittwoch, 1. September 2010, 18:16:34 schrieb Alan Stern: > On Wed, 1 Sep 2010, Oliver Neukum wrote: > > > Which in means > > that medium change events will be lost. I think for devices with this quirk > > we can autosuspend only if there's no medium present. Furthermore > > you'll probably need to introduce a new flag to signal this requirement > > to usbcore. > > How? usbcore knows nothing about media. The best solution is for > usb-storage to disallow autosuspend if the quirk is set. That is the easiest fix. It is somewhat wasteful though. > > > Suggestions for a sysfs interface? Should the sd driver add its own > > > "suspend_delay_no_medium" attribute? > > > > Hm. I see no connection to sd. In fact I see no connection to block > > devices. Tapes have this issue, too. > > It could be added for all SCSI devices. But wouldn't it be easier > simply to use a fixed delay when there's no medium? We could pick a > value like 100 ms or make it a module parameter. > > There's a problem about communicating the delay value to the PM layer. > The code I'm adding to the PM core assumes a device has only a single > delay: the current suspend_delay value. That current value will be the > one to show up in the "suspend_delay_ms" sysfs attribute. So for > example, you wouldn't be able to set the medium-present delay value at > a time when no media was loaded. Not too bad. If you really want to elaborate on this you could you add an attribute allowing the user to specify whether a driver should be allowed to override the delay the user has set. But I think, simply allow the drivers to override. > Also, there are potentially problems with drives that take a while to > warm up and claim they have no media in the mean time. That argues for not using a fixed value. But I suspect that drives for removable rotational media are a dieing species anyway. We could simply block autosuspend for them. 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
