On 10/15/2019 1:51 AM, Sinan Kaya wrote:
On 10/14/2019 1:20 AM, Thierry Reding wrote:
I think this makes sense, so:
Reviewed-by: Thierry Reding <treding@xxxxxxxxxx>
However, it looks like Sinan has researched this extensively in the past
and gave a presentation on this at Plumbers in 2017:
https://blog.linuxplumbersconf.org/2017/ocw/system/presentations/4732/original/crs.pdf
Adding Sinan to see if he has any concerns about this, since resume time
is explicitly mentioned in the above slides.
Thanks for including me. Let me catch up here.
pci_dev_wait() is supposed to handle this case via pci_pm_reset().
/**
* pci_pm_reset - Put device into PCI_D3 and back into PCI_D0.
* @dev: Device to reset.
* @probe: If set, only check if the device can be reset this way.
*/
Do you know if your execution path hits this function? We might have
missed a use case.
Nope. It doesn't.
Following is the stack dump showing how pci_update_current_state() is called in resume() path.
And pci_device_is_present() is called from inside pci_update_current_state() API.
My understanding is that pci_device_is_present() is the API we hit first in the resume() path
for any PCIe device.
[ 36.380726] Call trace:
[ 36.383270] dump_backtrace+0x0/0x158
[ 36.386802] show_stack+0x14/0x20
[ 36.389749] dump_stack+0xb0/0xf8
[ 36.393451] pci_update_current_state+0x58/0xe0
[ 36.398178] pci_power_up+0x60/0x70
[ 36.401672] pci_pm_resume_noirq+0x6c/0x130
[ 36.405669] dpm_run_callback.isra.16+0x20/0x70
[ 36.410248] device_resume_noirq+0x120/0x238
[ 36.414364] async_resume_noirq+0x24/0x58
[ 36.418364] async_run_entry_fn+0x40/0x148
[ 36.422418] process_one_work+0x1e8/0x360
[ 36.426525] worker_thread+0x40/0x488
[ 36.430201] kthread+0x118/0x120
[ 36.433843] ret_from_fork+0x10/0x1c
Also, I don't see pci_pm_reset() getting called in resume() path at all.
Thanks,
Vidya Sagar
