On Thu, Oct 15, 2026 at 03:25:17PM -0500, Mario Limonciello wrote:
> On 10/15/26 14:48, Bjorn Helgaas wrote:
> > [+cc Alex, Ilpo, Lukas, linux-acpi]
> >
> > On Thu, Oct 15, 2026 at 07:48:42AM -0500, Mario Limonciello wrote:
> > > The soft filter system introduced by commit 11c141672045f ("drm/amdgpu:
> > > Fix VFCT bus number matching with soft filter") has a deficiency that
> > > it won't work when there are multiple GPUs of the exact same model.
> > >
> > > As it was introduced specifically to help the case of pci=realloc, gate
> > > it to only run when that's in use.
> > >
> > > Fixes: 11c141672045f ("drm/amdgpu: Fix VFCT bus number matching with soft
> > > filter")
> > > Reported-by: Reza Nikzad Chaleshori <[email protected]>
> > > Closes:
> > > https://lore.kernel.org/amd-gfx/[email protected]/
> > > Signed-off-by: Mario Limonciello <[email protected]>
> > > ---
> > > drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c | 15 ++++++++-------
> > > drivers/pci/setup-bus.c | 5 +++++
> > > include/linux/pci.h | 1 +
> > > 3 files changed, 14 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
> > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
> > > index 08ed1eb695586..75af9a59671ae 100644
> > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
> > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
> > > @@ -384,12 +384,10 @@ static bool amdgpu_read_disabled_bios(struct
> > > amdgpu_device *adev)
> > > * @vhdr: VFCT image header to check
> > > *
> > > * VFCT entries contain the PCI bus number as recorded during BIOS POST.
> > > - * On systems where the kernel renumbers PCI buses (e.g. pci=realloc or
> > > - * resource conflicts), the runtime bus number may differ from the POST
> > > - * value. Match by device identity (vendor + device + function) and use
> > > - * the bus number as a preference: exact bus match is preferred, but when
> > > - * the bus numbers disagree we accept the entry if the device identity
> > > - * matches.
> > > + * On systems where the user requested PCI resource reallocation, the
> > > + * runtime bus number may differ from the POST value. Match by device
> > > + * identity (vendor + device + function), but only treat the bus number
> > > as
> > > + * a preference when pci=realloc was explicitly requested.
> >
> > This is a generic problem, isn't it?
> >
> > I think any table from firmware that has PCI bus numbers in it could
> > trip over issues like this. Seems like we need a more generic
> > solution.
>
> Yeah; it's a generic issue which was triggered by pci=realloc which is why I
> did a soft filter in 11c141672045f.
>
> But this causes problems when you have two (or more) of the exact same
> device. You might match the wrong thing.
>
> > > *
> > > * Returns: 0 on match, -ENODEV on no match
> > > */
> > > @@ -409,7 +407,10 @@ static int amdgpu_acpi_vfct_match(struct
> > > amdgpu_device *adev,
> > > if (vhdr->PCIBus == adev->pdev->bus->number)
> > > return 0;
> > > - /* Bus mismatch but device identity matches (PCI renumbering case) */
> > > + /* Allow bus renumbering only when the user requested pci=realloc. */
> > > + if (!pci_realloc_enabled_by_user())
> > > + return -ENODEV;
> > > +
> > > dev_notice(adev->dev,
> > > "VFCT bus number mismatch: table %u != runtime %u,
> > > matching by device identity (vendor 0x%04x device 0x%04x)\n",
> > > vhdr->PCIBus, adev->pdev->bus->number,
> > > diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
> > > index ed16ef7c26fa7..d9450585082c0 100644
> > > --- a/drivers/pci/setup-bus.c
> > > +++ b/drivers/pci/setup-bus.c
> > > @@ -1799,6 +1799,11 @@ static bool pci_realloc_enabled(enum enable_type
> > > enable)
> > > return enable >= user_enabled;
> > > }
> > > +bool pci_realloc_enabled_by_user(void)
> > > +{
> > > + return pci_realloc_enable == user_enabled;
> > > +}
> >
> > I don't like this. I think the same bus renumbering can happen in the
> > "auto_enabled" case, and I don't think we set pci_realloc_enable in
> > that case.
> >
> > But more generally, I think ultimately the PCI core should be able to
> > reassign bus numbers arbitrarily to accommodate hotplugs (given the
> > appropriate driver support to tolerate that, of course).
>
> Could we keep track of the original perhaps? Then drivers can know
> what it was reassigned from?
I think the only thing that can change is the bus number, and saving
the original bus number in a struct pci_bus or similar might be
practical?
