sorry for the delay in responding.
On Thu, Dec 18, 2014 at 1:35 PM, Bill Huang <bilhuang@xxxxxxxxxx
On 12/17/2014 10:47 PM, Bibek Basu wrote:
Though I like your solution, I have a usecase where the driver probe
sequence itself is not right. Both the driver are module_init
depends on another during suspend sequence.
In such a situation, my system hangs. What do you suggest to do
case? Should I get my driver registration sequence right and how?
Moving tegra-pcie driver above in the probe sequence by making the
driver subsystem_initcall solved the issue I am facing with this
But I don't think that's allowed solution?
To change the probe sequence, use defer probe is the right choice.
What if there is no direct dependency to defer probe ?
True they are all related and if both pcieport and tegra-pcie have suspend_noirq callback defined (I guess so since you said you have problem here:), then my fix will change the suspend sequence of the two.
Due to your patch, suspend_noirq for tegra_pcie will be called
Are you sure? My change will only affect pm devices in dpm_list,
suspend_noirq should still be called after all devices in dpm_list
Yes, all lists are affected if you update dpm_list. Because using
dpm_list, dm_prepared_list is prepared . During suspend, using
dpm_prepared_list, dpm_suspended_list is prepared. And using
dpc_suspended_list, in dpm_suspend_late, dpm_late_early_list is prepared
and which is used to call suspend_noirq callbacks and also prepare
dpm_noirq_list. So all are related!!!
pcieport. While pcieport tries to read through
with clocks and power off to the pcie controller and eventually
On Fri, Dec 12, 2014 at 9:04 PM, Greg KH
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
> 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
> 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
> we fix it.
> - Do we have better fix?
> - This proposed fix or any other fix might introduces
> 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
struct device_driver *drv)
> goto probe_failed;
> + device_pm_lock();
> + device_pm_move_last(dev);
> + device_pm_unlock();
> ret = 1;
> pr_debug("bus: '%s': %s: bound device %s to driver
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.
To unsubscribe from this list: send the line "unsubscribe
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at http://www.tux.org/lkml/