From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id DF22DCD4F5E for ; Tue, 19 May 2026 17:20:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=LyDnZx1EgwKQxomL9p8sUoIyJVyjwOTBwOhojD+4j7g=; b=N1CL14eBnRZqvj bg93UNJl1Lul9i0616Llzezl6J5xGQosKJePCfVRo+qrkdhQzamCUtQ+la2rztsSXcKlrJ+lcsklG OwXzu6wWNonYIDbSgk8N9uWXfpV5iG/5/rIAnuV4RZFCzVGES2ne0x700fbn3zLQm6pj7iz33uqGd F9KJLDHsG5P7f2DnKJkGbRl4AfP1zjLRRGon4cEggP7ty7ZW15b9QKcu58v3IikVxnIel5x+NOdpS qcMeCsOkn2euN1OIeRD3XN7g3WxfEoMvN4bsNY7EwDoAMOEKn94e8eZAQk7ZiWvBrVQzKj63wYjgK GolgHuNXTeXSrQpoQH0w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wPO6t-00000002MQf-2qsw; Tue, 19 May 2026 17:20:03 +0000 Received: from sea.source.kernel.org ([2600:3c0a:e001:78e:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1wPO6q-00000002MP4-2I75; Tue, 19 May 2026 17:20:01 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id E531442DD5; Tue, 19 May 2026 17:19:58 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CE02BC2BCB3; Tue, 19 May 2026 17:19:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1779211198; bh=PcQgZeciD6zTFbc/Al2Qw1LpZV+52E8Gj2OSIzC9Qss=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=XbBBzI6BMmc2qi3CO/PJ03L/0BLjVUWyHeawfD9cL5/Zzfr6WScpP28XVy2zTPt2a ljZxJD6N9ASkopYjKp67ifLM3nvk+x3bNgJjQ3DEk+H1XdQoY5pVyxFITJh/YqBggM /7KGybNccUvfeB0gUVw/ZKhWVoQwjtBHNrtclXL7HSsCBMRekKdsE56dzcCpTohR21 p+DQfqk6jZLV2LDjGtesHbn1XRL0vzBGFqNoE6wXGIwVw8slCzZUQsO1BZgApb5mii Cb0kl7/79jR/btL5zrqnIi3y47jE3yZzzRC0fdAju6hYf6U5Zf98CCl3/IBjZZJ0ex NqYjdckOwMG0w== Date: Tue, 19 May 2026 19:19:51 +0200 From: Niklas Cassel To: Manivannan Sadhasivam Cc: manivannan.sadhasivam@oss.qualcomm.com, Bjorn Helgaas , Mahesh J Salgaonkar , Oliver O'Halloran , Will Deacon , Lorenzo Pieralisi , Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= , Rob Herring , Heiko Stuebner , Philipp Zabel , linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org, linux-arm-msm@vger.kernel.org, linux-rockchip@lists.infradead.org, Wilfred Mallawa , Krishna Chaitanya Chundru , Lukas Wunner , Richard Zhu , Brian Norris , Wilson Ding , Frank Li Subject: Re: [PATCH v7 0/4] PCI: Add support for resetting the Root Ports in a platform specific way Message-ID: References: <20260310-pci-port-reset-v7-0-9dd00ccc25ab@oss.qualcomm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.9.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260519_102000_629621_9BEB8643 X-CRM114-Status: GOOD ( 33.37 ) X-BeenThere: linux-rockchip@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Upstream kernel work for Rockchip platforms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "Linux-rockchip" Errors-To: linux-rockchip-bounces+linux-rockchip=archiver.kernel.org@lists.infradead.org Hello Mani, On Mon, May 18, 2026 at 11:51:56AM +0530, Manivannan Sadhasivam wrote: > > > > With the patch above. There is zero difference before/after reset, and all > > the BAR tests pass. However, MSI/MSI-X tests still fail with: > > > > # pci_endpoint_test.c:143:MSI_TEST:Expected 0 (0) == ret (-110) > > # pci_endpoint_test.c:143:MSI_TEST:Test failed for MSI1 > > > > ETIMEDOUT. > > > > This suggests that pci_endpoint_test on the host side did not receive an > > interrupt. > > > > I don't know why, but considering that lspci output is now (with the > > save+restore) identical, I assume that the problem is not related to > > the host. Unless somehow the host will use a new/different MSI address > > after the root port has been reset, and we restore the old MSI address, > > but looking at the code, dw_pcie_msi_init() is called by > > dw_pcie_setup_rc(), so I would expect the MSI address to be the same. > > > > Hi Niklas, > > When I rebased this series on top of v7.1-rc1, I ended up seeing the issue what > you described here (not sure why I didn't see it earlier). So after the Root > Port reset, MSI tests fail, but BAR tests succeed. Also, I got IOMMU faults on > the host after endpoint triggers MSI. > > I investigated it and found that the MSI iATU mapping gets cleared in hw after > LDn happens. But the host continues to use the same address/size for the > endpoint MSI even after reset. Due to this, the existing checks in > dw_pcie_ep_raise_msi_irq() don't pass and the stale MSI iATU mapping gets > reused. > > The fix would be to clear the mapping in dw_pcie_ep_cleanup(), which gets called > as part of the PERST# assert/deassert sequence post LDn and also set > msi_iatu_mapped flag to 'false'. This will force dw_pcie_ep_raise_msi_irq() to > use fresh iATU mapping when it gets called for the first time: > > diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c b/drivers/pci/controller/dwc/pcie-designware-ep.c > index d4dc3b24da60..4ae0e1b55f39 100644 > --- a/drivers/pci/controller/dwc/pcie-designware-ep.c > +++ b/drivers/pci/controller/dwc/pcie-designware-ep.c > @@ -1035,6 +1035,11 @@ void dw_pcie_ep_cleanup(struct dw_pcie_ep *ep) > { > struct dw_pcie *pci = to_dw_pcie_from_ep(ep); > > + if (ep->msi_iatu_mapped) { > + dw_pcie_ep_unmap_addr(ep->epc, 0, 0, ep->msi_mem_phys); > + ep->msi_iatu_mapped = false; > + } > + > dwc_pcie_debugfs_deinit(pci); > dw_pcie_edma_remove(pci); > } > > With this change, MSI works after Root Port reset without any issues on our Qcom > endpoint/host setup. > > Please test this change on your rockchip setup as well. You have to make sure > that dw_pcie_ep_cleanup() is called during PERST# assert/deassert. > > I'm going to respin the series with this fix. If you confirm it works for you, > then we can merge your Rockchip Root Port change. I am happy to hear that you managed to find the root cause! Hopefully your series can finally move forward :) While e.g. RK3588 does have a PERST# input GPIO, so it could theoretically add a perst_deassert()/assert() function. However, when the EPC support was added, you did not want that, since I remember that you said that you only wanted that for drivers that required an external refclock. Thus, for drivers that do not require an external refclock, should we perhaps add your suggested code in dw_pcie_ep_linkdown()? E.g. pcie-tegra194.c does not call dw_pcie_ep_linkdown(), so I'm not sure if we can simply move it from dw_pcie_ep_cleanup() to dw_pcie_ep_linkdown() either... Perhaps we need the code in both functions? (pcie-qcom-ep.c seems to be the only function that will call both dw_pcie_ep_linkdown() and dw_pcie_ep_cleanup().) Kind regards, Niklas _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip