[PATCH] agp/amd64: Bind to unsupported devices only if AGP is present

Lukas Wunner lukas at wunner.de
Wed Jul 2 13:29:48 UTC 2025


[cc += tglx, start of thread:
https://lore.kernel.org/r/f8ff40f35a9a5836d1371f60e85c09c5735e3c5e.1750497201.git.lukas@wunner.de/
]

On Wed, Jul 02, 2025 at 12:47:49PM +0200, Lukas Wunner wrote:
> On Mon, Jun 30, 2025 at 01:10:24PM +0200, Hans de Goede wrote:
> > ping? It would be good to get some consensus on how to
> > fix this and move forward with a fix. Either the patch from
> > this thread; or my patch:
> > 
> > https://lore.kernel.org/dri-devel/20250625112411.4123-1-hansg@kernel.org/
> > 
> > Works for me, the most important thing here is to get this
> > regression fixed.
> 
> You seem to have a machine where you can trigger the
> "Resources present before probing" message.
> 
> Would you mind enabling CONFIG_DEBUG_DEVRES=y and adding
> "log_devres=1" to the kernel command line so that we
> can understand what kind of resource is attached to
> the AMD IOMMU, and where that happens.
> 
> I don't see invocations of devm_*() in arch/x86/ or
> drivers/iommu/amd/ that would explain the error message.

I just remembered that an MSI is set up for the AMD IOMMU.
And sure enough:

amd_iommu_enable_interrupts()
  iommu_init_irq()
    iommu_setup_msi()
      pci_enable_msi()
        __pci_enable_msi_range()
	  pci_setup_msi_device_domain()
            pci_create_device_domain()
              msi_create_device_irq_domain()
                msi_setup_device_data()
                  msi_sysfs_create_group()
		    devm_device_add_group()

... introduced by bf5e758f02fc ("genirq/msi: Simplify sysfs handling").

Not sure if this is the only one or if there are other resources
added anywhere else for the driver-less AMD IOMMU.

We'd have to rework MSI handling to not use devm_*(), so that MSIs
can be requested for a device without it being bound to a driver.
But I suspect tglx may have deliberately designed it to not
support that, in which case what the AMD IOMMU driver does
is somewhat dodgy...

Thanks,

Lukas


More information about the dri-devel mailing list