On Thursday, September 02, 2010, Alan Stern wrote: > On Thu, 2 Sep 2010, Oliver Neukum wrote: > > > 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. > > I guess so, but making it more efficient would be painful. If the > quirk was set, usb-storage would have to tell the SCSI layer never to > autosuspend when media was present. Since relatively few mass-storage > devices have this quirk, I think we can be wasteful. > > > > 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. > > Hmm. There isn't any way for the driver to override the suspend_delay > value with something shorter. All it can do is stop using > suspend_delay entirely (which is effectively the same as assuming the > value is 0, even if the real value is negative). I'm not so sure that > would work out well in the presence of polling. > > Yes, the driver could _replace_ suspend_delay with something shorter. > But then the new shorter value would appear in the sysfs attribute -- > and changes to the attribute would affect the new value rather than the > original value. This seems even less attractive. IMO it is unacceptable. The values set by user space cannot be changed by the kernel at will or the entire interface won't make sense. However, there is a question whether suspend_delay should be treated by the kernel as a mandatory delay or the representation of user space's preference. In the latter case, the driver would be allowed to use a different value. > > > 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. > > Or rely on userspace not to enable autosuspend in the first place. > That's probably the best approach, since the kernel can't tell whether > a drive is rotational. I agree. > One more thing: With these changes to the PM core, each USB interface > will now have its own suspend_delay value instead of using its parent > device's value. What should this value be set to? Ideally it would be > the same as the parent device's suspend_delay -- but changes to the > parent's value made by the user would not affect the interface's value. > > We could try initializing the interface suspend_delay values to 1 > second. But of course the user could change it at any time; would that > cause problems? I guess the suspend_delay attribute for USB interfaces may be read-only, in which case they will be able to use their parent's values without allowing user space to modify them. Thanks, Rafael -- 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
