From nobody Fri Dec 19 20:14:38 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 059A1180A8F; Sun, 24 Mar 2024 23:47:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711324056; cv=none; b=QWIa+OGutsGK1RGDi9X+MOQFpzAvpBL9vvkdUobKChqiz+FPVWxW5C5+NmlfcDspanRuZ2hPd3qwyIGhijqdosf3J0Eo24+cD7V66rj0RYtVRwctGlNHqduh1JC+L+6gs0BK4+q0ejCpScz7yCsSqXa5pXuaBXl07tR9a/R/eY0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711324056; c=relaxed/simple; bh=NzjFbhFV+1szkeOU6f/PGRB/2eW54jz9i68ODl8u9+Y=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=F2Sgvwy4+eyEcd+TLLxT2JgaYGMcmKovM2kNf+3zjrTvHQQjGeigAHpwaWar3CnWGGZe706SBth0X0UuNYWpXnUGNe5X7h7j6TPjRs1x9QdZG8Bx8XiB0coiRaV2KAQwrYHSTqjjg5oaC/w4sdwBUCKGIzcLAuAl4Nmq7J4w8Io= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=lmn8lyn4; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="lmn8lyn4" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D231CC43394; Sun, 24 Mar 2024 23:47:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711324054; bh=NzjFbhFV+1szkeOU6f/PGRB/2eW54jz9i68ODl8u9+Y=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=lmn8lyn43Xe2U1jL3X9lMwoXOR4McKOln5q3RnORh2dgCQFhaJZbrfhennup2GFC6 5Mc+0HWN7PLD/HhmDZpXeE+KKS9lWFs7hdElKhhWQ2xBMKHBniGI0ZD1NB9OYj3t1U R4Hg9Us//k25Sltj5HBr3TfAUtRQRnyc9IoykqreHA3JMTYepOd2jmYecmvWtV+RpR YGjr+17AvFfSNUnCFRcN3++JPxUFw3pl78MyfULWc1rd8x8dYF2H6I/khm2dwWei1b 5ImVGIiRFvmWPUNpLm+rIbZKglGr5sDRHsJ295Y2MytDEnbWT2KZJiYmKImsVp4dY7 etnT45aVSy6+g== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Mario Limonciello , Vasant Hegde , Joerg Roedel , Sasha Levin Subject: [PATCH 5.4 055/183] iommu/amd: Mark interrupt as managed Date: Sun, 24 Mar 2024 19:44:28 -0400 Message-ID: <20240324234638.1355609-56-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324234638.1355609-1-sashal@kernel.org> References: <20240324234638.1355609-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Mario Limonciello [ Upstream commit 0feda94c868d396fac3b3cb14089d2d989a07c72 ] On many systems that have an AMD IOMMU the following sequence of warnings is observed during bootup. ``` pci 0000:00:00.2 can't derive routing for PCI INT A pci 0000:00:00.2: PCI INT A: not connected ``` This series of events happens because of the IOMMU initialization sequence order and the lack of _PRT entries for the IOMMU. During initialization the IOMMU driver first enables the PCI device using pci_enable_device(). This will call acpi_pci_irq_enable() which will check if the interrupt is declared in a PCI routing table (_PRT) entry. According to the PCI spec [1] these routing entries are only required under PCI root bridges: The _PRT object is required under all PCI root bridges The IOMMU is directly connected to the root complex, so there is no parent bridge to look for a _PRT entry. The first warning is emitted since no entry could be found in the hierarchy. The second warning is then emitted because the interrupt hasn't yet been configured to any value. The pin was configured in pci_read_irq() but the byte in PCI_INTERRUPT_LINE return 0xff which means "Unknown". After that sequence of events pci_enable_msi() is called and this will allocate an interrupt. That is both of these warnings are totally harmless because the IOMMU uses MSI for interrupts. To avoid even trying to probe for a _PRT entry mark the IOMMU as IRQ managed. This avoids both warnings. Link: https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/06_Device_Configuration= /Device_Configuration.html?highlight=3D_prt#prt-pci-routing-table [1] Signed-off-by: Mario Limonciello Fixes: cffe0a2b5a34 ("x86, irq: Keep balance of IOAPIC pin reference count") Reviewed-by: Vasant Hegde Link: https://lore.kernel.org/r/20240122233400.1802-1-mario.limonciello@amd= .com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin --- drivers/iommu/amd_iommu_init.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c index 4a9feff340da7..15e25f712f393 100644 --- a/drivers/iommu/amd_iommu_init.c +++ b/drivers/iommu/amd_iommu_init.c @@ -1745,6 +1745,9 @@ static int __init iommu_init_pci(struct amd_iommu *io= mmu) /* Prevent binding other PCI device drivers to IOMMU devices */ iommu->dev->match_driver =3D false; =20 + /* ACPI _PRT won't have an IRQ for IOMMU */ + iommu->dev->irq_managed =3D 1; + pci_read_config_dword(iommu->dev, cap_ptr + MMIO_CAP_HDR_OFFSET, &iommu->cap); pci_read_config_dword(iommu->dev, cap_ptr + MMIO_RANGE_OFFSET, --=20 2.43.0