Re: pm_runtime_suspended() can be false if RPM_SUSPENDED

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

 



"Rafael J. Wysocki" <rjw@xxxxxxx> writes:

[...]

>> 
>> However, based on the pm_runtime_set_active() problem you mentioned
>> above, I'm not sure this will help either, since what the PM domain's
>> noirq callback will want to do will be based on the actual device
>> hardware state, not on the PM core's view of the device state.
>
> Yes.  For devices whose runtime PM is never enabled, this is quite clear
> (we must assume they are operational).  For devices whose runtime PM is
> temporarily disabled and the reenabled, it's not that clear, but at
> least for the system suspend case we may require drivers not to use
> pm_runtime_set_active/suspended() in their callbacks, so that we may
> assume that the status hasn't changed between .suspend() and .resume().
>
> So, I think your approach (to check power.runtime_status) is correct in this
> respect.

OK, I'll just directly check power.runtime_status in the noirq methods,
since at that point I always know that disable_depth > 0.

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