From patchwork Thu Jul 11 13:25:44 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Marek_Beh=C3=BAn?= X-Patchwork-Id: 13730728 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 83DA1C3DA49 for ; Thu, 11 Jul 2024 13:26:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:MIME-Version:Message-ID:Date:Subject:Cc:To:From:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Owner; bh=4HjCWvEJTN2ci52I9KiRAUXnvYcaFOUFYGYBLaD5SrI=; b=286bmqzuKprkSsfAHfLOHwBQG5 3kvZuJZfsYgzpFudFf86Uty6m+AEbSRV5Pbt15lKr795A5Mk5A//ySj5M8vKRIFirYiweij7fAYl5 kGqvA3y/0K2bFg/gql6D0U6qvbwxtO4ntE9sMyKyGdnwRraflSwHqdpfQyrH0Q4bdwmfY6s5wNwQX pMflx7YBkDH9ed7kcFdxOrm3MxR+y1AB+g/eRE3ngma75H6d+IOrrf1phbcXbeCGy8XOT4/Zfb1Fe 4oI/3uMIo30Uc4FLiaC/UNNi7TnJD+RKyRBrtA/Mrtlk08Jqy11dvgLOnOroEEmHye1nM8GTFUqY+ cCwbwOjA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sRtoI-0000000E9ZK-1FF2; Thu, 11 Jul 2024 13:26:10 +0000 Received: from sin.source.kernel.org ([145.40.73.55]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sRtnz-0000000E9Sl-3YkA for linux-arm-kernel@lists.infradead.org; Thu, 11 Jul 2024 13:25:53 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 3B9BFCE189F; Thu, 11 Jul 2024 13:25:50 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1B655C116B1; Thu, 11 Jul 2024 13:25:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1720704349; bh=k5bmhPA0dDj6lZmlZdKcCm/UQoTJ5B2ESn1wu8a6a/c=; h=From:To:Cc:Subject:Date:From; b=lLjjkocx3f+o5YelJRRiposcM0mqy+7gZDX7kCmb3rfnVvpigoB8RszkbphxROCDg PBtWRjTeqtnBw6ZF8pQTszOhleOUi7HXsLFBjxAswSHic8lgQERhGRJb3LSneBqH52 bKInMPPUC3lhGIMeQWWL6XTo9jsDIZrETljX2qI5NTsGHtLKTbe2sJKzHMnx2X0il7 Sz0MFPiLEFAhUhsxhQlZEa0VbTr6FPV5RvfgnzbGiNa/UcDgn/o5/vbpLBgNcw4oUU ZsAhvpgELMj0cuxSxlMS9PgRocs2y0jgC6z5aHTYBbz703yqi0Vn2OM8lIRc+EViLs uGFsDOmWICViA== From: =?utf-8?q?Marek_Beh=C3=BAn?= To: Lorenzo Pieralisi , =?utf-8?q?Krzysztof_Wilczy?= =?utf-8?q?=C5=84ski?= , Bjorn Helgaas , Andrew Lunn , Gregory Clement Cc: Thomas Petazzoni , Rob Herring , linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Manivannan Sadhasivam , =?utf-8?q?Marek_B?= =?utf-8?q?eh=C3=BAn?= Subject: [PATCH v2] PCI: mvebu: Dispose INTx IRQs before to removing INTx domain Date: Thu, 11 Jul 2024 15:25:44 +0200 Message-ID: <20240711132544.9048-1-kabel@kernel.org> X-Mailer: git-send-email 2.44.2 MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240711_062552_097676_7ED53A71 X-CRM114-Status: GOOD ( 16.52 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org From: Pali Rohár The documentation for the irq_domain_remove() function says that all mappings within the IRQ domain must be disposed before the domain is removed. Currently, the INTx IRQs are not disposed in pci-mvebu driver .remove() method, which causes the kernel to crash when unloading the driver and then reading /sys/kernel/debug/irq/irqs/ or /proc/interrupts. Unmapping of the IRQs at this point of the .remove() method is safe, since the PCIe bus is already unregistered, and all its devices are unbound from their drivers and removed. If there was indeed any remaining use of PCIe resources, then it would mean that PCIe hotplug code is broken, and we have bigger problems. Fixes: ec075262648f ("PCI: mvebu: Implement support for legacy INTx interrupts") Reported-by: Hajo Noerenberg Signed-off-by: Pali Rohár Reviewed-by: Marek Behún [ Marek: refactored a little, added more explanation to commit message ] Signed-off-by: Marek Behún Reviewed-by: Manivannan Sadhasivam Reviewed-by: Andrew Lunn --- Changes since v1: - added explanation into commit message about why this is safe to do, as suggested by Andy. The explanation originally comes from Pali: https://lore.kernel.org/linux-arm-kernel/20220809133911.hqi7eyskcq2sojia@pali/ --- drivers/pci/controller/pci-mvebu.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/pci/controller/pci-mvebu.c b/drivers/pci/controller/pci-mvebu.c index 29fe09c99e7d..91a02b23aeb1 100644 --- a/drivers/pci/controller/pci-mvebu.c +++ b/drivers/pci/controller/pci-mvebu.c @@ -1683,8 +1683,15 @@ static void mvebu_pcie_remove(struct platform_device *pdev) irq_set_chained_handler_and_data(irq, NULL, NULL); /* Remove IRQ domains. */ - if (port->intx_irq_domain) + if (port->intx_irq_domain) { + for (int j = 0; j < PCI_NUM_INTX; j++) { + int virq = irq_find_mapping(port->intx_irq_domain, j); + + if (virq > 0) + irq_dispose_mapping(virq); + } irq_domain_remove(port->intx_irq_domain); + } /* Free config space for emulated root bridge. */ pci_bridge_emul_cleanup(&port->bridge);