Hi Rafael, sorry about the email mix up. On Thu, Oct 24, 2013 at 4:08 PM, Rafael J. Wysocki <r...@rjwysocki.net> wrote: >> > + >> > +What: /sys/devices/.../power/pm_qos_no_notify_flags >> > +Date: October 2013 >> > +Contact: Dan Williams <dan.j.willi...@intel.com> >> > +Description: >> > + The /sys/devices/.../power/pm_qos_no_notify_flags >> > attribute is >> > + used for determining whether the kernel is permitted to >> > forward >> > + changes to the the PM QoS flags (no_power_off, >> > remote_wakeup) to >> > + other devices it deems to be related in the system. When >> > this >> > + flag is set userspace is indicating that it wants exclusive >> > + control > > This is aganist the way the PM QoS flags were designed. There is no exclusive > control over them and user space cannot expect specific behavior when one of > them is unset in sysfs. Specifically, "no power off" unset doesn't mean > "power > off is required". It merely means "I have no objections against powering off > if that's what you decide to do".
'Exclusive control' was the wrong choice of terms. This admittedly ugly pm_qos_no_notify_flags flag would disable propagating the pm_qos_no_power_off setting to another device. The problem I am trying to solve is that deviceA can only safely be powered off depending on the state of deviceB. The kernel knows this relationship and in most cases when userspace says "I don't have any objections to powering off deviceA it almost certainly means I have no objections to you coordinating poweroff of deviceA + deviceB". I could skip this flag and keep this knowledge internal. I.e. userspace would just need to know that clearing pm_qos_no_power_off on deviceA will not enable power off until the same setting is performed on deviceB. I do place a link from deviceA to deviceB in sysfs. Although ordering becomes trickier without notification... Alternatively I could just power manage deviceB behind userspace's back when taking action on deviceA, but I think that is even more of a hack and takes away configuration ability from userspace. -- Dan -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
