On Fri, Jun 19, 2020 at 1:07 PM Saravana Kannan <sarava...@google.com> wrote: > > I think instead of deferred_probe_work_func() moving the device to the > end of the dpm_list, I think the device probing successfully is what > should move it to the end of the dpm_list. That way, the dpm_list is > actually ordered by when the devices become functional and not the > random order in DT or random probe order which can get pretty > convoluted with multiple deferred probes. This feels right and will > make suspend/resume more robust against DT ordering -- but I'm not > sure what other wide ranging impact this has for other platforms.
Geert, If you want to play around with a potential fix to test my hypothesis, I think it's just adding this one line to driver_bound(): ============ klist_add_tail(&dev->p->knode_driver, &dev->driver->p->klist_devices); device_links_driver_bound(dev); +device_pm_move_to_tail(dev); device_pm_check_callbacks(dev); ============ -Saravana
