On 14 November 2013 18:57, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Thu, 14 Nov 2013, Ulf Hansson wrote: > >> > Bear in mind that drivers _cannot_ rely on runtime PM to inactivate a >> > device during system suspend. The user can always prevent a device >> > from going into runtime suspend by writing "on" to the >> > /sys/.../power/control file. >> >> Good that you brought this up. From my point of view I think the sysfs >> for runtime PM could be debated whether it should exist at all, at >> least in it's current form. > > What other form would you suggest? I think it is kind of strange to give provision to userspace to control a "request based" power management feature in the kernel. Me personally can't think of any good use case, but I comes from the embedded/ARM world so I might not have the full picture. What would make sense to me, is to move the runtime PM sysfs to debugfs, because it is a good feature to make use of during development and debugging. > >> Anyway, if userspace decides to prevent runtime_suspend, I guess it >> will have take the consequences for it as well. :-) > > Right now, those consequences don't include also preventing the device > from going to low power during system system. What would you do if you > had a buggy device, where you knew it couldn't handle runtime suspend? > If you still wanted to put the whole system to sleep, you'd be stuck. Hmm, this seems like a use case for runtime PM sysfs then. :-) It sounds like vague arguments. If the driver has bugs we need to fix them, right? Should we really let userspace workaround bugs in the kernel? > >> So as a way forward, I am thinking of a similar approach as you >> suggested with the "generic" suspend_late. But instead add a new >> runtime PM API, which intent is to let drivers to specify for PM core, >> if it should care to prevent the runtime suspend from happen during >> system system - or not. Could that work? > > I don't see what good it would do. Instead of adding a new flag, why > not just let drivers point their .suspend_late methods to the new > generic function? That would accomplish almost the same thing without > changing the API. Two minor functions will be added to the API, no big deal I think. More importantly these will actually make life easier for some drivers since they don't need to set up any additional PM callbacks. Using the generic suspend_late approach would for sure work, but it will spread to buses and power domains as well, which is not the case when adding when adding a new API. > > (Actually, it would be superior. The generic suspend_late approach > will work even if the user writes "on" to /sys/.../power/control, > whereas your approach won't work.) We have different view here. :-) Whether I like it or not, the sysfs interface exist and then I think the kernel must act accordingly. We shouldn’t override it. I mean if userspace has decided to keep a device active, there is probably a reason. Thanks a lot Alan for being patient with me and continuing the discussion! Kind regards Ulf Hansson > > Alan Stern > -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
