From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Rafael J. Wysocki" Subject: Re: [RFC Add no_suspend attribute V2] Let the driver know if it's in use Date: Thu, 23 Jul 2009 16:32:39 +0200 Message-ID: <200907231632.40243.rjw@sisk.pl> References: <4A686EFC.6040904@gandalf.sssup.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4A686EFC.6040904@gandalf.sssup.it> Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-pm-bounces@lists.linux-foundation.org Errors-To: linux-pm-bounces@lists.linux-foundation.org To: Michael Trimarchi Cc: Greg KH , linux-pm@lists.linux-foundation.org, len.brown@intel.com List-Id: linux-pm@vger.kernel.org On Thursday 23 July 2009, Michael Trimarchi wrote: > Hi all, > > Alan Stern wrote: > > On Sat, 25 Apr 2009, Michael Trimarchi wrote: > > > > > >> Anyway, I revert this beacuse is wrong but is it correct to use here the > >> list_add instead the list_add_tail, it put the child node > >> after the parent stricly and don't create hole in subtree visit. Now I > >> see only a dump > >> reason for debugging and a simple exit in flag update. > >> The important thing is that the children follow the parent, > >> and in this way is like visiting the tree. > >> > > > > That's not necessarily true. There may be dependencies between devices > > that aren't expressed by the parent-child relationship. > > > > For example, device B might require device A even though A isn't a > > parent (or ancestor) of B. The way dpm_list works now this is okay, > > because devices are added in order of discovery. That is, if B depends > > on A then A must have been discovered before B, so A will come first on > > the list. > > > > If you change things by adding children directly after their parent > > then you will mess this up. For example, if B's parent was discovered > > before A, then adding B directly after its parent would mean putting B > > before A on the list. Then you'd run into trouble during a system > > suspend, because A would be suspended before B and that would prevent B > > from working properly. > > > > > >> Nothing change for me because > >> is difficult > >> to isolate only a subtree, if you have a list, but I'm sure that if I > >> find a subtree with > >> the same parent, my subtree is finish, and if someone add a new device, > >> the system put > >> in the correct position. > >> > > > > It is _not_ difficult to isolate a subtree using a list. For example: > > > > mutex_lock(&dpm_mutex); > > topdev->in_subtree = 1; > > list_for_each_entry(dpm_list, dev, power.entry) { > > if (dev->parent && dev->parent->in_subtree) > > dev->in_subtree = 1; > > } > > list_for_each_entry(dpm_list, dev, power.entry) { > > if (dev->in_subtree) { > > dev->in_subtree = 0; > > dev->dont_suspend = 1; > > } > > } > > mutex_unlock(&dpm_mutex); > > > > This will set the dont_suspend flag for all devices in the subtree > > starting at topdev. > > > > Alan Stern > > > I follow the discussion around the new runtime support and I would like > to know if I can > add to the new interface the no_suspend flag or maybe now there is a > better solution. Hmm. Do I remember correctly that the no_suspend flag is for preventing the system-wide suspend in case some devices are in use? Rafael