All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Trimarchi <trimarchi@gandalf.sssup.it>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Greg KH <greg@kroah.com>,
	linux-pm@lists.linux-foundation.org, len.brown@intel.com
Subject: Re: [RFC Add no_suspend attribute V2] Let the driver know if it's in use
Date: Thu, 23 Jul 2009 16:09:00 +0200	[thread overview]
Message-ID: <4A686EFC.6040904@gandalf.sssup.it> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0904251243360.18955-100000@netrider.rowland.org>

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.

Michael
>
>
>   

  parent reply	other threads:[~2009-07-23 14:09 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-24 17:24 [RFC Add no_suspend attribute V2] Let the driver know if it's in use Michael Trimarchi
2009-04-24 17:31 ` Randy Dunlap
2009-04-24 17:36   ` Michael Trimarchi
2009-04-24 17:55 ` Michael Trimarchi
2009-04-24 22:55   ` Greg KH
2009-04-25  8:21     ` Michael Trimarchi
2009-04-25  9:07     ` Michael Trimarchi
2009-04-25 10:56       ` Rafael J. Wysocki
2009-04-25 12:03         ` Michael Trimarchi
2009-04-25 16:57           ` Alan Stern
2009-04-25 17:11             ` Michael Trimarchi
2009-04-25 18:33               ` Alan Stern
2009-04-30 23:42                 ` Michael Trimarchi
2009-05-01  2:27                   ` Alan Stern
2009-07-23 14:09             ` Michael Trimarchi [this message]
2009-07-23 14:32               ` Rafael J. Wysocki
2009-07-23 14:56                 ` Alan Stern
2009-07-23 16:00                   ` Michael Trimarchi
2009-07-24 15:36                     ` Rafael J. Wysocki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4A686EFC.6040904@gandalf.sssup.it \
    --to=trimarchi@gandalf.sssup.it \
    --cc=greg@kroah.com \
    --cc=len.brown@intel.com \
    --cc=linux-pm@lists.linux-foundation.org \
    --cc=stern@rowland.harvard.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.