Patch "iommu/amd: Mark interrupt as managed" has been added to the 6.6-stable tree

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

 



This is a note to let you know that I've just added the patch titled

    iommu/amd: Mark interrupt as managed

to the 6.6-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     iommu-amd-mark-interrupt-as-managed.patch
and it can be found in the queue-6.6 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.



commit 18d379166480d2c8c6ca74ee2e9d0d8052343908
Author: Mario Limonciello <mario.limonciello@xxxxxxx>
Date:   Mon Jan 22 17:34:00 2024 -0600

    iommu/amd: Mark interrupt as managed
    
    [ 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=_prt#prt-pci-routing-table [1]
    Signed-off-by: Mario Limonciello <mario.limonciello@xxxxxxx>
    Fixes: cffe0a2b5a34 ("x86, irq: Keep balance of IOAPIC pin reference count")
    Reviewed-by: Vasant Hegde <vasant.hegde@xxxxxxx>
    Link: https://lore.kernel.org/r/20240122233400.1802-1-mario.limonciello@xxxxxxx
    Signed-off-by: Joerg Roedel <jroedel@xxxxxxx>
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/drivers/iommu/amd/init.c b/drivers/iommu/amd/init.c
index 45efb7e5d7254..a2ad2dbd04d92 100644
--- a/drivers/iommu/amd/init.c
+++ b/drivers/iommu/amd/init.c
@@ -2084,6 +2084,9 @@ static int __init iommu_init_pci(struct amd_iommu *iommu)
 	/* Prevent binding other PCI device drivers to IOMMU devices */
 	iommu->dev->match_driver = false;
 
+	/* ACPI _PRT won't have an IRQ for IOMMU */
+	iommu->dev->irq_managed = 1;
+
 	pci_read_config_dword(iommu->dev, cap_ptr + MMIO_CAP_HDR_OFFSET,
 			      &iommu->cap);
 




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux