On Thu, Sep 18, 2025 at 02:45:17PM +0300, Ilpo Järvinen wrote:
On Wed, 17 Sep 2025, Lucas De Marchi wrote:
From: Ilpo Järvinen <ilpo.jarvi...@linux.intel.com>
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 <lucas.demar...@intel.com>
Cc: <sta...@vger.kernel.org> # 6.12+
Link:
https://lore.kernel.org/linux-pci/fl6tx5ztvttg7txmz2ps7oyd745wg3lwcp3h7esmvnyg26n44y@owo2ojiu2mov/
Signed-off-by: Ilpo Järvinen <ilpo.jarvi...@linux.intel.com>
Signed-off-by: Lucas De Marchi <lucas.demar...@intel.com>
---
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).
sorry, it seems `b4 send` that I recently started using behaves
differently than git-send-email and doesn't accept multiple --to
args.
Lucas De Marchi
