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. 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
