Re: [RFC Add no_suspend attribute V2] Let the driver know if it's in use

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
>
>
>   

_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

[Index of Archives]     [Linux ACPI]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [CPU Freq]     [Kernel Newbies]     [Fedora Kernel]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux