[RFC 1/1] driver core: re-order dpm_list after a succussful probe

[Bill Huang]

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

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/