Re: Query about secondary_bu_reset implementation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 11/19/2021 12:16 AM, Sinan Kaya wrote:
External email: Use caution opening links or attachments


On 11/18/2021 10:03 AM, Vidya Sagar wrote:
Regarding the below commit that added pci_dev_wait() API to wait for the
device (supposed to be a downstream device.. i.e. and endpoint) get
ready, I'm wondering, given the 'dev' pointer here points to an upstream
device (i.e. a root port) because the same is passed to
pcibios_reset_secondary_bus() API, how is passing a root port's dev
pointer to pci_dev_wait() is going to serve the purpose?

My understanding is that it would always get the response immediately as
the reset is applied to the endpoint here (through secondary bus reset)
and not to the root port, right? or am I missing something here?

Root port is not reset.
This is a link reset and recovery from link reset can take time per CRS
response.

We have seen some GPUs going all the way up to 60 seconds while
returning CRS response and waiting to reinitialize.
Yes, but the pci_dev_wait() is called here with the pci_dev * of the RP and not the endpoint, right? So, how is CRSes from the endpoint are handled in this case?



[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux