On Tue, Apr 01, 2025 at 01:28:51PM +0200, Niklas Cassel wrote: > Hello Mani, > > On Wed, Mar 19, 2025 at 04:02:17PM +0530, Manivannan Sadhasivam wrote: > > > > > > While I don't intend to justify dropping pci_epc_deinit_notify() in the > > > cleanup path, I wanted to check if this should be added to > > > dw_pcie_ep_deinit() as well. Or is it the case that dw_pcie_ep_deinit() > > > is different from cdns_pcie_ep_disable()? Please let me know. > > > > > > > Reason why it was not added to dw_pcie_ep_deinit() because, deinit_notify() is > > supposed to be called while performing the resource cleanup with active refclk. > > > > Some plaforms (Tegra, Qcom) depend on refclk from host. So if deinit_notify() is > > called when there is no refclk, it will crash the endpoint SoC. But since > > cadence endpoint platforms seem to generate their own refclk, you can call > > deinit_notify() during deinit phase. > > > > That said, I noticed some issues in the DWC cleanup path while checking the code > > now. Will submit fixes for them. > > Could you please elaborate quickly what issues you found? > (1) dw_pcie_ep_deinit() -> dw_pcie_ep_cleanup() -> dw_pcie_edma_remove() But dw_pcie_ep_init() is not calling dw_pcie_edma_detect(). It is called by dw_pcie_ep_init_registers(). So dw_pcie_ep_init() and dw_pcie_ep_deinit() not symmetrical. (2) We are not calling pci_epc_deinit_notify() in non-PREST# supported controller drivers. I think this could be fixed by moving it inside dw_pcie_ep_cleanup(). - Mani -- மணிவண்ணன் சதாசிவம்
