On Monday, August 30, 2010, Alan Stern wrote: > On Mon, 30 Aug 2010, Rafael J. Wysocki wrote: > > > I guess I'd need to know more about how the USB autosuspend mechanism works > > to understand it entirely. > > > > I really don't think it's a good idea to even change the way pm_schedule_suspend() > > works, because it's already been used by drivers that don't support device > > autosuspend. So, if autosuspend support is needed at the PM core level, I'd > > prefer it to be added in the form of a separate helper function (that may share > > code with the existing ones). > > > > Also, IMO, suspend_delay_ms should be accessible to user space only if the > > device's driver and/or subsystem support autosuspend, so that the meaning of > > the value written to this file by user space is always well defined. > > There could be a new use_suspend_delay flag bit. Subsystems or drivers > could set it, and if it wasn't set then pm_schedule_suspend and the > timer handler would behave the same as they do now. Also, attempts to > read or write the suspend_delay_ms attribute would fail with -EIO. > > Or if you prefer, I could add another routine that would be like > pm_schedule_suspend but only taking the suspend_delay into account. > However it doesn't seem to be necessary given the new flag. Yes, I think the new flag would be sufficient. 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
