On Thu, Oct 24, 2013 at 05:42:13PM -0700, Dan Williams wrote: > Hi Rafael, sorry about the email mix up. > > On Thu, Oct 24, 2013 at 4:08 PM, Rafael J. Wysocki <rjw@xxxxxxxxxxxxx> wrote: > >> > + > >> > +What: /sys/devices/.../power/pm_qos_no_notify_flags > >> > +Date: October 2013 > >> > +Contact: Dan Williams <dan.j.williams@xxxxxxxxx> > >> > +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". So your plan was to automatically change the pm_qos_no_port_poweroff flag for deviceB whenever userspace set deviceA pm_qos_no_port_poweroff? And userspace could tell the kernel not to do that with the pm_qos_no_notify_flags file? > 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. That seems to be the easier solution. I suspect that what userspace will do is clear pm_qos_no_power_off for all ports marked as hardwired, and then never touch pm_qos_no_power_off again. It seems like unnecessary optimization to try to pair the two device states. > Although ordering becomes trickier without notification... What situations specifically are trickier? > 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. Yeah, I don't think that's a good idea. Sarah Sharp -- 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
