On 12/17/2014 10:47 PM, Bibek Basu wrote:
Hi Bill, Though I like your solution, I have a usecase where the driver probe sequence itself is not right. Both the driver are module_init but one depends on another during suspend sequence. In such a situation, my system hangs. What do you suggest to do in that 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 patch. But I don't think that's allowed solution?
To change the probe sequence, use defer probe is the right choice.
Example: Probe sequence: driver pcieport driver tegra-pcie Due to your patch, suspend_noirq for tegra_pcie will be called before
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 were suspended.
pcieport. While pcieport tries to read through pci_bus_read_config_dword with clocks and power off to the pcie controller and eventually leads to a crash. regards Bibek On Fri, Dec 12, 2014 at 9:04 PM, Greg KH <gre...@linuxfoundation.org <mailto:gre...@linuxfoundation.org>> wrote: 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 <mailto: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 <mailto: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/
-- 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/
