On Thu, 2 Sep 2010, Rafael J. Wysocki wrote: > > 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. There is a compromise that should work most of the time: Prevent autosuspend while the sd_open() routine runs (which is where the polling takes place). The problem is that programs can still send commands to a drive with no medium, if they open the device file with O_NONBLOCK. When/if this happens, the drive would be autosuspended immediately after each command, with no delay. > > 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. The driver can't use a different value without having it show up in sysfs. Unless we store _two_ suspend_delay values in dev_pm_info: the value to display in sysfs and the value to actually be used. This doesn't seem like a good idea. > > 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. If we rely on the regular sysfs filesystem permissions then the superuser would be able to make the attribute read/write again (chmod). Maybe that doesn't matter. Alternatively, there could be an extra flag bit in dev_pm_info to tell the suspend_delay_store routine that writes should always fail. Which do you prefer? There's still a small problem. When the user changes the parent's suspend_delay, the change won't affect the interfaces until the next time they try to autosuspend. 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
