On 2013年10月11日 19:19, Rafael J. Wysocki wrote:
On Friday, October 11, 2013 04:16:25 PM tianyu.lan@xxxxxxxxx wrote:
From: Lan Tianyu <tianyu.lan@xxxxxxxxx>
Currently, when one power resource is turned on, devices owning it
will be requested to resume regardless of their runtime pm status.
ACPI power resource maybe turn on in some devices' runtime pm
resume callback(E.G, usb port) while turning on the power resource
will trigger one new resume request of the device. It causes
infinite loop between resume and suspend. This has happened on
clearing usb port's PM Qos NO_POWER_OFF flag twice. This patch is
to add check of physical device's runtime pm status and request resume
if the device is suspended.
Signed-off-by: Lan Tianyu <tianyu.lan@xxxxxxxxx>
---
drivers/acpi/power.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/power.c b/drivers/acpi/power.c
index 0dbe5cd..228c138 100644
--- a/drivers/acpi/power.c
+++ b/drivers/acpi/power.c
@@ -250,8 +250,10 @@ static void acpi_power_resume_dependent(struct work_struct *work)
mutex_lock(&adev->physical_node_lock);
- list_for_each_entry(pn, &adev->physical_node_list, node)
- pm_request_resume(pn->dev);
+ list_for_each_entry(pn, &adev->physical_node_list, node) {
+ if (pm_runtime_suspended(pn->dev))
+ pm_request_resume(pn->dev);
+ }
This is racy, because the status may change right after you check it and before
you call pm_request_resume().
Yes, the runtime status may be changed just after the check.
Besides, pm_request_resume() checks the status of the device and won't
try to resume it if it is not suspended.
For this issue, usb port is in the RPM_SUSPENDING state when
pm_request_resume() is called. The deferred_resume will be set to true
during this procedure and trigger resume after finishing suspend. USB
port runtime resume callback will turn on its power resource again and
the work of acpi_power_resume_dependent() is scheduled. Because the usb
port's usage count remains zero, it's to be suspended soon. When
pm_request_resume() of acpi_power_resume_dependent() is called, the usb
port is always in the PRM_SUSPENDING. Fall in the loop of suspend and
resume.
How about running acpi_power_dependent when turning on power resource
rather than scheduling a work to run it? After this,
pm_request_resume() can check device's right status just after turning
on power resource. Furthermore, pm_request_resume() is async resume and
this change will not consume much time.
list_for_each_entry(pn, &adev->power_dependent, node)
pm_request_resume(pn->dev);
Thanks!
--
Best regards
Tianyu Lan
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
