On Wed, 17 Sep 2025, Lucas De Marchi wrote:
> From: Ilpo Järvinen <[email protected]>
>
> Resizing BAR to a larger size has to release upstream bridge windows in
> order make the bridge windows larger as well (and to potential relocate
> them into a larger free block within iomem space). Some GPUs have an
> integrated PCI switch that has BAR0. The resource allocation assigns
> space for that BAR0 as it does for any resource.
>
> An extra resource on a bridge will pin its upstream bridge window in
> place which prevents BAR resize for anything beneath that bridge.
>
> Nothing in the pcieport driver provided by PCI core, which typically is
> the driver bound to these bridges, requires that BAR0. Because of that,
> releasing the extra BAR does not seem to have notable downsides but
> comes with a clear upside.
>
> Therefore, release BAR0 of such switches using a quirk and clear its
> flags to prevent any new invocation of the resource assignment
> algorithm from assigning the resource again.
>
> Due to other siblings within the PCI hierarchy of all the devices
> integrated into the GPU, some other devices may still have to be
> manually removed before the resize is free of any bridge window pins.
> Such siblings can be released through sysfs to unpin windows while
> leaving access to GPU's sysfs entries required for initiating the
> resize operation, whereas removing the topmost bridge this quirk
> targets would result in removing the GPU device as well so no manual
> workaround for this problem exists.
>
> Reported-by: Lucas De Marchi <[email protected]>
> Cc: <[email protected]> # 6.12+
> Link:
> https://lore.kernel.org/linux-pci/fl6tx5ztvttg7txmz2ps7oyd745wg3lwcp3h7esmvnyg26n44y@owo2ojiu2mov/
> Signed-off-by: Ilpo Järvinen <[email protected]>
> Signed-off-by: Lucas De Marchi <[email protected]>
> ---
> drivers/pci/quirks.c | 20 ++++++++++++++++++++
Please include all relevant people into submissions. You've left all PCI
receipients out (except me).
I also recommend you leave that part I put under --- line into the
submission as it explain my position on why I think it's reasonable
interim solution as we don't expect it more complicated solution to be
something we wnat to push into older kernels (perhaps mark it as
"Remarks from Ilpo:" or something along those lines so it doesn't get
misattributed to you).
--
i.
> 1 file changed, 20 insertions(+)
>
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index d97335a401930..98a4f0a1285be 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -6338,3 +6338,23 @@ static void pci_mask_replay_timer_timeout(struct
> pci_dev *pdev)
> DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_GLI, 0x9750,
> pci_mask_replay_timer_timeout);
> DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_GLI, 0x9755,
> pci_mask_replay_timer_timeout);
> #endif
> +
> +/*
> + * PCI switches integrated into some GPUs have BAR0 that prevents resizing
> + * the BARs of the GPU device due to that bridge BAR0 pinning the bridge
> + * window it's under in place. Nothing in pcieport requires that BAR0.
> + *
> + * Release and disable BAR0 permanently by clearing its flags to prevent
> + * anything from assigning it again.
> + */
> +static void pci_release_bar0(struct pci_dev *pdev)
> +{
> + struct resource *res = pci_resource_n(pdev, 0);
> +
> + if (!res->parent)
> + return;
> +
> + pci_release_resource(pdev, 0);
> + res->flags = 0;
> +}
> +DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_INTEL, 0xe2ff, pci_release_bar0);
>
>
