On Fri, Dec 12, 2014 at 03:50:15AM -0800, Bill Huang wrote:
> 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 <bilhu...@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",
Adding Grant, as he did the deferred probe stuff...
And it's the middle of the merge window, I'll not have time to look at
this for a few weeks at the earliest, sorry.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
