Hi, On 4/10/20 5:46 PM, Rafael J. Wysocki wrote:
Hi Alan, Following our recent discussion regarding the DPM_FLAG_* family of flags [1], I have decided to follow some of your recommendations and make changes to the core code handling those flags. The purpose of this is basically to make the code more consistent internally, easier to follow and better documented. First of all, patch [1/7] changes the PM core to skip driver-level "late" and "noirq" suspend callbacks for devices with SMART_SUSPEND set if they are still runtime-suspended during the "late" system-wide suspend phase (without the patch it does that only if subsystem-level late/noirq/early suspend/resume callbacks are not present for the device, which is demonstrably inconsistent) and updates the resume part of the code accordingly (it doesn't need to check whether or not the subsystem-level callbacks are present any more). The next patch, [2/7], is purely cosmetic and its only purpose is to reduce the LOC number and move related pieces of code closer to each other. Patch [3/7] changes the PM core so that it doesn't skip any subsystem-level callbacks during system-wide resume (without the patch they may be skipped in the "early resume" and "resume" phases due to LEAVE_SUSPENDED being set which may be problematic) and to always run the driver's ->resume callback if the corresponding subsystem-level callback is not present (without the patch it may be skipped if LEAVE_SUSPENDED is set) to let it reverse the changes made by the driver's ->suspend callback (which always runs too) if need be. Patches [4-6/7] rename one function in the PM core and two driver PM flags to make their names better reflect their purpose. Finally, patch [7/7] updates the documentation of the driver PM flags to reflect the new code flows. This patch series have been available in the git branch at git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \ pm-sleep-core for easier web and git access.
The series looks sane to me at a first look. I've added it to my local tree for testing on all the pesky Bay and Cherry Trail devices I have and which always cause trouble in this area. Regards, Hans
