From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Trimarchi Subject: Re: [RFC Add no_suspend attribute V2] Let the driver know if it's in use Date: Sat, 25 Apr 2009 19:11:28 +0200 Message-ID: <49F34440.5020304@gandalf.sssup.it> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: 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: Alan Stern Cc: Greg KH , linux-pm@lists.linux-foundation.org, len.brown@intel.com List-Id: linux-pm@vger.kernel.org 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. > Ok, so the sysfs don't contain all the dependenceis but dmp_list contains the exaclty suspend order of the device > 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. > Ok, I understand, so how to know the devices dependences? There is a way to express this relation? Because if it is not possible a single flag can be used > >> 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. > Yes this is possible, but you walk all list twice. Regards Michael