lkml.org 
[lkml]   [2014]   [Dec]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
From
Subject[RFC 1/1] driver core: re-order dpm_list after a succussful probe
Date
The dpm_list was added in the call "device_add" and when we do defer
probe we'll explicitly move the probed device to be the last in the
dpm_list, we should do the same for the normal probe since there are
cases that we won't have chance to do defer probe to change the PM order
as the below example.

If we would like the device driver A to be suspended earlier than the
device driver B, we won't have chance to do defer probe to fix the
suspend dependency since at the time device driver A is probed, device B
was up and running.

Device A was added
Device B was added
Driver for device B was binded
Driver for device A was binded

Signed-off-by: Bill Huang <bilhuang@nvidia.com>
---

It seems to me this is a bug in the core driver, but I'm not sure how should
we fix it.

- Do we have better fix?
- This proposed fix or any other fix might introduces side effect that breaks
existing working suspend dependencies which happen to work based on the
existing wrong suspend order.

Any thoughts? Thanks.

drivers/base/dd.c | 4 ++++
1 file changed, 4 insertions(+)

diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index cdc779c..54886d2 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -308,6 +308,10 @@ static int really_probe(struct device *dev, struct device_driver *drv)
goto probe_failed;
}

+ device_pm_lock();
+ device_pm_move_last(dev);
+ device_pm_unlock();
+
driver_bound(dev);
ret = 1;
pr_debug("bus: '%s': %s: bound device %s to driver %s\n",
--
1.9.1


\
 
 \ /
  Last update: 2014-12-12 13:21    [W:0.042 / U:0.276 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site