On Thursday, September 02, 2010, Alan Stern wrote: > On Thu, 2 Sep 2010, Rafael J. Wysocki wrote: > ... > > > > 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. I wanted to say that, if the value in suspend_delay was regarded as the preferred one (not mandatory), the driver would be free to actually suspend the device without waiting that time or to wait longer, depending on circumstances. That doesn't imply having a separate delay field for the driver to use. > > > 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. I thought about this approach. > Which do you prefer? The extra flag bit. :-) > 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. The extra flag bit mentioned above may mean "use the parent's value" which seems to address this issue. 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
