[PATCH v2 00/11] PCI: Resizable BAR improvements

[PATCH v2 00/11] PCI: Resizable BAR improvements

[Ilpo Järvinen]

pci.c has been used as catch everything that doesn't fits elsewhere
within PCI core and thus resizable BAR code has been placed there as
well. Move Resizable BAR related code to a newly introduced rebar.c to
reduce size of pci.c. After move, there are no pci_rebar_*() calls from
pci.c indicating this is indeed well-defined subset of PCI core.

Endpoint drivers perform Resizable BAR related operations which could
well be performed by PCI core to simplify driver-side code. This
series adds a few new API functions to that effect and converts the
drivers to use the new APIs (in separate patches).

While at it, also convert BAR sizes bitmask to u64 as PCIe spec already
specifies more sizes than what will fit u32 to make the API typing more
future-proof. The extra sizes beyond 128TB are not added at this point.

These are based on pci/main plus a simple "adapter" patch to add the
include for xe_vram_types.h that was added by a commit in drm-tip.
Hopefully that is enough to avoid the within context conflict with
BAR_SIZE_SHIFT removal to let the xe CI tests to be run for this
series.

There are two minor conflicts with the work in pci/resource but I'm
hesitant to base this on top of it as this is otherwise entirely
independent (and would likely prevent GPU CI tests as well). If we end
up having to pull the bridge window select changes, there should be no
reason why this does have to become collateral damage (so my
suggestion, if this is good to go in this cycle, to take this into a
separate branch than pci/resource and deal with those small conflicts
while merging into pci/next).

I've tested sysfs resize, i915, and xe BAR resizing functionality. In
the case of xe, I did small hack patch as its resize is anyway broken
as is because BAR0 pins the bridge window so resizing BAR2 fails. My
hack caused other problems further down the road (likely because BAR0
is in use by the driver so releasing it messed assumptions xe driver
has) but the BAR resize itself was working which was all I was
interested to know. I'm not planning to pursue fixing the pinning
problem within xe driver because the core changes to consider maximum
size of the resizable BARs should take care of the main problem by
different means.

Some parts of this are to be used by the resizable BAR changes into the
resource fitting/assingment logic but these seem to stand on their own
so sending these out now to reduce the size of the other patch series.

v2:
- Kerneldoc:
  - Improve formatting of errno returns
  - Open "ctrl" -> "control"
  - Removed mislead "bit" words (when referring to BAR size)
  - Rewrote pci_rebar_get_possible_sizes() kernel doc to not claim the
    returned bitmask is defined in PCIe spec as the capability bits now
    span across two registers in the spec and are not continuous (we
    don't support the second block of bits yet, but this API is expected
    to return the bits without the hole so it will not be matching with
    the spec layout).
- Dropped superfluous zero check from pci_rebar_size_supported()
- Small improvement to changelog of patch 7

Ilpo Järvinen (11):
  PCI: Move Resizable BAR code into rebar.c
  PCI: Cleanup pci_rebar_bytes_to_size() and move into rebar.c
  PCI: Move pci_rebar_size_to_bytes() and export it
  PCI: Improve Resizable BAR functions kernel doc
  PCI: Add pci_rebar_size_supported() helper
  drm/i915/gt: Use pci_rebar_size_supported()
  drm/xe/vram: Use PCI rebar helpers in resize_vram_bar()
  PCI: Add pci_rebar_get_max_size()
  drm/xe/vram: Use pci_rebar_get_max_size()
  drm/amdgpu: Use pci_rebar_get_max_size()
  PCI: Convert BAR sizes bitmasks to u64

 Documentation/driver-api/pci/pci.rst        |   3 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c  |   8 +-
 drivers/gpu/drm/i915/gt/intel_region_lmem.c |  10 +-
 drivers/gpu/drm/xe/xe_vram.c                |  32 +-
 drivers/pci/Makefile                        |   2 +-
 drivers/pci/iov.c                           |   9 +-
 drivers/pci/pci-sysfs.c                     |   2 +-
 drivers/pci/pci.c                           | 145 ---------
 drivers/pci/pci.h                           |   5 +-
 drivers/pci/rebar.c                         | 314 ++++++++++++++++++++
 drivers/pci/setup-res.c                     |  78 -----
 include/linux/pci.h                         |  15 +-
 12 files changed, 350 insertions(+), 273 deletions(-)
 create mode 100644 drivers/pci/rebar.c


base-commit: 8f5ae30d69d7543eee0d70083daf4de8fe15d585
prerequisite-patch-id: 35bd3cd7a60ff7d887450a7fdde73b055a76ae24
-- 
2.39.5

[PATCH v2 01/11] PCI: Move Resizable BAR code into rebar.c

[Ilpo Järvinen]

In the lack of better place to put it, Resizable BAR code has been
placed inside pci.c and setup-res.c that do not use it for anything.
Upcoming changes are going to add more Resizable BAR related API
functions to PCI core increasing the Resizable BAR code size from the
current.

As pci.c is huge file as is, extract the Resizable BAR related code out
of it into rebar.c and move the actual BAR resize code from setup-res.c
as well.

Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
---
 Documentation/driver-api/pci/pci.rst |   3 +
 drivers/pci/Makefile                 |   2 +-
 drivers/pci/pci.c                    | 145 ----------------
 drivers/pci/pci.h                    |   1 +
 drivers/pci/rebar.c                  | 236 +++++++++++++++++++++++++++
 drivers/pci/setup-res.c              |  78 ---------
 6 files changed, 241 insertions(+), 224 deletions(-)
 create mode 100644 drivers/pci/rebar.c

diff --git a/Documentation/driver-api/pci/pci.rst b/Documentation/driver-api/pci/pci.rst
index 59d86e827198..99a1bbaaec5d 100644
--- a/Documentation/driver-api/pci/pci.rst
+++ b/Documentation/driver-api/pci/pci.rst
@@ -37,6 +37,9 @@ PCI Support Library
 .. kernel-doc:: drivers/pci/slot.c
    :export:
 
+.. kernel-doc:: drivers/pci/rebar.c
+   :export:
+
 .. kernel-doc:: drivers/pci/rom.c
    :export:
 
diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
index 67647f1880fb..f3c81c892786 100644
--- a/drivers/pci/Makefile
+++ b/drivers/pci/Makefile
@@ -4,7 +4,7 @@
 
 obj-$(CONFIG_PCI)		+= access.o bus.o probe.o host-bridge.o \
 				   remove.o pci.o pci-driver.o search.o \
-				   rom.o setup-res.o irq.o vpd.o \
+				   rebar.o rom.o setup-res.o irq.o vpd.o \
 				   setup-bus.o vc.o mmap.o devres.o
 
 obj-$(CONFIG_PCI)		+= msi/
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index b0f4d98036cd..da3a48bf2799 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -1874,32 +1874,6 @@ static void pci_restore_config_space(struct pci_dev *pdev)
 	}
 }
 
-static void pci_restore_rebar_state(struct pci_dev *pdev)
-{
-	unsigned int pos, nbars, i;
-	u32 ctrl;
-
-	pos = pdev->rebar_cap;
-	if (!pos)
-		return;
-
-	pci_read_config_dword(pdev, pos + PCI_REBAR_CTRL, &ctrl);
-	nbars = FIELD_GET(PCI_REBAR_CTRL_NBAR_MASK, ctrl);
-
-	for (i = 0; i < nbars; i++, pos += 8) {
-		struct resource *res;
-		int bar_idx, size;
-
-		pci_read_config_dword(pdev, pos + PCI_REBAR_CTRL, &ctrl);
-		bar_idx = ctrl & PCI_REBAR_CTRL_BAR_IDX;
-		res = pci_resource_n(pdev, bar_idx);
-		size = pci_rebar_bytes_to_size(resource_size(res));
-		ctrl &= ~PCI_REBAR_CTRL_BAR_SIZE;
-		ctrl |= FIELD_PREP(PCI_REBAR_CTRL_BAR_SIZE, size);
-		pci_write_config_dword(pdev, pos + PCI_REBAR_CTRL, ctrl);
-	}
-}
-
 /**
  * pci_restore_state - Restore the saved state of a PCI device
  * @dev: PCI device that we're dealing with
@@ -3738,125 +3712,6 @@ void pci_acs_init(struct pci_dev *dev)
 	pci_enable_acs(dev);
 }
 
-void pci_rebar_init(struct pci_dev *pdev)
-{
-	pdev->rebar_cap = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_REBAR);
-}
-
-/**
- * pci_rebar_find_pos - find position of resize ctrl reg for BAR
- * @pdev: PCI device
- * @bar: BAR to find
- *
- * Helper to find the position of the ctrl register for a BAR.
- * Returns -ENOTSUPP if resizable BARs are not supported at all.
- * Returns -ENOENT if no ctrl register for the BAR could be found.
- */
-static int pci_rebar_find_pos(struct pci_dev *pdev, int bar)
-{
-	unsigned int pos, nbars, i;
-	u32 ctrl;
-
-	if (pci_resource_is_iov(bar)) {
-		pos = pci_iov_vf_rebar_cap(pdev);
-		bar = pci_resource_num_to_vf_bar(bar);
-	} else {
-		pos = pdev->rebar_cap;
-	}
-
-	if (!pos)
-		return -ENOTSUPP;
-
-	pci_read_config_dword(pdev, pos + PCI_REBAR_CTRL, &ctrl);
-	nbars = FIELD_GET(PCI_REBAR_CTRL_NBAR_MASK, ctrl);
-
-	for (i = 0; i < nbars; i++, pos += 8) {
-		int bar_idx;
-
-		pci_read_config_dword(pdev, pos + PCI_REBAR_CTRL, &ctrl);
-		bar_idx = FIELD_GET(PCI_REBAR_CTRL_BAR_IDX, ctrl);
-		if (bar_idx == bar)
-			return pos;
-	}
-
-	return -ENOENT;
-}
-
-/**
- * pci_rebar_get_possible_sizes - get possible sizes for BAR
- * @pdev: PCI device
- * @bar: BAR to query
- *
- * Get the possible sizes of a resizable BAR as bitmask defined in the spec
- * (bit 0=1MB, bit 31=128TB). Returns 0 if BAR isn't resizable.
- */
-u32 pci_rebar_get_possible_sizes(struct pci_dev *pdev, int bar)
-{
-	int pos;
-	u32 cap;
-
-	pos = pci_rebar_find_pos(pdev, bar);
-	if (pos < 0)
-		return 0;
-
-	pci_read_config_dword(pdev, pos + PCI_REBAR_CAP, &cap);
-	cap = FIELD_GET(PCI_REBAR_CAP_SIZES, cap);
-
-	/* Sapphire RX 5600 XT Pulse has an invalid cap dword for BAR 0 */
-	if (pdev->vendor == PCI_VENDOR_ID_ATI && pdev->device == 0x731f &&
-	    bar == 0 && cap == 0x700)
-		return 0x3f00;
-
-	return cap;
-}
-EXPORT_SYMBOL(pci_rebar_get_possible_sizes);
-
-/**
- * pci_rebar_get_current_size - get the current size of a BAR
- * @pdev: PCI device
- * @bar: BAR to set size to
- *
- * Read the size of a BAR from the resizable BAR config.
- * Returns size if found or negative error code.
- */
-int pci_rebar_get_current_size(struct pci_dev *pdev, int bar)
-{
-	int pos;
-	u32 ctrl;
-
-	pos = pci_rebar_find_pos(pdev, bar);
-	if (pos < 0)
-		return pos;
-
-	pci_read_config_dword(pdev, pos + PCI_REBAR_CTRL, &ctrl);
-	return FIELD_GET(PCI_REBAR_CTRL_BAR_SIZE, ctrl);
-}
-
-/**
- * pci_rebar_set_size - set a new size for a BAR
- * @pdev: PCI device
- * @bar: BAR to set size to
- * @size: new size as defined in the spec (0=1MB, 31=128TB)
- *
- * Set the new size of a BAR as defined in the spec.
- * Returns zero if resizing was successful, error code otherwise.
- */
-int pci_rebar_set_size(struct pci_dev *pdev, int bar, int size)
-{
-	int pos;
-	u32 ctrl;
-
-	pos = pci_rebar_find_pos(pdev, bar);
-	if (pos < 0)
-		return pos;
-
-	pci_read_config_dword(pdev, pos + PCI_REBAR_CTRL, &ctrl);
-	ctrl &= ~PCI_REBAR_CTRL_BAR_SIZE;
-	ctrl |= FIELD_PREP(PCI_REBAR_CTRL_BAR_SIZE, size);
-	pci_write_config_dword(pdev, pos + PCI_REBAR_CTRL, ctrl);
-	return 0;
-}
-
 /**
  * pci_enable_atomic_ops_to_root - enable AtomicOp requests to root port
  * @dev: the PCI device
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index 34f65d69662e..f1b30414b2f1 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -926,6 +926,7 @@ static inline int acpi_get_rc_resources(struct device *dev, const char *hid,
 #endif
 
 void pci_rebar_init(struct pci_dev *pdev);
+void pci_restore_rebar_state(struct pci_dev *pdev);
 int pci_rebar_get_current_size(struct pci_dev *pdev, int bar);
 int pci_rebar_set_size(struct pci_dev *pdev, int bar, int size);
 static inline u64 pci_rebar_size_to_bytes(int size)
diff --git a/drivers/pci/rebar.c b/drivers/pci/rebar.c
new file mode 100644
index 000000000000..b87cfa6fb3ef
--- /dev/null
+++ b/drivers/pci/rebar.c
@@ -0,0 +1,236 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * PCI Resizable BAR Extended Capability handling.
+ */
+
+#include <linux/bitfield.h>
+#include <linux/errno.h>
+#include <linux/export.h>
+#include <linux/ioport.h>
+#include <linux/pci.h>
+#include <linux/types.h>
+
+#include "pci.h"
+
+void pci_rebar_init(struct pci_dev *pdev)
+{
+	pdev->rebar_cap = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_REBAR);
+}
+
+/**
+ * pci_rebar_find_pos - find position of resize ctrl reg for BAR
+ * @pdev: PCI device
+ * @bar: BAR to find
+ *
+ * Helper to find the position of the ctrl register for a BAR.
+ * Returns -ENOTSUPP if resizable BARs are not supported at all.
+ * Returns -ENOENT if no ctrl register for the BAR could be found.
+ */
+static int pci_rebar_find_pos(struct pci_dev *pdev, int bar)
+{
+	unsigned int pos, nbars, i;
+	u32 ctrl;
+
+	if (pci_resource_is_iov(bar)) {
+		pos = pci_iov_vf_rebar_cap(pdev);
+		bar = pci_resource_num_to_vf_bar(bar);
+	} else {
+		pos = pdev->rebar_cap;
+	}
+
+	if (!pos)
+		return -ENOTSUPP;
+
+	pci_read_config_dword(pdev, pos + PCI_REBAR_CTRL, &ctrl);
+	nbars = FIELD_GET(PCI_REBAR_CTRL_NBAR_MASK, ctrl);
+
+	for (i = 0; i < nbars; i++, pos += 8) {
+		int bar_idx;
+
+		pci_read_config_dword(pdev, pos + PCI_REBAR_CTRL, &ctrl);
+		bar_idx = FIELD_GET(PCI_REBAR_CTRL_BAR_IDX, ctrl);
+		if (bar_idx == bar)
+			return pos;
+	}
+
+	return -ENOENT;
+}
+
+/**
+ * pci_rebar_get_possible_sizes - get possible sizes for BAR
+ * @pdev: PCI device
+ * @bar: BAR to query
+ *
+ * Get the possible sizes of a resizable BAR as bitmask defined in the spec
+ * (bit 0=1MB, bit 31=128TB). Returns 0 if BAR isn't resizable.
+ */
+u32 pci_rebar_get_possible_sizes(struct pci_dev *pdev, int bar)
+{
+	int pos;
+	u32 cap;
+
+	pos = pci_rebar_find_pos(pdev, bar);
+	if (pos < 0)
+		return 0;
+
+	pci_read_config_dword(pdev, pos + PCI_REBAR_CAP, &cap);
+	cap = FIELD_GET(PCI_REBAR_CAP_SIZES, cap);
+
+	/* Sapphire RX 5600 XT Pulse has an invalid cap dword for BAR 0 */
+	if (pdev->vendor == PCI_VENDOR_ID_ATI && pdev->device == 0x731f &&
+	    bar == 0 && cap == 0x700)
+		return 0x3f00;
+
+	return cap;
+}
+EXPORT_SYMBOL(pci_rebar_get_possible_sizes);
+
+/**
+ * pci_rebar_get_current_size - get the current size of a BAR
+ * @pdev: PCI device
+ * @bar: BAR to set size to
+ *
+ * Read the size of a BAR from the resizable BAR config.
+ * Returns size if found or negative error code.
+ */
+int pci_rebar_get_current_size(struct pci_dev *pdev, int bar)
+{
+	int pos;
+	u32 ctrl;
+
+	pos = pci_rebar_find_pos(pdev, bar);
+	if (pos < 0)
+		return pos;
+
+	pci_read_config_dword(pdev, pos + PCI_REBAR_CTRL, &ctrl);
+	return FIELD_GET(PCI_REBAR_CTRL_BAR_SIZE, ctrl);
+}
+
+/**
+ * pci_rebar_set_size - set a new size for a BAR
+ * @pdev: PCI device
+ * @bar: BAR to set size to
+ * @size: new size as defined in the spec (0=1MB, 31=128TB)
+ *
+ * Set the new size of a BAR as defined in the spec.
+ * Returns zero if resizing was successful, error code otherwise.
+ */
+int pci_rebar_set_size(struct pci_dev *pdev, int bar, int size)
+{
+	int pos;
+	u32 ctrl;
+
+	pos = pci_rebar_find_pos(pdev, bar);
+	if (pos < 0)
+		return pos;
+
+	pci_read_config_dword(pdev, pos + PCI_REBAR_CTRL, &ctrl);
+	ctrl &= ~PCI_REBAR_CTRL_BAR_SIZE;
+	ctrl |= FIELD_PREP(PCI_REBAR_CTRL_BAR_SIZE, size);
+	pci_write_config_dword(pdev, pos + PCI_REBAR_CTRL, ctrl);
+	return 0;
+}
+
+void pci_restore_rebar_state(struct pci_dev *pdev)
+{
+	unsigned int pos, nbars, i;
+	u32 ctrl;
+
+	pos = pdev->rebar_cap;
+	if (!pos)
+		return;
+
+	pci_read_config_dword(pdev, pos + PCI_REBAR_CTRL, &ctrl);
+	nbars = FIELD_GET(PCI_REBAR_CTRL_NBAR_MASK, ctrl);
+
+	for (i = 0; i < nbars; i++, pos += 8) {
+		struct resource *res;
+		int bar_idx, size;
+
+		pci_read_config_dword(pdev, pos + PCI_REBAR_CTRL, &ctrl);
+		bar_idx = ctrl & PCI_REBAR_CTRL_BAR_IDX;
+		res = pci_resource_n(pdev, bar_idx);
+		size = pci_rebar_bytes_to_size(resource_size(res));
+		ctrl &= ~PCI_REBAR_CTRL_BAR_SIZE;
+		ctrl |= FIELD_PREP(PCI_REBAR_CTRL_BAR_SIZE, size);
+		pci_write_config_dword(pdev, pos + PCI_REBAR_CTRL, ctrl);
+	}
+}
+
+static bool pci_resize_is_memory_decoding_enabled(struct pci_dev *dev,
+						  int resno)
+{
+	u16 cmd;
+
+	if (pci_resource_is_iov(resno))
+		return pci_iov_is_memory_decoding_enabled(dev);
+
+	pci_read_config_word(dev, PCI_COMMAND, &cmd);
+
+	return cmd & PCI_COMMAND_MEMORY;
+}
+
+static void pci_resize_resource_set_size(struct pci_dev *dev, int resno,
+					 int size)
+{
+	resource_size_t res_size = pci_rebar_size_to_bytes(size);
+	struct resource *res = pci_resource_n(dev, resno);
+
+	if (!pci_resource_is_iov(resno)) {
+		resource_set_size(res, res_size);
+	} else {
+		resource_set_size(res, res_size * pci_sriov_get_totalvfs(dev));
+		pci_iov_resource_set_size(dev, resno, res_size);
+	}
+}
+
+int pci_resize_resource(struct pci_dev *dev, int resno, int size)
+{
+	struct resource *res = pci_resource_n(dev, resno);
+	struct pci_host_bridge *host;
+	int old, ret;
+	u32 sizes;
+
+	/* Check if we must preserve the firmware's resource assignment */
+	host = pci_find_host_bridge(dev->bus);
+	if (host->preserve_config)
+		return -ENOTSUPP;
+
+	/* Make sure the resource isn't assigned before resizing it. */
+	if (!(res->flags & IORESOURCE_UNSET))
+		return -EBUSY;
+
+	if (pci_resize_is_memory_decoding_enabled(dev, resno))
+		return -EBUSY;
+
+	sizes = pci_rebar_get_possible_sizes(dev, resno);
+	if (!sizes)
+		return -ENOTSUPP;
+
+	if (!(sizes & BIT(size)))
+		return -EINVAL;
+
+	old = pci_rebar_get_current_size(dev, resno);
+	if (old < 0)
+		return old;
+
+	ret = pci_rebar_set_size(dev, resno, size);
+	if (ret)
+		return ret;
+
+	pci_resize_resource_set_size(dev, resno, size);
+
+	/* Check if the new config works by trying to assign everything. */
+	if (dev->bus->self) {
+		ret = pci_reassign_bridge_resources(dev->bus->self, res->flags);
+		if (ret)
+			goto error_resize;
+	}
+	return 0;
+
+error_resize:
+	pci_rebar_set_size(dev, resno, old);
+	pci_resize_resource_set_size(dev, resno, old);
+	return ret;
+}
+EXPORT_SYMBOL(pci_resize_resource);
diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
index d2b3ed51e880..20b02b74e90b 100644
--- a/drivers/pci/setup-res.c
+++ b/drivers/pci/setup-res.c
@@ -423,84 +423,6 @@ void pci_release_resource(struct pci_dev *dev, int resno)
 }
 EXPORT_SYMBOL(pci_release_resource);
 
-static bool pci_resize_is_memory_decoding_enabled(struct pci_dev *dev,
-						  int resno)
-{
-	u16 cmd;
-
-	if (pci_resource_is_iov(resno))
-		return pci_iov_is_memory_decoding_enabled(dev);
-
-	pci_read_config_word(dev, PCI_COMMAND, &cmd);
-
-	return cmd & PCI_COMMAND_MEMORY;
-}
-
-static void pci_resize_resource_set_size(struct pci_dev *dev, int resno,
-					 int size)
-{
-	resource_size_t res_size = pci_rebar_size_to_bytes(size);
-	struct resource *res = pci_resource_n(dev, resno);
-
-	if (!pci_resource_is_iov(resno)) {
-		resource_set_size(res, res_size);
-	} else {
-		resource_set_size(res, res_size * pci_sriov_get_totalvfs(dev));
-		pci_iov_resource_set_size(dev, resno, res_size);
-	}
-}
-
-int pci_resize_resource(struct pci_dev *dev, int resno, int size)
-{
-	struct resource *res = pci_resource_n(dev, resno);
-	struct pci_host_bridge *host;
-	int old, ret;
-	u32 sizes;
-
-	/* Check if we must preserve the firmware's resource assignment */
-	host = pci_find_host_bridge(dev->bus);
-	if (host->preserve_config)
-		return -ENOTSUPP;
-
-	/* Make sure the resource isn't assigned before resizing it. */
-	if (!(res->flags & IORESOURCE_UNSET))
-		return -EBUSY;
-
-	if (pci_resize_is_memory_decoding_enabled(dev, resno))
-		return -EBUSY;
-
-	sizes = pci_rebar_get_possible_sizes(dev, resno);
-	if (!sizes)
-		return -ENOTSUPP;
-
-	if (!(sizes & BIT(size)))
-		return -EINVAL;
-
-	old = pci_rebar_get_current_size(dev, resno);
-	if (old < 0)
-		return old;
-
-	ret = pci_rebar_set_size(dev, resno, size);
-	if (ret)
-		return ret;
-
-	pci_resize_resource_set_size(dev, resno, size);
-
-	/* Check if the new config works by trying to assign everything. */
-	if (dev->bus->self) {
-		ret = pci_reassign_bridge_resources(dev->bus->self, res->flags);
-		if (ret)
-			goto error_resize;
-	}
-	return 0;
-
-error_resize:
-	pci_rebar_set_size(dev, resno, old);
-	pci_resize_resource_set_size(dev, resno, old);
-	return ret;
-}
-EXPORT_SYMBOL(pci_resize_resource);
-
 int pci_enable_resources(struct pci_dev *dev, int mask)
 {
 	u16 cmd, old_cmd;
-- 
2.39.5

[PATCH v2 02/11] PCI: Cleanup pci_rebar_bytes_to_size() and move into rebar.c

[Ilpo Järvinen]

Move pci_rebar_bytes_to_size() from include/linux/pci.h into rebar.c as
it does not look very trivial and is not expected to be performance
critical.

Convert literals to use a newly added PCI_REBAR_MIN_SIZE define.

Also add kernel doc for the function as the function is exported.

Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Michael J. Ruhl <mjruhl@habana.ai>
---
 drivers/pci/rebar.c | 23 +++++++++++++++++++++++
 include/linux/pci.h | 10 +++-------
 2 files changed, 26 insertions(+), 7 deletions(-)

diff --git a/drivers/pci/rebar.c b/drivers/pci/rebar.c
index b87cfa6fb3ef..95e00d8e0c89 100644
--- a/drivers/pci/rebar.c
+++ b/drivers/pci/rebar.c
@@ -7,11 +7,34 @@
 #include <linux/errno.h>
 #include <linux/export.h>
 #include <linux/ioport.h>
+#include <linux/log2.h>
 #include <linux/pci.h>
+#include <linux/sizes.h>
 #include <linux/types.h>
 
 #include "pci.h"
 
+#define PCI_REBAR_MIN_SIZE	((resource_size_t)SZ_1M)
+
+/**
+ * pci_rebar_bytes_to_size - Convert size in bytes to PCI BAR Size
+ * @bytes: size in bytes
+ *
+ * Convert bytes to BAR Size in Resizable BAR Capability (PCIe r6.2,
+ * sec. 7.8.6.3).
+ *
+ * Return: BAR Size as defined in the PCIe spec (0=1MB, 31=128TB).
+ */
+int pci_rebar_bytes_to_size(u64 bytes)
+{
+	int rebar_minsize = ilog2(PCI_REBAR_MIN_SIZE);
+
+	bytes = roundup_pow_of_two(bytes);
+
+	return max(ilog2(bytes), rebar_minsize) - rebar_minsize;
+}
+EXPORT_SYMBOL_GPL(pci_rebar_bytes_to_size);
+
 void pci_rebar_init(struct pci_dev *pdev)
 {
 	pdev->rebar_cap = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_REBAR);
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 59876de13860..894e9020b07d 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1418,16 +1418,12 @@ void pcibios_reset_secondary_bus(struct pci_dev *dev);
 void pci_update_resource(struct pci_dev *dev, int resno);
 int __must_check pci_assign_resource(struct pci_dev *dev, int i);
 void pci_release_resource(struct pci_dev *dev, int resno);
-static inline int pci_rebar_bytes_to_size(u64 bytes)
-{
-	bytes = roundup_pow_of_two(bytes);
-
-	/* Return BAR size as defined in the resizable BAR specification */
-	return max(ilog2(bytes), 20) - 20;
-}
 
+/* Resizable BAR related routines */
+int pci_rebar_bytes_to_size(u64 bytes);
 u32 pci_rebar_get_possible_sizes(struct pci_dev *pdev, int bar);
 int __must_check pci_resize_resource(struct pci_dev *dev, int i, int size);
+
 int pci_select_bars(struct pci_dev *dev, unsigned long flags);
 bool pci_device_is_present(struct pci_dev *pdev);
 void pci_ignore_hotplug(struct pci_dev *dev);
-- 
2.39.5

[PATCH v2 03/11] PCI: Move pci_rebar_size_to_bytes() and export it

[Ilpo Järvinen]

pci_rebar_size_to_bytes() is in drivers/pci/pci.h but would be useful
for endpoint drivers as well.

Move the function into rebar.c and export it.

In addition, convert the literal to where the number comes from
(PCI_REBAR_MIN_SIZE).

Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
---
 drivers/pci/pci.h   |  4 ----
 drivers/pci/rebar.c | 12 ++++++++++++
 include/linux/pci.h |  1 +
 3 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index f1b30414b2f1..3d5068d6e195 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -929,10 +929,6 @@ void pci_rebar_init(struct pci_dev *pdev);
 void pci_restore_rebar_state(struct pci_dev *pdev);
 int pci_rebar_get_current_size(struct pci_dev *pdev, int bar);
 int pci_rebar_set_size(struct pci_dev *pdev, int bar, int size);
-static inline u64 pci_rebar_size_to_bytes(int size)
-{
-	return 1ULL << (size + 20);
-}
 
 struct device_node;
 
diff --git a/drivers/pci/rebar.c b/drivers/pci/rebar.c
index 95e00d8e0c89..0c943d9e3a08 100644
--- a/drivers/pci/rebar.c
+++ b/drivers/pci/rebar.c
@@ -35,6 +35,18 @@ int pci_rebar_bytes_to_size(u64 bytes)
 }
 EXPORT_SYMBOL_GPL(pci_rebar_bytes_to_size);
 
+/**
+ * pci_rebar_size_to_bytes - Convert BAR Size to bytes
+ * @size: BAR Size as defined in the PCIe spec (0=1MB, 31=128TB)
+ *
+ * Return: BAR size in bytes.
+ */
+resource_size_t pci_rebar_size_to_bytes(int size)
+{
+	return 1ULL << (size + ilog2(PCI_REBAR_MIN_SIZE));
+}
+EXPORT_SYMBOL_GPL(pci_rebar_size_to_bytes);
+
 void pci_rebar_init(struct pci_dev *pdev)
 {
 	pdev->rebar_cap = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_REBAR);
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 894e9020b07d..6f0c31290675 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1421,6 +1421,7 @@ void pci_release_resource(struct pci_dev *dev, int resno);
 
 /* Resizable BAR related routines */
 int pci_rebar_bytes_to_size(u64 bytes);
+resource_size_t pci_rebar_size_to_bytes(int size);
 u32 pci_rebar_get_possible_sizes(struct pci_dev *pdev, int bar);
 int __must_check pci_resize_resource(struct pci_dev *dev, int i, int size);
 
-- 
2.39.5

[PATCH v2 04/11] PCI: Improve Resizable BAR functions kernel doc

[Ilpo Järvinen]

Fix the copy-pasted errors in the Resizable BAR handling functions
kernel doc and generally improve wording choices.

Fix the formatting errors of the Return: line.

Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
---
 drivers/pci/rebar.c | 35 +++++++++++++++++++++--------------
 1 file changed, 21 insertions(+), 14 deletions(-)

diff --git a/drivers/pci/rebar.c b/drivers/pci/rebar.c
index 0c943d9e3a08..b1bd24a72bcc 100644
--- a/drivers/pci/rebar.c
+++ b/drivers/pci/rebar.c
@@ -53,13 +53,15 @@ void pci_rebar_init(struct pci_dev *pdev)
 }
 
 /**
- * pci_rebar_find_pos - find position of resize ctrl reg for BAR
+ * pci_rebar_find_pos - find position of resize control reg for BAR
  * @pdev: PCI device
  * @bar: BAR to find
  *
- * Helper to find the position of the ctrl register for a BAR.
- * Returns -ENOTSUPP if resizable BARs are not supported at all.
- * Returns -ENOENT if no ctrl register for the BAR could be found.
+ * Helper to find the position of the control register for a BAR.
+ *
+ * Return:
+ * * %-ENOTSUPP if resizable BARs are not supported at all,
+ * * %-ENOENT if no control register for the BAR could be found.
  */
 static int pci_rebar_find_pos(struct pci_dev *pdev, int bar)
 {
@@ -92,12 +94,14 @@ static int pci_rebar_find_pos(struct pci_dev *pdev, int bar)
 }
 
 /**
- * pci_rebar_get_possible_sizes - get possible sizes for BAR
+ * pci_rebar_get_possible_sizes - get possible sizes for Resizable BAR
  * @pdev: PCI device
  * @bar: BAR to query
  *
- * Get the possible sizes of a resizable BAR as bitmask defined in the spec
- * (bit 0=1MB, bit 31=128TB). Returns 0 if BAR isn't resizable.
+ * Get the possible sizes of a resizable BAR as bitmask.
+ *
+ * Return: A bitmask of possible sizes (bit 0=1MB, bit 31=128TB), or %0 if
+ *	   BAR isn't resizable.
  */
 u32 pci_rebar_get_possible_sizes(struct pci_dev *pdev, int bar)
 {
@@ -121,12 +125,14 @@ u32 pci_rebar_get_possible_sizes(struct pci_dev *pdev, int bar)
 EXPORT_SYMBOL(pci_rebar_get_possible_sizes);
 
 /**
- * pci_rebar_get_current_size - get the current size of a BAR
+ * pci_rebar_get_current_size - get the current size of a Resizable BAR
  * @pdev: PCI device
- * @bar: BAR to set size to
+ * @bar: BAR to get the size from
  *
- * Read the size of a BAR from the resizable BAR config.
- * Returns size if found or negative error code.
+ * Reads the current size of a BAR from the Resizable BAR config.
+ *
+ * Return: BAR Size if @bar is resizable (0=1MB, 31=128TB), or negative on
+ *         error.
  */
 int pci_rebar_get_current_size(struct pci_dev *pdev, int bar)
 {
@@ -142,13 +148,14 @@ int pci_rebar_get_current_size(struct pci_dev *pdev, int bar)
 }
 
 /**
- * pci_rebar_set_size - set a new size for a BAR
+ * pci_rebar_set_size - set a new size for a Resizable BAR
  * @pdev: PCI device
  * @bar: BAR to set size to
- * @size: new size as defined in the spec (0=1MB, 31=128TB)
+ * @size: new size as defined in the PCIe spec (0=1MB, 31=128TB)
  *
  * Set the new size of a BAR as defined in the spec.
- * Returns zero if resizing was successful, error code otherwise.
+ *
+ * Return: %0 if resizing was successful, or negative on error.
  */
 int pci_rebar_set_size(struct pci_dev *pdev, int bar, int size)
 {
-- 
2.39.5

[PATCH v2 05/11] PCI: Add pci_rebar_size_supported() helper

[Ilpo Järvinen]

Many callers of pci_rebar_get_possible_sizes() are interested in
finding out if a particular BAR Size (PCIe r6.2 sec. 7.8.6.3) is
supported by the particular BAR.

Add pci_rebar_size_supported() into PCI core to make it easy for the
drivers to determine if the BAR Size is supported or not.

Use the new function in pci_resize_resource() and in
pci_iov_vf_bar_set_size().

Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
---
 drivers/pci/iov.c   |  7 +------
 drivers/pci/rebar.c | 25 +++++++++++++++++++------
 include/linux/pci.h |  1 +
 3 files changed, 21 insertions(+), 12 deletions(-)

diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c
index ac4375954c94..51844a9176a0 100644
--- a/drivers/pci/iov.c
+++ b/drivers/pci/iov.c
@@ -1334,7 +1334,6 @@ EXPORT_SYMBOL_GPL(pci_sriov_configure_simple);
  */
 int pci_iov_vf_bar_set_size(struct pci_dev *dev, int resno, int size)
 {
-	u32 sizes;
 	int ret;
 
 	if (!pci_resource_is_iov(resno))
@@ -1343,11 +1342,7 @@ int pci_iov_vf_bar_set_size(struct pci_dev *dev, int resno, int size)
 	if (pci_iov_is_memory_decoding_enabled(dev))
 		return -EBUSY;
 
-	sizes = pci_rebar_get_possible_sizes(dev, resno);
-	if (!sizes)
-		return -ENOTSUPP;
-
-	if (!(sizes & BIT(size)))
+	if (!pci_rebar_size_supported(dev, resno, size))
 		return -EINVAL;
 
 	ret = pci_rebar_set_size(dev, resno, size);
diff --git a/drivers/pci/rebar.c b/drivers/pci/rebar.c
index b1bd24a72bcc..81e01cbadde7 100644
--- a/drivers/pci/rebar.c
+++ b/drivers/pci/rebar.c
@@ -3,6 +3,7 @@
  * PCI Resizable BAR Extended Capability handling.
  */
 
+#include <linux/bits.h>
 #include <linux/bitfield.h>
 #include <linux/errno.h>
 #include <linux/export.h>
@@ -124,6 +125,23 @@ u32 pci_rebar_get_possible_sizes(struct pci_dev *pdev, int bar)
 }
 EXPORT_SYMBOL(pci_rebar_get_possible_sizes);
 
+/**
+ * pci_rebar_size_supported - check if size is supported for BAR
+ * @pdev: PCI device
+ * @bar: BAR to check
+ * @size: size as defined in the PCIe spec (0=1MB, 31=128TB)
+ *
+ * Return: %true if @bar is resizable and @size is a supported, otherwise
+ *	   %false.
+ */
+bool pci_rebar_size_supported(struct pci_dev *pdev, int bar, int size)
+{
+	u64 sizes = pci_rebar_get_possible_sizes(pdev, bar);
+
+	return BIT(size) & sizes;
+}
+EXPORT_SYMBOL_GPL(pci_rebar_size_supported);
+
 /**
  * pci_rebar_get_current_size - get the current size of a Resizable BAR
  * @pdev: PCI device
@@ -231,7 +249,6 @@ int pci_resize_resource(struct pci_dev *dev, int resno, int size)
 	struct resource *res = pci_resource_n(dev, resno);
 	struct pci_host_bridge *host;
 	int old, ret;
-	u32 sizes;
 
 	/* Check if we must preserve the firmware's resource assignment */
 	host = pci_find_host_bridge(dev->bus);
@@ -245,11 +262,7 @@ int pci_resize_resource(struct pci_dev *dev, int resno, int size)
 	if (pci_resize_is_memory_decoding_enabled(dev, resno))
 		return -EBUSY;
 
-	sizes = pci_rebar_get_possible_sizes(dev, resno);
-	if (!sizes)
-		return -ENOTSUPP;
-
-	if (!(sizes & BIT(size)))
+	if (!pci_rebar_size_supported(dev, resno, size))
 		return -EINVAL;
 
 	old = pci_rebar_get_current_size(dev, resno);
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 6f0c31290675..917c3b897739 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1423,6 +1423,7 @@ void pci_release_resource(struct pci_dev *dev, int resno);
 int pci_rebar_bytes_to_size(u64 bytes);
 resource_size_t pci_rebar_size_to_bytes(int size);
 u32 pci_rebar_get_possible_sizes(struct pci_dev *pdev, int bar);
+bool pci_rebar_size_supported(struct pci_dev *pdev, int bar, int size);
 int __must_check pci_resize_resource(struct pci_dev *dev, int i, int size);
 
 int pci_select_bars(struct pci_dev *dev, unsigned long flags);
-- 
2.39.5

[PATCH v2 06/11] drm/i915/gt: Use pci_rebar_size_supported()

[Ilpo Järvinen]

PCI core provides pci_rebar_size_supported() that helps in checking if
a BAR Size is supported for the BAR or not. Use it in
i915_resize_lmem_bar() to simplify code.

Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Acked-by: Christian König <christian.koenig@amd.com>
---
 drivers/gpu/drm/i915/gt/intel_region_lmem.c | 10 +++-------
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_region_lmem.c b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
index 51bb27e10a4f..69c65fc8a72d 100644
--- a/drivers/gpu/drm/i915/gt/intel_region_lmem.c
+++ b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
@@ -61,16 +61,12 @@ static void i915_resize_lmem_bar(struct drm_i915_private *i915, resource_size_t
 	current_size = roundup_pow_of_two(pci_resource_len(pdev, GEN12_LMEM_BAR));
 
 	if (i915->params.lmem_bar_size) {
-		u32 bar_sizes;
-
-		rebar_size = i915->params.lmem_bar_size *
-			(resource_size_t)SZ_1M;
-		bar_sizes = pci_rebar_get_possible_sizes(pdev, GEN12_LMEM_BAR);
-
+		rebar_size = i915->params.lmem_bar_size * (resource_size_t)SZ_1M;
 		if (rebar_size == current_size)
 			return;
 
-		if (!(bar_sizes & BIT(pci_rebar_bytes_to_size(rebar_size))) ||
+		if (!pci_rebar_size_supported(pdev, GEN12_LMEM_BAR,
+					      pci_rebar_bytes_to_size(rebar_size)) ||
 		    rebar_size >= roundup_pow_of_two(lmem_size)) {
 			rebar_size = lmem_size;
 
-- 
2.39.5

[PATCH v2 07/11] drm/xe/vram: Use PCI rebar helpers in resize_vram_bar()

[Ilpo Järvinen]

PCI core provides pci_rebar_size_supported() and
pci_rebar_size_to_bytes(), use them in resize_vram_bar() to simplify
code.

Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Acked-by: Christian König <christian.koenig@amd.com>
---
 drivers/gpu/drm/xe/xe_vram.c | 19 +++++++------------
 1 file changed, 7 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/xe/xe_vram.c b/drivers/gpu/drm/xe/xe_vram.c
index 0b7417bb0a47..d4fbd7f74255 100644
--- a/drivers/gpu/drm/xe/xe_vram.c
+++ b/drivers/gpu/drm/xe/xe_vram.c
@@ -22,8 +22,6 @@
 #include "xe_vram.h"
 #include "xe_vram_types.h"
 
-#define BAR_SIZE_SHIFT 20
-
 static void
 _resize_bar(struct xe_device *xe, int resno, resource_size_t size)
 {
@@ -72,25 +70,22 @@ static void resize_vram_bar(struct xe_device *xe)
 
 	/* set to a specific size? */
 	if (force_vram_bar_size) {
-		u32 bar_size_bit;
-
-		rebar_size = force_vram_bar_size * (resource_size_t)SZ_1M;
+		rebar_size = pci_rebar_bytes_to_size(force_vram_bar_size *
+						     (resource_size_t)SZ_1M);
 
-		bar_size_bit = bar_size_mask & BIT(pci_rebar_bytes_to_size(rebar_size));
-
-		if (!bar_size_bit) {
+		if (!pci_rebar_size_supported(pdev, LMEM_BAR, rebar_size)) {
 			drm_info(&xe->drm,
 				 "Requested size: %lluMiB is not supported by rebar sizes: 0x%x. Leaving default: %lluMiB\n",
-				 (u64)rebar_size >> 20, bar_size_mask, (u64)current_size >> 20);
+				 (u64)pci_rebar_size_to_bytes(rebar_size) >> 20,
+				 bar_size_mask, (u64)current_size >> 20);
 			return;
 		}
 
-		rebar_size = 1ULL << (__fls(bar_size_bit) + BAR_SIZE_SHIFT);
-
+		rebar_size = pci_rebar_size_to_bytes(rebar_size);
 		if (rebar_size == current_size)
 			return;
 	} else {
-		rebar_size = 1ULL << (__fls(bar_size_mask) + BAR_SIZE_SHIFT);
+		rebar_size = pci_rebar_size_to_bytes(__fls(bar_size_mask));
 
 		/* only resize if larger than current */
 		if (rebar_size <= current_size)
-- 
2.39.5

[PATCH v2 08/11] PCI: Add pci_rebar_get_max_size()

[Ilpo Järvinen]

Add pci_rebar_get_max_size() into PCI core to allow simplifying code
that wants to know the maximum possible size for a Resizable BAR.

Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
---
 drivers/pci/rebar.c | 23 +++++++++++++++++++++++
 include/linux/pci.h |  1 +
 2 files changed, 24 insertions(+)

diff --git a/drivers/pci/rebar.c b/drivers/pci/rebar.c
index 81e01cbadde7..27185892ada4 100644
--- a/drivers/pci/rebar.c
+++ b/drivers/pci/rebar.c
@@ -5,6 +5,7 @@
 
 #include <linux/bits.h>
 #include <linux/bitfield.h>
+#include <linux/bitops.h>
 #include <linux/errno.h>
 #include <linux/export.h>
 #include <linux/ioport.h>
@@ -142,6 +143,28 @@ bool pci_rebar_size_supported(struct pci_dev *pdev, int bar, int size)
 }
 EXPORT_SYMBOL_GPL(pci_rebar_size_supported);
 
+/**
+ * pci_rebar_get_max_size - get the maximum supported size of a BAR
+ * @pdev: PCI device
+ * @bar: BAR to query
+ *
+ * Get the largest supported size of a resizable BAR as a size.
+ *
+ * Returns: the maximum BAR size as defined in the PCIe spec (0=1MB, 31=128TB),
+ *	     or %-NOENT on error.
+ */
+int pci_rebar_get_max_size(struct pci_dev *pdev, int bar)
+{
+	u32 sizes;
+
+	sizes = pci_rebar_get_possible_sizes(pdev, bar);
+	if (!sizes)
+		return -ENOENT;
+
+	return __fls(sizes);
+}
+EXPORT_SYMBOL_GPL(pci_rebar_get_max_size);
+
 /**
  * pci_rebar_get_current_size - get the current size of a Resizable BAR
  * @pdev: PCI device
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 917c3b897739..a4236aafad24 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1424,6 +1424,7 @@ int pci_rebar_bytes_to_size(u64 bytes);
 resource_size_t pci_rebar_size_to_bytes(int size);
 u32 pci_rebar_get_possible_sizes(struct pci_dev *pdev, int bar);
 bool pci_rebar_size_supported(struct pci_dev *pdev, int bar, int size);
+int pci_rebar_get_max_size(struct pci_dev *pdev, int bar);
 int __must_check pci_resize_resource(struct pci_dev *dev, int i, int size);
 
 int pci_select_bars(struct pci_dev *dev, unsigned long flags);
-- 
2.39.5

[PATCH v2 09/11] drm/xe/vram: Use pci_rebar_get_max_size()

[Ilpo Järvinen]

Use pci_rebar_get_max_size() from PCI core in resize_vram_bar() to
simplify code.

Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Acked-by: Christian König <christian.koenig@amd.com>
---
 drivers/gpu/drm/xe/xe_vram.c | 15 +++++++--------
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/xe/xe_vram.c b/drivers/gpu/drm/xe/xe_vram.c
index d4fbd7f74255..ca02744fb369 100644
--- a/drivers/gpu/drm/xe/xe_vram.c
+++ b/drivers/gpu/drm/xe/xe_vram.c
@@ -54,16 +54,11 @@ static void resize_vram_bar(struct xe_device *xe)
 	resource_size_t current_size;
 	resource_size_t rebar_size;
 	struct resource *root_res;
-	u32 bar_size_mask;
+	int max_size, i;
 	u32 pci_cmd;
-	int i;
 
 	/* gather some relevant info */
 	current_size = pci_resource_len(pdev, LMEM_BAR);
-	bar_size_mask = pci_rebar_get_possible_sizes(pdev, LMEM_BAR);
-
-	if (!bar_size_mask)
-		return;
 
 	if (force_vram_bar_size < 0)
 		return;
@@ -77,7 +72,8 @@ static void resize_vram_bar(struct xe_device *xe)
 			drm_info(&xe->drm,
 				 "Requested size: %lluMiB is not supported by rebar sizes: 0x%x. Leaving default: %lluMiB\n",
 				 (u64)pci_rebar_size_to_bytes(rebar_size) >> 20,
-				 bar_size_mask, (u64)current_size >> 20);
+				 pci_rebar_get_possible_sizes(pdev, LMEM_BAR),
+				 (u64)current_size >> 20);
 			return;
 		}
 
@@ -85,7 +81,10 @@ static void resize_vram_bar(struct xe_device *xe)
 		if (rebar_size == current_size)
 			return;
 	} else {
-		rebar_size = pci_rebar_size_to_bytes(__fls(bar_size_mask));
+		max_size = pci_rebar_get_max_size(pdev, LMEM_BAR);
+		if (max_size < 0)
+			return;
+		rebar_size = pci_rebar_size_to_bytes(max_size);
 
 		/* only resize if larger than current */
 		if (rebar_size <= current_size)
-- 
2.39.5

[PATCH v2 10/11] drm/amdgpu: Use pci_rebar_get_max_size()

[Ilpo Järvinen]

Use pci_rebar_get_max_size() from PCI core to simplify code in
amdgpu_device_resize_fb_bar().

Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 01d234cf8156..c4ab503fb5d0 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -1670,9 +1670,9 @@ int amdgpu_device_resize_fb_bar(struct amdgpu_device *adev)
 	int rbar_size = pci_rebar_bytes_to_size(adev->gmc.real_vram_size);
 	struct pci_bus *root;
 	struct resource *res;
+	int max_size, r;
 	unsigned int i;
 	u16 cmd;
-	int r;
 
 	if (!IS_ENABLED(CONFIG_PHYS_ADDR_T_64BIT))
 		return 0;
@@ -1718,8 +1718,10 @@ int amdgpu_device_resize_fb_bar(struct amdgpu_device *adev)
 		return 0;
 
 	/* Limit the BAR size to what is available */
-	rbar_size = min(fls(pci_rebar_get_possible_sizes(adev->pdev, 0)) - 1,
-			rbar_size);
+	max_size = pci_rebar_get_max_size(adev->pdev, 0);
+	if (max_size < 0)
+		return 0;
+	rbar_size = min(max_size, rbar_size);
 
 	/* Disable memory decoding while we change the BAR addresses and size */
 	pci_read_config_word(adev->pdev, PCI_COMMAND, &cmd);
-- 
2.39.5

[PATCH v2 11/11] PCI: Convert BAR sizes bitmasks to u64

[Ilpo Järvinen]

PCIe r6.2 section 7.8.6 defines resizable BAR sizes beyond the
currently supported maximum of 128TB which will require more than u32
to store the entire bitmask.

Convert Resizable BAR related functions to use u64 bitmask for BAR
sizes to make the typing more future-proof.

The support for the larger BAR sizes themselves is not added at this
point.

Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
---
 drivers/gpu/drm/xe/xe_vram.c | 2 +-
 drivers/pci/iov.c            | 2 +-
 drivers/pci/pci-sysfs.c      | 2 +-
 drivers/pci/rebar.c          | 4 ++--
 include/linux/pci.h          | 2 +-
 5 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/xe/xe_vram.c b/drivers/gpu/drm/xe/xe_vram.c
index ca02744fb369..22b998727eb2 100644
--- a/drivers/gpu/drm/xe/xe_vram.c
+++ b/drivers/gpu/drm/xe/xe_vram.c
@@ -70,7 +70,7 @@ static void resize_vram_bar(struct xe_device *xe)
 
 		if (!pci_rebar_size_supported(pdev, LMEM_BAR, rebar_size)) {
 			drm_info(&xe->drm,
-				 "Requested size: %lluMiB is not supported by rebar sizes: 0x%x. Leaving default: %lluMiB\n",
+				 "Requested size: %lluMiB is not supported by rebar sizes: 0x%llx. Leaving default: %lluMiB\n",
 				 (u64)pci_rebar_size_to_bytes(rebar_size) >> 20,
 				 pci_rebar_get_possible_sizes(pdev, LMEM_BAR),
 				 (u64)current_size >> 20);
diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c
index 51844a9176a0..d2741c4f3315 100644
--- a/drivers/pci/iov.c
+++ b/drivers/pci/iov.c
@@ -1370,7 +1370,7 @@ EXPORT_SYMBOL_GPL(pci_iov_vf_bar_set_size);
 u32 pci_iov_vf_bar_get_sizes(struct pci_dev *dev, int resno, int num_vfs)
 {
 	u64 vf_len = pci_resource_len(dev, resno);
-	u32 sizes;
+	u64 sizes;
 
 	if (!num_vfs)
 		return 0;
diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index 5eea14c1f7f5..b6920114d538 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -1544,7 +1544,7 @@ static ssize_t __resource_resize_show(struct device *dev, int n, char *buf)
 	pci_config_pm_runtime_get(pdev);
 
 	ret = sysfs_emit(buf, "%016llx\n",
-			 (u64)pci_rebar_get_possible_sizes(pdev, n));
+			 pci_rebar_get_possible_sizes(pdev, n));
 
 	pci_config_pm_runtime_put(pdev);
 
diff --git a/drivers/pci/rebar.c b/drivers/pci/rebar.c
index 27185892ada4..ea8620e4bc18 100644
--- a/drivers/pci/rebar.c
+++ b/drivers/pci/rebar.c
@@ -105,7 +105,7 @@ static int pci_rebar_find_pos(struct pci_dev *pdev, int bar)
  * Return: A bitmask of possible sizes (bit 0=1MB, bit 31=128TB), or %0 if
  *	   BAR isn't resizable.
  */
-u32 pci_rebar_get_possible_sizes(struct pci_dev *pdev, int bar)
+u64 pci_rebar_get_possible_sizes(struct pci_dev *pdev, int bar)
 {
 	int pos;
 	u32 cap;
@@ -155,7 +155,7 @@ EXPORT_SYMBOL_GPL(pci_rebar_size_supported);
  */
 int pci_rebar_get_max_size(struct pci_dev *pdev, int bar)
 {
-	u32 sizes;
+	u64 sizes;
 
 	sizes = pci_rebar_get_possible_sizes(pdev, bar);
 	if (!sizes)
diff --git a/include/linux/pci.h b/include/linux/pci.h
index a4236aafad24..bb10c7eb49e2 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1422,7 +1422,7 @@ void pci_release_resource(struct pci_dev *dev, int resno);
 /* Resizable BAR related routines */
 int pci_rebar_bytes_to_size(u64 bytes);
 resource_size_t pci_rebar_size_to_bytes(int size);
-u32 pci_rebar_get_possible_sizes(struct pci_dev *pdev, int bar);
+u64 pci_rebar_get_possible_sizes(struct pci_dev *pdev, int bar);
 bool pci_rebar_size_supported(struct pci_dev *pdev, int bar, int size);
 int pci_rebar_get_max_size(struct pci_dev *pdev, int bar);
 int __must_check pci_resize_resource(struct pci_dev *dev, int i, int size);
-- 
2.39.5

Re: [PATCH v2 06/11] drm/i915/gt: Use pci_rebar_size_supported()

[Jani Nikula]

On Mon, 15 Sep 2025, Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> wrote:
> PCI core provides pci_rebar_size_supported() that helps in checking if
> a BAR Size is supported for the BAR or not. Use it in
> i915_resize_lmem_bar() to simplify code.
>
> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
> Acked-by: Christian König <christian.koenig@amd.com>

Reviewed-by: Jani Nikula <jani.nikula@intel.com>

and

Acked-by: Jani Nikula <jani.nikula@intel.com>

for merging via whichever tree is convenient.

> ---
>  drivers/gpu/drm/i915/gt/intel_region_lmem.c | 10 +++-------
>  1 file changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_region_lmem.c b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
> index 51bb27e10a4f..69c65fc8a72d 100644
> --- a/drivers/gpu/drm/i915/gt/intel_region_lmem.c
> +++ b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
> @@ -61,16 +61,12 @@ static void i915_resize_lmem_bar(struct drm_i915_private *i915, resource_size_t
>  	current_size = roundup_pow_of_two(pci_resource_len(pdev, GEN12_LMEM_BAR));
>  
>  	if (i915->params.lmem_bar_size) {
> -		u32 bar_sizes;
> -
> -		rebar_size = i915->params.lmem_bar_size *
> -			(resource_size_t)SZ_1M;
> -		bar_sizes = pci_rebar_get_possible_sizes(pdev, GEN12_LMEM_BAR);
> -
> +		rebar_size = i915->params.lmem_bar_size * (resource_size_t)SZ_1M;
>  		if (rebar_size == current_size)
>  			return;
>  
> -		if (!(bar_sizes & BIT(pci_rebar_bytes_to_size(rebar_size))) ||
> +		if (!pci_rebar_size_supported(pdev, GEN12_LMEM_BAR,
> +					      pci_rebar_bytes_to_size(rebar_size)) ||
>  		    rebar_size >= roundup_pow_of_two(lmem_size)) {
>  			rebar_size = lmem_size;

-- 
Jani Nikula, Intel

Re: [PATCH v2 00/11] PCI: Resizable BAR improvements

[Lucas De Marchi]

On Mon, Sep 15, 2025 at 12:13:47PM +0300, Ilpo Järvinen wrote:
>pci.c has been used as catch everything that doesn't fits elsewhere
>within PCI core and thus resizable BAR code has been placed there as
>well. Move Resizable BAR related code to a newly introduced rebar.c to
>reduce size of pci.c. After move, there are no pci_rebar_*() calls from
>pci.c indicating this is indeed well-defined subset of PCI core.
>
>Endpoint drivers perform Resizable BAR related operations which could
>well be performed by PCI core to simplify driver-side code. This
>series adds a few new API functions to that effect and converts the
>drivers to use the new APIs (in separate patches).
>
>While at it, also convert BAR sizes bitmask to u64 as PCIe spec already
>specifies more sizes than what will fit u32 to make the API typing more
>future-proof. The extra sizes beyond 128TB are not added at this point.
>
>These are based on pci/main plus a simple "adapter" patch to add the
>include for xe_vram_types.h that was added by a commit in drm-tip.
>Hopefully that is enough to avoid the within context conflict with
>BAR_SIZE_SHIFT removal to let the xe CI tests to be run for this
>series.
>
>There are two minor conflicts with the work in pci/resource but I'm
>hesitant to base this on top of it as this is otherwise entirely
>independent (and would likely prevent GPU CI tests as well). If we end
>up having to pull the bridge window select changes, there should be no
>reason why this does have to become collateral damage (so my
>suggestion, if this is good to go in this cycle, to take this into a
>separate branch than pci/resource and deal with those small conflicts
>while merging into pci/next).
>
>I've tested sysfs resize, i915, and xe BAR resizing functionality. In
>the case of xe, I did small hack patch as its resize is anyway broken
>as is because BAR0 pins the bridge window so resizing BAR2 fails. My
>hack caused other problems further down the road (likely because BAR0
>is in use by the driver so releasing it messed assumptions xe driver
>has) but the BAR resize itself was working which was all I was

is the hack you mention here to release all BARs before attempting the
resize?

>interested to know. I'm not planning to pursue fixing the pinning
>problem within xe driver because the core changes to consider maximum
>size of the resizable BARs should take care of the main problem by
>different means.

I'd actually like to pursue that myself as that could be propagated to
stable since we do have some resize errors in xe with BMG that I wasn't
understanding. It's likely due to xe_mmio_probe_early() taking a hold of
BAR0 and not expecting it to be moved. We could either remap if we have
have to resize or just move the resize logic early on.

thanks
Lucas De Marchi

>
>Some parts of this are to be used by the resizable BAR changes into the
>resource fitting/assingment logic but these seem to stand on their own
>so sending these out now to reduce the size of the other patch series.
>
>v2:
>- Kerneldoc:
>  - Improve formatting of errno returns
>  - Open "ctrl" -> "control"
>  - Removed mislead "bit" words (when referring to BAR size)
>  - Rewrote pci_rebar_get_possible_sizes() kernel doc to not claim the
>    returned bitmask is defined in PCIe spec as the capability bits now
>    span across two registers in the spec and are not continuous (we
>    don't support the second block of bits yet, but this API is expected
>    to return the bits without the hole so it will not be matching with
>    the spec layout).
>- Dropped superfluous zero check from pci_rebar_size_supported()
>- Small improvement to changelog of patch 7
>
>Ilpo Järvinen (11):
>  PCI: Move Resizable BAR code into rebar.c
>  PCI: Cleanup pci_rebar_bytes_to_size() and move into rebar.c
>  PCI: Move pci_rebar_size_to_bytes() and export it
>  PCI: Improve Resizable BAR functions kernel doc
>  PCI: Add pci_rebar_size_supported() helper
>  drm/i915/gt: Use pci_rebar_size_supported()
>  drm/xe/vram: Use PCI rebar helpers in resize_vram_bar()
>  PCI: Add pci_rebar_get_max_size()
>  drm/xe/vram: Use pci_rebar_get_max_size()
>  drm/amdgpu: Use pci_rebar_get_max_size()
>  PCI: Convert BAR sizes bitmasks to u64
>
> Documentation/driver-api/pci/pci.rst        |   3 +
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c  |   8 +-
> drivers/gpu/drm/i915/gt/intel_region_lmem.c |  10 +-
> drivers/gpu/drm/xe/xe_vram.c                |  32 +-
> drivers/pci/Makefile                        |   2 +-
> drivers/pci/iov.c                           |   9 +-
> drivers/pci/pci-sysfs.c                     |   2 +-
> drivers/pci/pci.c                           | 145 ---------
> drivers/pci/pci.h                           |   5 +-
> drivers/pci/rebar.c                         | 314 ++++++++++++++++++++
> drivers/pci/setup-res.c                     |  78 -----
> include/linux/pci.h                         |  15 +-
> 12 files changed, 350 insertions(+), 273 deletions(-)
> create mode 100644 drivers/pci/rebar.c
>
>
>base-commit: 8f5ae30d69d7543eee0d70083daf4de8fe15d585
>prerequisite-patch-id: 35bd3cd7a60ff7d887450a7fdde73b055a76ae24
>-- 
>2.39.5
>

Re: [PATCH v2 06/11] drm/i915/gt: Use pci_rebar_size_supported()

[Andi Shyti]

Hi Ilpo,

On Mon, Sep 15, 2025 at 12:13:53PM +0300, Ilpo Järvinen wrote:
> PCI core provides pci_rebar_size_supported() that helps in checking if
> a BAR Size is supported for the BAR or not. Use it in
> i915_resize_lmem_bar() to simplify code.
> 
> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
> Acked-by: Christian König <christian.koenig@amd.com>

Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>

Thanks,
Andi

Re: [PATCH v2 00/11] PCI: Resizable BAR improvements

[Ilpo Järvinen]

[-- Attachment #1: Type: text/plain, Size: 6874 bytes --]

On Mon, 15 Sep 2025, Lucas De Marchi wrote:

> On Mon, Sep 15, 2025 at 12:13:47PM +0300, Ilpo Järvinen wrote:
> > pci.c has been used as catch everything that doesn't fits elsewhere
> > within PCI core and thus resizable BAR code has been placed there as
> > well. Move Resizable BAR related code to a newly introduced rebar.c to
> > reduce size of pci.c. After move, there are no pci_rebar_*() calls from
> > pci.c indicating this is indeed well-defined subset of PCI core.
> > 
> > Endpoint drivers perform Resizable BAR related operations which could
> > well be performed by PCI core to simplify driver-side code. This
> > series adds a few new API functions to that effect and converts the
> > drivers to use the new APIs (in separate patches).
> > 
> > While at it, also convert BAR sizes bitmask to u64 as PCIe spec already
> > specifies more sizes than what will fit u32 to make the API typing more
> > future-proof. The extra sizes beyond 128TB are not added at this point.
> > 
> > These are based on pci/main plus a simple "adapter" patch to add the
> > include for xe_vram_types.h that was added by a commit in drm-tip.
> > Hopefully that is enough to avoid the within context conflict with
> > BAR_SIZE_SHIFT removal to let the xe CI tests to be run for this
> > series.
> > 
> > There are two minor conflicts with the work in pci/resource but I'm
> > hesitant to base this on top of it as this is otherwise entirely
> > independent (and would likely prevent GPU CI tests as well). If we end
> > up having to pull the bridge window select changes, there should be no
> > reason why this does have to become collateral damage (so my
> > suggestion, if this is good to go in this cycle, to take this into a
> > separate branch than pci/resource and deal with those small conflicts
> > while merging into pci/next).
> > 
> > I've tested sysfs resize, i915, and xe BAR resizing functionality. In
> > the case of xe, I did small hack patch as its resize is anyway broken
> > as is because BAR0 pins the bridge window so resizing BAR2 fails. My
> > hack caused other problems further down the road (likely because BAR0
> > is in use by the driver so releasing it messed assumptions xe driver
> > has) but the BAR resize itself was working which was all I was
> 
> is the hack you mention here to release all BARs before attempting the
> resize?

Yes, the patch added release of BAR0 prior to resize. The existing xe code 
in _resize_bar() already releases BAR2.

During resize, if the first loop in pbus_reassign_bridge_resources() 
(called from pci_resize_resource()) finds the bridge window closest to the 
endpoint still has a child, it results in having empty saved list because 
all upstream bridge windows will then have a child as well.

Empty saved list is checked after the loop and 
pbus_reassign_bridge_resources() returns -ENOENT without even trying to 
assign the resources. The error is returned even if the actual bridge 
window size is large enough to fit the resized resource.

The logic in pci_resize_resource() and pbus_reassign_bridge_resources() 
need some other improvements besides that problem, but I likely won't 
have time to look at that until completing the fitting algorithm changes.
I'd actually want to add pci_release_and_resize_resource() which would
take care of releasing all the resources of the device (obviously driver 
must have its hands off all those BARs when it calls that function). With 
the current pci_resize_resource() API, handling the restore of BARs in 
case of failure is not as robust as I'd like to make it.

> > interested to know. I'm not planning to pursue fixing the pinning
> > problem within xe driver because the core changes to consider maximum
> > size of the resizable BARs should take care of the main problem by
> > different means.
> 
> I'd actually like to pursue that myself as that could be propagated to
> stable since we do have some resize errors in xe with BMG that I wasn't
> understanding. It's likely due to xe_mmio_probe_early() taking a hold of
> BAR0 and not expecting it to be moved. We could either remap if we have
> have to resize or just move the resize logic early on.

Great. If you have any questions when it comes to the PCI core side code, 
please let me know.

-- 
 i.

> > Some parts of this are to be used by the resizable BAR changes into the
> > resource fitting/assingment logic but these seem to stand on their own
> > so sending these out now to reduce the size of the other patch series.
> > 
> > v2:
> > - Kerneldoc:
> >  - Improve formatting of errno returns
> >  - Open "ctrl" -> "control"
> >  - Removed mislead "bit" words (when referring to BAR size)
> >  - Rewrote pci_rebar_get_possible_sizes() kernel doc to not claim the
> >    returned bitmask is defined in PCIe spec as the capability bits now
> >    span across two registers in the spec and are not continuous (we
> >    don't support the second block of bits yet, but this API is expected
> >    to return the bits without the hole so it will not be matching with
> >    the spec layout).
> > - Dropped superfluous zero check from pci_rebar_size_supported()
> > - Small improvement to changelog of patch 7
> > 
> > Ilpo Järvinen (11):
> >  PCI: Move Resizable BAR code into rebar.c
> >  PCI: Cleanup pci_rebar_bytes_to_size() and move into rebar.c
> >  PCI: Move pci_rebar_size_to_bytes() and export it
> >  PCI: Improve Resizable BAR functions kernel doc
> >  PCI: Add pci_rebar_size_supported() helper
> >  drm/i915/gt: Use pci_rebar_size_supported()
> >  drm/xe/vram: Use PCI rebar helpers in resize_vram_bar()
> >  PCI: Add pci_rebar_get_max_size()
> >  drm/xe/vram: Use pci_rebar_get_max_size()
> >  drm/amdgpu: Use pci_rebar_get_max_size()
> >  PCI: Convert BAR sizes bitmasks to u64
> > 
> > Documentation/driver-api/pci/pci.rst        |   3 +
> > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c  |   8 +-
> > drivers/gpu/drm/i915/gt/intel_region_lmem.c |  10 +-
> > drivers/gpu/drm/xe/xe_vram.c                |  32 +-
> > drivers/pci/Makefile                        |   2 +-
> > drivers/pci/iov.c                           |   9 +-
> > drivers/pci/pci-sysfs.c                     |   2 +-
> > drivers/pci/pci.c                           | 145 ---------
> > drivers/pci/pci.h                           |   5 +-
> > drivers/pci/rebar.c                         | 314 ++++++++++++++++++++
> > drivers/pci/setup-res.c                     |  78 -----
> > include/linux/pci.h                         |  15 +-
> > 12 files changed, 350 insertions(+), 273 deletions(-)
> > create mode 100644 drivers/pci/rebar.c
> > 
> > 
> > base-commit: 8f5ae30d69d7543eee0d70083daf4de8fe15d585
> > prerequisite-patch-id: 35bd3cd7a60ff7d887450a7fdde73b055a76ae24
> > -- 
> > 2.39.5
> > 
> 

Re: [PATCH v2 06/11] drm/i915/gt: Use pci_rebar_size_supported()

[Andi Shyti]

Hi,

On Mon, Sep 15, 2025 at 03:42:23PM +0300, Jani Nikula wrote:
> On Mon, 15 Sep 2025, Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> wrote:
> > PCI core provides pci_rebar_size_supported() that helps in checking if
> > a BAR Size is supported for the BAR or not. Use it in
> > i915_resize_lmem_bar() to simplify code.
> >
> > Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
> > Acked-by: Christian König <christian.koenig@amd.com>
> 
> Reviewed-by: Jani Nikula <jani.nikula@intel.com>
> 
> and
> 
> Acked-by: Jani Nikula <jani.nikula@intel.com>

Just for some random noise on commit log's bureaucracy: why do we
need both Ack and R-b? I think R-b covers Ack making it
redundant. Right?

Andi

Re: [PATCH v2 05/11] PCI: Add pci_rebar_size_supported() helper

[Andi Shyti]

Hi Ilpo,

> +/**
> + * pci_rebar_size_supported - check if size is supported for BAR
> + * @pdev: PCI device
> + * @bar: BAR to check
> + * @size: size as defined in the PCIe spec (0=1MB, 31=128TB)
> + *
> + * Return: %true if @bar is resizable and @size is a supported, otherwise
> + *	   %false.
> + */
> +bool pci_rebar_size_supported(struct pci_dev *pdev, int bar, int size)
> +{
> +	u64 sizes = pci_rebar_get_possible_sizes(pdev, bar);
> +
> +	return BIT(size) & sizes;

I would return here "!!(BIT(size) & sizes)", but it doesn't
really matter.

Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>

Andi

Re: [PATCH v2 06/11] drm/i915/gt: Use pci_rebar_size_supported()

[Rodrigo Vivi]

On Mon, Sep 15, 2025 at 07:24:10PM +0200, Andi Shyti wrote:
> Hi,
> 
> On Mon, Sep 15, 2025 at 03:42:23PM +0300, Jani Nikula wrote:
> > On Mon, 15 Sep 2025, Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> wrote:
> > > PCI core provides pci_rebar_size_supported() that helps in checking if
> > > a BAR Size is supported for the BAR or not. Use it in
> > > i915_resize_lmem_bar() to simplify code.
> > >
> > > Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
> > > Acked-by: Christian König <christian.koenig@amd.com>
> > 
> > Reviewed-by: Jani Nikula <jani.nikula@intel.com>
> > 
> > and
> > 
> > Acked-by: Jani Nikula <jani.nikula@intel.com>
> 
> Just for some random noise on commit log's bureaucracy: why do we
> need both Ack and R-b? I think R-b covers Ack making it
> redundant. Right?

reviewed-by is a more formal attestation of the entries in the
submitting-patches doc, saying that he carefully reviewed the work.

acked by is to state that from the maintainer perspective of that file
the file can be merged through any tree.

in the drm trees nowdays our tooling is enforcing acked-by tag if
the patch is touching domains outside that drm branch itself.

if a committer tries to push a patch without ack from the maintainer
of that domain it will be blocked.

So I believe it is a good idea to keep a separation of the meaning.
Carrying a technical review of the patch in question doesn't necessarily
mean that you, as maintainer, is okay of getting that patch merged
through other trees.

> 
> Andi

Re: [PATCH v2 09/11] drm/xe/vram: Use pci_rebar_get_max_size()

[Rodrigo Vivi]

On Mon, Sep 15, 2025 at 12:13:56PM +0300, Ilpo Järvinen wrote:
> Use pci_rebar_get_max_size() from PCI core in resize_vram_bar() to
> simplify code.
> 
> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
> Acked-by: Christian König <christian.koenig@amd.com>
> ---
>  drivers/gpu/drm/xe/xe_vram.c | 15 +++++++--------


Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

to get this patch merged through any other tree

>  1 file changed, 7 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/xe/xe_vram.c b/drivers/gpu/drm/xe/xe_vram.c
> index d4fbd7f74255..ca02744fb369 100644
> --- a/drivers/gpu/drm/xe/xe_vram.c
> +++ b/drivers/gpu/drm/xe/xe_vram.c
> @@ -54,16 +54,11 @@ static void resize_vram_bar(struct xe_device *xe)
>  	resource_size_t current_size;
>  	resource_size_t rebar_size;
>  	struct resource *root_res;
> -	u32 bar_size_mask;
> +	int max_size, i;
>  	u32 pci_cmd;
> -	int i;
>  
>  	/* gather some relevant info */
>  	current_size = pci_resource_len(pdev, LMEM_BAR);
> -	bar_size_mask = pci_rebar_get_possible_sizes(pdev, LMEM_BAR);
> -
> -	if (!bar_size_mask)
> -		return;
>  
>  	if (force_vram_bar_size < 0)
>  		return;
> @@ -77,7 +72,8 @@ static void resize_vram_bar(struct xe_device *xe)
>  			drm_info(&xe->drm,
>  				 "Requested size: %lluMiB is not supported by rebar sizes: 0x%x. Leaving default: %lluMiB\n",
>  				 (u64)pci_rebar_size_to_bytes(rebar_size) >> 20,
> -				 bar_size_mask, (u64)current_size >> 20);
> +				 pci_rebar_get_possible_sizes(pdev, LMEM_BAR),
> +				 (u64)current_size >> 20);
>  			return;
>  		}
>  
> @@ -85,7 +81,10 @@ static void resize_vram_bar(struct xe_device *xe)
>  		if (rebar_size == current_size)
>  			return;
>  	} else {
> -		rebar_size = pci_rebar_size_to_bytes(__fls(bar_size_mask));
> +		max_size = pci_rebar_get_max_size(pdev, LMEM_BAR);
> +		if (max_size < 0)
> +			return;
> +		rebar_size = pci_rebar_size_to_bytes(max_size);
>  
>  		/* only resize if larger than current */
>  		if (rebar_size <= current_size)
> -- 
> 2.39.5
> 

Re: [PATCH v2 07/11] drm/xe/vram: Use PCI rebar helpers in resize_vram_bar()

[Rodrigo Vivi]

On Mon, Sep 15, 2025 at 12:13:54PM +0300, Ilpo Järvinen wrote:
> PCI core provides pci_rebar_size_supported() and
> pci_rebar_size_to_bytes(), use them in resize_vram_bar() to simplify
> code.
> 
> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
> Acked-by: Christian König <christian.koenig@amd.com>
> ---
>  drivers/gpu/drm/xe/xe_vram.c | 19 +++++++------------

Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

>  1 file changed, 7 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/xe/xe_vram.c b/drivers/gpu/drm/xe/xe_vram.c
> index 0b7417bb0a47..d4fbd7f74255 100644
> --- a/drivers/gpu/drm/xe/xe_vram.c
> +++ b/drivers/gpu/drm/xe/xe_vram.c
> @@ -22,8 +22,6 @@
>  #include "xe_vram.h"
>  #include "xe_vram_types.h"
>  
> -#define BAR_SIZE_SHIFT 20
> -
>  static void
>  _resize_bar(struct xe_device *xe, int resno, resource_size_t size)
>  {
> @@ -72,25 +70,22 @@ static void resize_vram_bar(struct xe_device *xe)
>  
>  	/* set to a specific size? */
>  	if (force_vram_bar_size) {
> -		u32 bar_size_bit;
> -
> -		rebar_size = force_vram_bar_size * (resource_size_t)SZ_1M;
> +		rebar_size = pci_rebar_bytes_to_size(force_vram_bar_size *
> +						     (resource_size_t)SZ_1M);
>  
> -		bar_size_bit = bar_size_mask & BIT(pci_rebar_bytes_to_size(rebar_size));
> -
> -		if (!bar_size_bit) {
> +		if (!pci_rebar_size_supported(pdev, LMEM_BAR, rebar_size)) {
>  			drm_info(&xe->drm,
>  				 "Requested size: %lluMiB is not supported by rebar sizes: 0x%x. Leaving default: %lluMiB\n",
> -				 (u64)rebar_size >> 20, bar_size_mask, (u64)current_size >> 20);
> +				 (u64)pci_rebar_size_to_bytes(rebar_size) >> 20,
> +				 bar_size_mask, (u64)current_size >> 20);
>  			return;
>  		}
>  
> -		rebar_size = 1ULL << (__fls(bar_size_bit) + BAR_SIZE_SHIFT);
> -
> +		rebar_size = pci_rebar_size_to_bytes(rebar_size);
>  		if (rebar_size == current_size)
>  			return;
>  	} else {
> -		rebar_size = 1ULL << (__fls(bar_size_mask) + BAR_SIZE_SHIFT);
> +		rebar_size = pci_rebar_size_to_bytes(__fls(bar_size_mask));
>  
>  		/* only resize if larger than current */
>  		if (rebar_size <= current_size)
> -- 
> 2.39.5
> 

Re: [PATCH v2 05/11] PCI: Add pci_rebar_size_supported() helper

[Jani Nikula]

On Mon, 15 Sep 2025, Andi Shyti <andi.shyti@kernel.org> wrote:
> Hi Ilpo,
>
>> +/**
>> + * pci_rebar_size_supported - check if size is supported for BAR
>> + * @pdev: PCI device
>> + * @bar: BAR to check
>> + * @size: size as defined in the PCIe spec (0=1MB, 31=128TB)
>> + *
>> + * Return: %true if @bar is resizable and @size is a supported, otherwise
>> + *	   %false.
>> + */
>> +bool pci_rebar_size_supported(struct pci_dev *pdev, int bar, int size)
>> +{
>> +	u64 sizes = pci_rebar_get_possible_sizes(pdev, bar);
>> +
>> +	return BIT(size) & sizes;
>
> I would return here "!!(BIT(size) & sizes)", but it doesn't
> really matter.

If the patch had that, I'd ask to drop the superfluous negations and
parens...

BR,
Jani.

>
> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
>
> Andi

-- 
Jani Nikula, Intel

Re: [PATCH v2 06/11] drm/i915/gt: Use pci_rebar_size_supported()

[Jani Nikula]

On Mon, 15 Sep 2025, Rodrigo Vivi <rodrigo.vivi@intel.com> wrote:
> On Mon, Sep 15, 2025 at 07:24:10PM +0200, Andi Shyti wrote:
>> Hi,
>> 
>> On Mon, Sep 15, 2025 at 03:42:23PM +0300, Jani Nikula wrote:
>> > On Mon, 15 Sep 2025, Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> wrote:
>> > > PCI core provides pci_rebar_size_supported() that helps in checking if
>> > > a BAR Size is supported for the BAR or not. Use it in
>> > > i915_resize_lmem_bar() to simplify code.
>> > >
>> > > Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
>> > > Acked-by: Christian König <christian.koenig@amd.com>
>> > 
>> > Reviewed-by: Jani Nikula <jani.nikula@intel.com>
>> > 
>> > and
>> > 
>> > Acked-by: Jani Nikula <jani.nikula@intel.com>
>> 
>> Just for some random noise on commit log's bureaucracy: why do we
>> need both Ack and R-b? I think R-b covers Ack making it
>> redundant. Right?
>
> reviewed-by is a more formal attestation of the entries in the
> submitting-patches doc, saying that he carefully reviewed the work.
>
> acked by is to state that from the maintainer perspective of that file
> the file can be merged through any tree.
>
> in the drm trees nowdays our tooling is enforcing acked-by tag if
> the patch is touching domains outside that drm branch itself.
>
> if a committer tries to push a patch without ack from the maintainer
> of that domain it will be blocked.
>
> So I believe it is a good idea to keep a separation of the meaning.
> Carrying a technical review of the patch in question doesn't necessarily
> mean that you, as maintainer, is okay of getting that patch merged
> through other trees.

Yes, all of the above. I just wanted to be explicit to avoid the
follow-up questions "thanks for the review, but is it okay to merge via
pci" or "thanks for the ack, but does this need review also", and move
on from this whole thread. (Which is a nice cleanup, btw, thanks.)

BR,
Jani.

-- 
Jani Nikula, Intel

Re: [PATCH v2 06/11] drm/i915/gt: Use pci_rebar_size_supported()

[Christian König]

On 16.09.25 10:12, Jani Nikula wrote:
> On Mon, 15 Sep 2025, Rodrigo Vivi <rodrigo.vivi@intel.com> wrote:
>> On Mon, Sep 15, 2025 at 07:24:10PM +0200, Andi Shyti wrote:
>>> Hi,
>>>
>>> On Mon, Sep 15, 2025 at 03:42:23PM +0300, Jani Nikula wrote:
>>>> On Mon, 15 Sep 2025, Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> wrote:
>>>>> PCI core provides pci_rebar_size_supported() that helps in checking if
>>>>> a BAR Size is supported for the BAR or not. Use it in
>>>>> i915_resize_lmem_bar() to simplify code.
>>>>>
>>>>> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
>>>>> Acked-by: Christian König <christian.koenig@amd.com>
>>>>
>>>> Reviewed-by: Jani Nikula <jani.nikula@intel.com>
>>>>
>>>> and
>>>>
>>>> Acked-by: Jani Nikula <jani.nikula@intel.com>
>>>
>>> Just for some random noise on commit log's bureaucracy: why do we
>>> need both Ack and R-b? I think R-b covers Ack making it
>>> redundant. Right?
>>
>> reviewed-by is a more formal attestation of the entries in the
>> submitting-patches doc, saying that he carefully reviewed the work.
>>
>> acked by is to state that from the maintainer perspective of that file
>> the file can be merged through any tree.
>>
>> in the drm trees nowdays our tooling is enforcing acked-by tag if
>> the patch is touching domains outside that drm branch itself.
>>
>> if a committer tries to push a patch without ack from the maintainer
>> of that domain it will be blocked.
>>
>> So I believe it is a good idea to keep a separation of the meaning.
>> Carrying a technical review of the patch in question doesn't necessarily
>> mean that you, as maintainer, is okay of getting that patch merged
>> through other trees.
> 
> Yes, all of the above. I just wanted to be explicit to avoid the
> follow-up questions "thanks for the review, but is it okay to merge via
> pci" or "thanks for the ack, but does this need review also", and move
> on from this whole thread. (Which is a nice cleanup, btw, thanks.)

Mhm, that's a really good point.

My understanding of an Acked-by by a maintainer is also "go a head and merge it through your tree", but I think we never formally documented that.

At least I can't find any reference to that in the "When to use Acked-by:, Cc:, and Co-developed-by:" section of Documentation/process/submitting-patches.rst.

Regards,
Christian.

> 
> BR,
> Jani.
> 

Re: [PATCH v2 06/11] drm/i915/gt: Use pci_rebar_size_supported()

[Rodrigo Vivi]

On Tue, Sep 16, 2025 at 10:57:24AM +0200, Christian König wrote:
> On 16.09.25 10:12, Jani Nikula wrote:
> > On Mon, 15 Sep 2025, Rodrigo Vivi <rodrigo.vivi@intel.com> wrote:
> >> On Mon, Sep 15, 2025 at 07:24:10PM +0200, Andi Shyti wrote:
> >>> Hi,
> >>>
> >>> On Mon, Sep 15, 2025 at 03:42:23PM +0300, Jani Nikula wrote:
> >>>> On Mon, 15 Sep 2025, Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> wrote:
> >>>>> PCI core provides pci_rebar_size_supported() that helps in checking if
> >>>>> a BAR Size is supported for the BAR or not. Use it in
> >>>>> i915_resize_lmem_bar() to simplify code.
> >>>>>
> >>>>> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
> >>>>> Acked-by: Christian König <christian.koenig@amd.com>
> >>>>
> >>>> Reviewed-by: Jani Nikula <jani.nikula@intel.com>
> >>>>
> >>>> and
> >>>>
> >>>> Acked-by: Jani Nikula <jani.nikula@intel.com>
> >>>
> >>> Just for some random noise on commit log's bureaucracy: why do we
> >>> need both Ack and R-b? I think R-b covers Ack making it
> >>> redundant. Right?
> >>
> >> reviewed-by is a more formal attestation of the entries in the
> >> submitting-patches doc, saying that he carefully reviewed the work.
> >>
> >> acked by is to state that from the maintainer perspective of that file
> >> the file can be merged through any tree.
> >>
> >> in the drm trees nowdays our tooling is enforcing acked-by tag if
> >> the patch is touching domains outside that drm branch itself.
> >>
> >> if a committer tries to push a patch without ack from the maintainer
> >> of that domain it will be blocked.
> >>
> >> So I believe it is a good idea to keep a separation of the meaning.
> >> Carrying a technical review of the patch in question doesn't necessarily
> >> mean that you, as maintainer, is okay of getting that patch merged
> >> through other trees.
> > 
> > Yes, all of the above. I just wanted to be explicit to avoid the
> > follow-up questions "thanks for the review, but is it okay to merge via
> > pci" or "thanks for the ack, but does this need review also", and move
> > on from this whole thread. (Which is a nice cleanup, btw, thanks.)
> 
> Mhm, that's a really good point.
> 
> My understanding of an Acked-by by a maintainer is also "go a head and merge it through your tree", but I think we never formally documented that.
> 
> At least I can't find any reference to that in the "When to use Acked-by:, Cc:, and Co-developed-by:" section of Documentation/process/submitting-patches.rst.

"Acked-by: is also less formal than Reviewed-by:. For instance, maintainers may
use it to signify that they are OK with a patch landing, but they may not have reviewed it..."

perhaps we should simply

s/patch landing/patch landing through any other tree/

> 
> Regards,
> Christian.
> 
> > 
> > BR,
> > Jani.
> > 
> 

Re: [PATCH v2 00/11] PCI: Resizable BAR improvements

[Lucas De Marchi]

On Mon, Sep 15, 2025 at 08:24:06PM +0300, Ilpo Järvinen wrote:
>On Mon, 15 Sep 2025, Lucas De Marchi wrote:
>
>> On Mon, Sep 15, 2025 at 12:13:47PM +0300, Ilpo Järvinen wrote:
>> > pci.c has been used as catch everything that doesn't fits elsewhere
>> > within PCI core and thus resizable BAR code has been placed there as
>> > well. Move Resizable BAR related code to a newly introduced rebar.c to
>> > reduce size of pci.c. After move, there are no pci_rebar_*() calls from
>> > pci.c indicating this is indeed well-defined subset of PCI core.
>> >
>> > Endpoint drivers perform Resizable BAR related operations which could
>> > well be performed by PCI core to simplify driver-side code. This
>> > series adds a few new API functions to that effect and converts the
>> > drivers to use the new APIs (in separate patches).
>> >
>> > While at it, also convert BAR sizes bitmask to u64 as PCIe spec already
>> > specifies more sizes than what will fit u32 to make the API typing more
>> > future-proof. The extra sizes beyond 128TB are not added at this point.
>> >
>> > These are based on pci/main plus a simple "adapter" patch to add the
>> > include for xe_vram_types.h that was added by a commit in drm-tip.
>> > Hopefully that is enough to avoid the within context conflict with
>> > BAR_SIZE_SHIFT removal to let the xe CI tests to be run for this
>> > series.
>> >
>> > There are two minor conflicts with the work in pci/resource but I'm
>> > hesitant to base this on top of it as this is otherwise entirely
>> > independent (and would likely prevent GPU CI tests as well). If we end
>> > up having to pull the bridge window select changes, there should be no
>> > reason why this does have to become collateral damage (so my
>> > suggestion, if this is good to go in this cycle, to take this into a
>> > separate branch than pci/resource and deal with those small conflicts
>> > while merging into pci/next).
>> >
>> > I've tested sysfs resize, i915, and xe BAR resizing functionality. In
>> > the case of xe, I did small hack patch as its resize is anyway broken
>> > as is because BAR0 pins the bridge window so resizing BAR2 fails. My
>> > hack caused other problems further down the road (likely because BAR0
>> > is in use by the driver so releasing it messed assumptions xe driver
>> > has) but the BAR resize itself was working which was all I was
>>
>> is the hack you mention here to release all BARs before attempting the
>> resize?
>
>Yes, the patch added release of BAR0 prior to resize. The existing xe code
>in _resize_bar() already releases BAR2.
>
>During resize, if the first loop in pbus_reassign_bridge_resources()
>(called from pci_resize_resource()) finds the bridge window closest to the
>endpoint still has a child, it results in having empty saved list because
>all upstream bridge windows will then have a child as well.
>
>Empty saved list is checked after the loop and
>pbus_reassign_bridge_resources() returns -ENOENT without even trying to
>assign the resources. The error is returned even if the actual bridge
>window size is large enough to fit the resized resource.
>
>The logic in pci_resize_resource() and pbus_reassign_bridge_resources()
>need some other improvements besides that problem, but I likely won't
>have time to look at that until completing the fitting algorithm changes.
>I'd actually want to add pci_release_and_resize_resource() which would
>take care of releasing all the resources of the device (obviously driver
>must have its hands off all those BARs when it calls that function). With
>the current pci_resize_resource() API, handling the restore of BARs in
>case of failure is not as robust as I'd like to make it.
>
>> > interested to know. I'm not planning to pursue fixing the pinning
>> > problem within xe driver because the core changes to consider maximum
>> > size of the resizable BARs should take care of the main problem by
>> > different means.
>>
>> I'd actually like to pursue that myself as that could be propagated to
>> stable since we do have some resize errors in xe with BMG that I wasn't
>> understanding. It's likely due to xe_mmio_probe_early() taking a hold of
>> BAR0 and not expecting it to be moved. We could either remap if we have
>> have to resize or just move the resize logic early on.
>
>Great. If you have any questions when it comes to the PCI core side code,
>please let me know.

I moved the resize to happen before anything else in xe. However when
testing I noticed a scenario failing without involving the driver.
With and without this series I still have the same pass/failure
scenarios:

Tests executed with a BMG. Just after boot, BAR2 is 16GB.

1) If I resize it via sysfs to 8GB and then load the driver, it resizes
it back. Resize from sysfs works too. No change in behavior.

2) If I do "remove the bridge via sysfs and rescan the bus"[1], it fails to
resize (either automatically, on rescan, via sysfs, or loading the xe
driver). It just stays at 256M. The only thing that brings it back is a
reboot. /proc/iomem shows this:

4000000000-7fffffffff : PCI Bus 0000:00
   4000000000-44007fffff : PCI Bus 0000:01
     4000000000-4017ffffff : PCI Bus 0000:02
       4000000000-400fffffff : PCI Bus 0000:03    <<<< BMG
         4000000000-400fffffff : 0000:03:00.0
       4010000000-40100fffff : PCI Bus 0000:04
     4018000000-40187fffff : 0000:01:00.0


And dmesg shows this for the rescan:

[ 1673.189737] pci 0000:01:00.0: [8086:e2ff] type 01 class 0x060400 PCIe Switch Upstream Port
[ 1673.189794] pci 0000:01:00.0: BAR 0 [mem 0x00000000-0x007fffff 64bit pref]
[ 1673.189808] pci 0000:01:00.0: PCI bridge to [bus 00]
[ 1673.189824] pci 0000:01:00.0:   bridge window [io  0x0000-0x0fff]
[ 1673.189834] pci 0000:01:00.0:   bridge window [mem 0x00000000-0x000fffff]
[ 1673.189856] pci 0000:01:00.0:   bridge window [mem 0x00000000-0x000fffff 64bit pref]
[ 1673.189878] pci 0000:01:00.0: Max Payload Size set to 256 (was 128, max 256)
[ 1673.190164] pci 0000:01:00.0: PME# supported from D0 D3hot D3cold
[ 1673.193531] pci 0000:01:00.0: Adding to iommu group 16
[ 1673.196997] pcieport 0000:00:01.0: ASPM: current common clock configuration is inconsistent, reconfiguring
[ 1673.197061] pci 0000:01:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[ 1673.197421] pci 0000:02:01.0: [8086:e2f0] type 01 class 0x060400 PCIe Switch Downstream Port
[ 1673.197452] pci 0000:02:01.0: PCI bridge to [bus 00]
[ 1673.197463] pci 0000:02:01.0:   bridge window [io  0x0000-0x0fff]
[ 1673.197468] pci 0000:02:01.0:   bridge window [mem 0x00000000-0x000fffff]
[ 1673.197482] pci 0000:02:01.0:   bridge window [mem 0x00000000-0x000fffff 64bit pref]
[ 1673.197497] pci 0000:02:01.0: Max Payload Size set to 256 (was 128, max 256)
[ 1673.197503] pci 0000:02:01.0: enabling Extended Tags
[ 1673.197660] pci 0000:02:01.0: PME# supported from D0 D3hot D3cold
[ 1673.198411] pci 0000:02:01.0: Adding to iommu group 17
[ 1673.200258] pci 0000:02:02.0: [8086:e2f1] type 01 class 0x060400 PCIe Switch Downstream Port
[ 1673.200289] pci 0000:02:02.0: PCI bridge to [bus 00]
[ 1673.200299] pci 0000:02:02.0:   bridge window [io  0x0000-0x0fff]
[ 1673.200304] pci 0000:02:02.0:   bridge window [mem 0x00000000-0x000fffff]
[ 1673.200317] pci 0000:02:02.0:   bridge window [mem 0x00000000-0x000fffff 64bit pref]
[ 1673.200333] pci 0000:02:02.0: Max Payload Size set to 256 (was 128, max 256)
[ 1673.200337] pci 0000:02:02.0: enabling Extended Tags
[ 1673.200470] pci 0000:02:02.0: PME# supported from D0 D3hot D3cold
[ 1673.201059] pci 0000:02:02.0: Adding to iommu group 18
[ 1673.202761] pci 0000:01:00.0: PCI bridge to [bus 02-04]
[ 1673.202774] pci 0000:02:01.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[ 1673.202782] pci 0000:02:02.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[ 1673.203024] pci 0000:03:00.0: [8086:e221] type 00 class 0x030000 PCIe Endpoint
[ 1673.203060] pci 0000:03:00.0: BAR 0 [mem 0x00000000-0x00ffffff 64bit]
[ 1673.203064] pci 0000:03:00.0: BAR 2 [mem 0x00000000-0x0fffffff 64bit pref]
[ 1673.203069] pci 0000:03:00.0: ROM [mem 0x00000000-0x001fffff pref]
[ 1673.203077] pci 0000:03:00.0: Max Payload Size set to 256 (was 128, max 256)
[ 1673.203209] pci 0000:03:00.0: PME# supported from D0 D3hot
[ 1673.203770] pci 0000:03:00.0: Adding to iommu group 19
[ 1673.205451] pci 0000:03:00.0: vgaarb: setting as boot VGA device
[ 1673.205454] pci 0000:03:00.0: vgaarb: bridge control possible
[ 1673.205455] pci 0000:03:00.0: vgaarb: VGA device added: decodes=io+mem,owns=none,locks=none
[ 1673.205534] pci 0000:02:01.0: PCI bridge to [bus 03-04]
[ 1673.205543] pci_bus 0000:03: busn_res: [bus 03-04] end is updated to 03
[ 1673.205787] pci 0000:04:00.0: [8086:e2f7] type 00 class 0x040300 PCIe Endpoint
[ 1673.205848] pci 0000:04:00.0: BAR 0 [mem 0x00000000-0x00003fff 64bit]
[ 1673.205867] pci 0000:04:00.0: Max Payload Size set to 256 (was 128, max 256)
[ 1673.205872] pci 0000:04:00.0: enabling Extended Tags
[ 1673.206012] pci 0000:04:00.0: PME# supported from D3hot D3cold
[ 1673.206528] pci 0000:04:00.0: Adding to iommu group 20
[ 1673.208271] pci 0000:02:02.0: PCI bridge to [bus 04]
[ 1673.208284] pci_bus 0000:04: busn_res: [bus 04] end is updated to 04
[ 1673.208291] pci_bus 0000:02: busn_res: [bus 02-04] end is updated to 04
[ 1673.232003] pcieport 0000:00:01.0: Assigned bridge window [mem 0x83000000-0x840fffff] to [bus 01-04] cannot fit 0x2000000 required for 0000:02:01.0 bridging to [bus 03]
[ 1673.232009] pci 0000:02:01.0: bridge window [mem 0x00000000-0x000fffff] to [bus 03] requires relaxed alignment rules
[ 1673.232016] pci 0000:02:01.0: bridge window [mem 0x01000000-0x01ffffff] to [bus 03] add_size 200000 add_align 1000000
[ 1673.232020] pcieport 0000:00:01.0: Assigned bridge window [mem 0x83000000-0x840fffff] to [bus 01-04] cannot fit 0x1800000 required for 0000:01:00.0 bridging to [bus 02-04]
[ 1673.232025] pci 0000:01:00.0: bridge window [mem 0x00000000-0x000fffff] to [bus 02-04] requires relaxed alignment rules
[ 1673.232027] pcieport 0000:00:01.0: Assigned bridge window [mem 0x83000000-0x840fffff] to [bus 01-04] cannot fit 0x2000000 required for 0000:01:00.0 bridging to [bus 02-04]
[ 1673.232031] pci 0000:01:00.0: bridge window [mem 0x00000000-0x000fffff] to [bus 02-04] requires relaxed alignment rules
[ 1673.232036] pci 0000:01:00.0: bridge window [mem 0x01000000-0x020fffff] to [bus 02-04] add_size 200000 add_align 1000000
[ 1673.232077] pci 0000:01:00.0: bridge window [mem 0x4000000000-0x4017ffffff 64bit pref]: assigned
[ 1673.232080] pci 0000:01:00.0: bridge window [mem size 0x01300000]: can't assign; no space
[ 1673.232082] pci 0000:01:00.0: bridge window [mem size 0x01300000]: failed to assign
[ 1673.232090] pci 0000:01:00.0: BAR 0 [mem 0x4018000000-0x40187fffff 64bit pref]: assigned
[ 1673.232103] pci 0000:01:00.0: bridge window [io  0x8000-0x9fff]: assigned
[ 1673.232129] pci 0000:01:00.0: bridge window [mem 0x83000000-0x840fffff]: assigned
[ 1673.232131] pci 0000:01:00.0: bridge window [mem 0x83000000-0x840fffff]: failed to expand by 0x200000
[ 1673.232136] pci 0000:01:00.0: bridge window [mem 0x83000000-0x840fffff]: failed to add optional 200000
[ 1673.232192] pci 0000:02:01.0: bridge window [mem 0x4000000000-0x400fffffff 64bit pref]: assigned
[ 1673.232196] pci 0000:02:01.0: bridge window [mem 0x83000000-0x83ffffff]: assigned
[ 1673.232200] pci 0000:02:02.0: bridge window [mem 0x84000000-0x840fffff]: assigned
[ 1673.232202] pci 0000:02:02.0: bridge window [mem 0x4010000000-0x40100fffff 64bit pref]: assigned
[ 1673.232204] pci 0000:02:01.0: bridge window [io  0x8000-0x8fff]: assigned
[ 1673.232206] pci 0000:02:02.0: bridge window [io  0x9000-0x9fff]: assigned
[ 1673.232241] pci 0000:03:00.0: BAR 2 [mem 0x4000000000-0x400fffffff 64bit pref]: assigned
[ 1673.232250] pci 0000:03:00.0: BAR 0 [mem 0x83000000-0x83ffffff 64bit]: assigned
[ 1673.232259] pci 0000:03:00.0: ROM [mem size 0x00200000 pref]: can't assign; no space
[ 1673.232261] pci 0000:03:00.0: ROM [mem size 0x00200000 pref]: failed to assign
[ 1673.232272] pci 0000:03:00.0: BAR 2 [mem 0x4000000000-0x400fffffff 64bit pref]: assigned
[ 1673.232280] pci 0000:03:00.0: BAR 0 [mem 0x83000000-0x83ffffff 64bit]: assigned
[ 1673.232289] pci 0000:03:00.0: ROM [mem size 0x00200000 pref]: can't assign; no space
[ 1673.232291] pci 0000:03:00.0: ROM [mem size 0x00200000 pref]: failed to assign
[ 1673.232302] pci 0000:02:01.0: PCI bridge to [bus 03]
[ 1673.232304] pci 0000:02:01.0:   bridge window [io  0x8000-0x8fff]
[ 1673.232309] pci 0000:02:01.0:   bridge window [mem 0x83000000-0x83ffffff]
[ 1673.232313] pci 0000:02:01.0:   bridge window [mem 0x4000000000-0x400fffffff 64bit pref]
[ 1673.232321] pci 0000:04:00.0: BAR 0 [mem 0x84000000-0x84003fff 64bit]: assigned
[ 1673.232336] pci 0000:02:02.0: PCI bridge to [bus 04]
[ 1673.232339] pci 0000:02:02.0:   bridge window [io  0x9000-0x9fff]
[ 1673.232345] pci 0000:02:02.0:   bridge window [mem 0x84000000-0x840fffff]
[ 1673.232349] pci 0000:02:02.0:   bridge window [mem 0x4010000000-0x40100fffff 64bit pref]
[ 1673.232356] pci 0000:01:00.0: PCI bridge to [bus 02-04]
[ 1673.232359] pci 0000:01:00.0:   bridge window [io  0x8000-0x9fff]
[ 1673.232363] pci 0000:01:00.0:   bridge window [mem 0x83000000-0x840fffff]
[ 1673.232366] pci 0000:01:00.0:   bridge window [mem 0x4000000000-0x4017ffffff 64bit pref]
[ 1673.232471] pcieport 0000:01:00.0: enabling device (0000 -> 0003)
[ 1673.233508] pcieport 0000:02:01.0: enabling device (0000 -> 0003)
[ 1673.233692] pcieport 0000:02:02.0: enabling device (0000 -> 0003)

# echo 9 > /sys/bus/pci/devices/0000\:03\:00.0/resource2_resize 
-bash: echo: write error: No space left on device


[1] # echo 1 > /sys/bus/pci/devices/0000\:01\:00.0/remove
     # echo 0 > /sys/bus/pci/drivers_autoprobe
     # echo 1 > /sys/bus/pci/rescan


I can share the xe patch so you check if it at least fixes it in your
test scenario.

thanks
Lucas De Marchi

>
>-- 
> i.
>
>> > Some parts of this are to be used by the resizable BAR changes into the
>> > resource fitting/assingment logic but these seem to stand on their own
>> > so sending these out now to reduce the size of the other patch series.
>> >
>> > v2:
>> > - Kerneldoc:
>> >  - Improve formatting of errno returns
>> >  - Open "ctrl" -> "control"
>> >  - Removed mislead "bit" words (when referring to BAR size)
>> >  - Rewrote pci_rebar_get_possible_sizes() kernel doc to not claim the
>> >    returned bitmask is defined in PCIe spec as the capability bits now
>> >    span across two registers in the spec and are not continuous (we
>> >    don't support the second block of bits yet, but this API is expected
>> >    to return the bits without the hole so it will not be matching with
>> >    the spec layout).
>> > - Dropped superfluous zero check from pci_rebar_size_supported()
>> > - Small improvement to changelog of patch 7
>> >
>> > Ilpo Järvinen (11):
>> >  PCI: Move Resizable BAR code into rebar.c
>> >  PCI: Cleanup pci_rebar_bytes_to_size() and move into rebar.c
>> >  PCI: Move pci_rebar_size_to_bytes() and export it
>> >  PCI: Improve Resizable BAR functions kernel doc
>> >  PCI: Add pci_rebar_size_supported() helper
>> >  drm/i915/gt: Use pci_rebar_size_supported()
>> >  drm/xe/vram: Use PCI rebar helpers in resize_vram_bar()
>> >  PCI: Add pci_rebar_get_max_size()
>> >  drm/xe/vram: Use pci_rebar_get_max_size()
>> >  drm/amdgpu: Use pci_rebar_get_max_size()
>> >  PCI: Convert BAR sizes bitmasks to u64
>> >
>> > Documentation/driver-api/pci/pci.rst        |   3 +
>> > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c  |   8 +-
>> > drivers/gpu/drm/i915/gt/intel_region_lmem.c |  10 +-
>> > drivers/gpu/drm/xe/xe_vram.c                |  32 +-
>> > drivers/pci/Makefile                        |   2 +-
>> > drivers/pci/iov.c                           |   9 +-
>> > drivers/pci/pci-sysfs.c                     |   2 +-
>> > drivers/pci/pci.c                           | 145 ---------
>> > drivers/pci/pci.h                           |   5 +-
>> > drivers/pci/rebar.c                         | 314 ++++++++++++++++++++
>> > drivers/pci/setup-res.c                     |  78 -----
>> > include/linux/pci.h                         |  15 +-
>> > 12 files changed, 350 insertions(+), 273 deletions(-)
>> > create mode 100644 drivers/pci/rebar.c
>> >
>> >
>> > base-commit: 8f5ae30d69d7543eee0d70083daf4de8fe15d585
>> > prerequisite-patch-id: 35bd3cd7a60ff7d887450a7fdde73b055a76ae24
>> > --
>> > 2.39.5
>> >
>>

Re: [PATCH v2 00/11] PCI: Resizable BAR improvements

[Ilpo Järvinen]

[-- Attachment #1: Type: text/plain, Size: 17124 bytes --]

On Tue, 16 Sep 2025, Lucas De Marchi wrote:

> On Mon, Sep 15, 2025 at 08:24:06PM +0300, Ilpo Järvinen wrote:
> > On Mon, 15 Sep 2025, Lucas De Marchi wrote:
> > 
> > > On Mon, Sep 15, 2025 at 12:13:47PM +0300, Ilpo Järvinen wrote:
> > > > pci.c has been used as catch everything that doesn't fits elsewhere
> > > > within PCI core and thus resizable BAR code has been placed there as
> > > > well. Move Resizable BAR related code to a newly introduced rebar.c to
> > > > reduce size of pci.c. After move, there are no pci_rebar_*() calls from
> > > > pci.c indicating this is indeed well-defined subset of PCI core.
> > > >
> > > > Endpoint drivers perform Resizable BAR related operations which could
> > > > well be performed by PCI core to simplify driver-side code. This
> > > > series adds a few new API functions to that effect and converts the
> > > > drivers to use the new APIs (in separate patches).
> > > >
> > > > While at it, also convert BAR sizes bitmask to u64 as PCIe spec already
> > > > specifies more sizes than what will fit u32 to make the API typing more
> > > > future-proof. The extra sizes beyond 128TB are not added at this point.
> > > >
> > > > These are based on pci/main plus a simple "adapter" patch to add the
> > > > include for xe_vram_types.h that was added by a commit in drm-tip.
> > > > Hopefully that is enough to avoid the within context conflict with
> > > > BAR_SIZE_SHIFT removal to let the xe CI tests to be run for this
> > > > series.
> > > >
> > > > There are two minor conflicts with the work in pci/resource but I'm
> > > > hesitant to base this on top of it as this is otherwise entirely
> > > > independent (and would likely prevent GPU CI tests as well). If we end
> > > > up having to pull the bridge window select changes, there should be no
> > > > reason why this does have to become collateral damage (so my
> > > > suggestion, if this is good to go in this cycle, to take this into a
> > > > separate branch than pci/resource and deal with those small conflicts
> > > > while merging into pci/next).
> > > >
> > > > I've tested sysfs resize, i915, and xe BAR resizing functionality. In
> > > > the case of xe, I did small hack patch as its resize is anyway broken
> > > > as is because BAR0 pins the bridge window so resizing BAR2 fails. My
> > > > hack caused other problems further down the road (likely because BAR0
> > > > is in use by the driver so releasing it messed assumptions xe driver
> > > > has) but the BAR resize itself was working which was all I was
> > > 
> > > is the hack you mention here to release all BARs before attempting the
> > > resize?
> > 
> > Yes, the patch added release of BAR0 prior to resize. The existing xe code
> > in _resize_bar() already releases BAR2.
> > 
> > During resize, if the first loop in pbus_reassign_bridge_resources()
> > (called from pci_resize_resource()) finds the bridge window closest to the
> > endpoint still has a child, it results in having empty saved list because
> > all upstream bridge windows will then have a child as well.
> > 
> > Empty saved list is checked after the loop and
> > pbus_reassign_bridge_resources() returns -ENOENT without even trying to
> > assign the resources. The error is returned even if the actual bridge
> > window size is large enough to fit the resized resource.
> > 
> > The logic in pci_resize_resource() and pbus_reassign_bridge_resources()
> > need some other improvements besides that problem, but I likely won't
> > have time to look at that until completing the fitting algorithm changes.
> > I'd actually want to add pci_release_and_resize_resource() which would
> > take care of releasing all the resources of the device (obviously driver
> > must have its hands off all those BARs when it calls that function). With
> > the current pci_resize_resource() API, handling the restore of BARs in
> > case of failure is not as robust as I'd like to make it.
> > 
> > > > interested to know. I'm not planning to pursue fixing the pinning
> > > > problem within xe driver because the core changes to consider maximum
> > > > size of the resizable BARs should take care of the main problem by
> > > > different means.
> > > 
> > > I'd actually like to pursue that myself as that could be propagated to
> > > stable since we do have some resize errors in xe with BMG that I wasn't
> > > understanding. It's likely due to xe_mmio_probe_early() taking a hold of
> > > BAR0 and not expecting it to be moved. We could either remap if we have
> > > have to resize or just move the resize logic early on.
> > 
> > Great. If you have any questions when it comes to the PCI core side code,
> > please let me know.
> 
> I moved the resize to happen before anything else in xe. However when
> testing I noticed a scenario failing without involving the driver.
> With and without this series I still have the same pass/failure
> scenarios:
> 
> Tests executed with a BMG. Just after boot, BAR2 is 16GB.
> 
> 1) If I resize it via sysfs to 8GB and then load the driver, it resizes
> it back. Resize from sysfs works too. No change in behavior.

It's expected that resizing smaller size -> back to the original works 
through sysfs because the upstream window pins won't prevent reacquiring 
the same or less space.

But the way resize is called from current xe code, sizing even to a 
smaller size fails because BAR0 pins the closest upstream window, 
resulting in -ENOENT as explained above. I don't see fixing this on core 
side as priority because I plan to rework the resizing code anyway and 
resizing to a smaller size doesn't seem overly useful use case.

> 2) If I do "remove the bridge via sysfs and rescan the bus"[1], it fails to
> resize (either automatically, on rescan, via sysfs, or loading the xe
> driver). It just stays at 256M.

This is because the larger resource sizes are only calculated on the 
actual resize call which occurs after the bridge windows were already 
sized on rescan to the smaller size. At that point, the critical bridge 
windows are already pinned in place and thus cannot be relocated to free 
area I assume there would be somewhere within 4000000000-7fffffffff.

> The only thing that brings it back is a reboot. /proc/iomem shows this:
> 
> 4000000000-7fffffffff : PCI Bus 0000:00
>   4000000000-44007fffff : PCI Bus 0000:01
>     4000000000-4017ffffff : PCI Bus 0000:02
>       4000000000-400fffffff : PCI Bus 0000:03    <<<< BMG
>         4000000000-400fffffff : 0000:03:00.0

>       4010000000-40100fffff : PCI Bus 0000:04

This pins 0000:01:00.0's window in place. And also prevents enlarging the 
siblings.

It would possible, though, to release it and still use sysfs to perform 
resize on 0000:03:00.0 as removing 0000:04:00.0 doesn't require removing 
0000:03:00.0. But...

>     4018000000-40187fffff : 0000:01:00.0

...This resource pins 0000:00:01.0's window in place. AFAIK, it cannot be 
released other than by removing 0000:01:00.0 which results in removing 
0000:03:00.0 as well, thus making it impossible to perform the BAR resize 
for 0000:03:00.0 through sysfs anymore. Catch-22.

Could you test if the attached quirk patch helps. Maybe it could be 
considered as the interim solution until the bridge sizing logic becomes 
aware of the resizable BARs. To use a quirk to do this feels hacky to me, 
but then it's hard to point out any real downsides with that approach 
(other than having to quirk it).

You'll still need to manually release 0000:04:00.0 but the BAR0 on the 
switch should be gone thanks to the quirk. When both of the window pins 
are gone, I think the resize through sysfs should work.

> And dmesg shows this for the rescan:
> 
> [ 1673.189737] pci 0000:01:00.0: [8086:e2ff] type 01 class 0x060400 PCIe
> Switch Upstream Port
> [ 1673.189794] pci 0000:01:00.0: BAR 0 [mem 0x00000000-0x007fffff 64bit pref]
> [ 1673.189808] pci 0000:01:00.0: PCI bridge to [bus 00]
> [ 1673.189824] pci 0000:01:00.0:   bridge window [io  0x0000-0x0fff]
> [ 1673.189834] pci 0000:01:00.0:   bridge window [mem 0x00000000-0x000fffff]
> [ 1673.189856] pci 0000:01:00.0:   bridge window [mem 0x00000000-0x000fffff
> 64bit pref]
> [ 1673.189878] pci 0000:01:00.0: Max Payload Size set to 256 (was 128, max
> 256)
> [ 1673.190164] pci 0000:01:00.0: PME# supported from D0 D3hot D3cold
> [ 1673.193531] pci 0000:01:00.0: Adding to iommu group 16
> [ 1673.196997] pcieport 0000:00:01.0: ASPM: current common clock configuration
> is inconsistent, reconfiguring
> [ 1673.197061] pci 0000:01:00.0: bridge configuration invalid ([bus 00-00]),
> reconfiguring
> [ 1673.197421] pci 0000:02:01.0: [8086:e2f0] type 01 class 0x060400 PCIe
> Switch Downstream Port
> [ 1673.197452] pci 0000:02:01.0: PCI bridge to [bus 00]
> [ 1673.197463] pci 0000:02:01.0:   bridge window [io  0x0000-0x0fff]
> [ 1673.197468] pci 0000:02:01.0:   bridge window [mem 0x00000000-0x000fffff]
> [ 1673.197482] pci 0000:02:01.0:   bridge window [mem 0x00000000-0x000fffff
> 64bit pref]
> [ 1673.197497] pci 0000:02:01.0: Max Payload Size set to 256 (was 128, max
> 256)
> [ 1673.197503] pci 0000:02:01.0: enabling Extended Tags
> [ 1673.197660] pci 0000:02:01.0: PME# supported from D0 D3hot D3cold
> [ 1673.198411] pci 0000:02:01.0: Adding to iommu group 17
> [ 1673.200258] pci 0000:02:02.0: [8086:e2f1] type 01 class 0x060400 PCIe
> Switch Downstream Port
> [ 1673.200289] pci 0000:02:02.0: PCI bridge to [bus 00]
> [ 1673.200299] pci 0000:02:02.0:   bridge window [io  0x0000-0x0fff]
> [ 1673.200304] pci 0000:02:02.0:   bridge window [mem 0x00000000-0x000fffff]
> [ 1673.200317] pci 0000:02:02.0:   bridge window [mem 0x00000000-0x000fffff
> 64bit pref]
> [ 1673.200333] pci 0000:02:02.0: Max Payload Size set to 256 (was 128, max
> 256)
> [ 1673.200337] pci 0000:02:02.0: enabling Extended Tags
> [ 1673.200470] pci 0000:02:02.0: PME# supported from D0 D3hot D3cold
> [ 1673.201059] pci 0000:02:02.0: Adding to iommu group 18
> [ 1673.202761] pci 0000:01:00.0: PCI bridge to [bus 02-04]
> [ 1673.202774] pci 0000:02:01.0: bridge configuration invalid ([bus 00-00]),
> reconfiguring
> [ 1673.202782] pci 0000:02:02.0: bridge configuration invalid ([bus 00-00]),
> reconfiguring
> [ 1673.203024] pci 0000:03:00.0: [8086:e221] type 00 class 0x030000 PCIe
> Endpoint
> [ 1673.203060] pci 0000:03:00.0: BAR 0 [mem 0x00000000-0x00ffffff 64bit]
> [ 1673.203064] pci 0000:03:00.0: BAR 2 [mem 0x00000000-0x0fffffff 64bit pref]
> [ 1673.203069] pci 0000:03:00.0: ROM [mem 0x00000000-0x001fffff pref]
> [ 1673.203077] pci 0000:03:00.0: Max Payload Size set to 256 (was 128, max
> 256)
> [ 1673.203209] pci 0000:03:00.0: PME# supported from D0 D3hot
> [ 1673.203770] pci 0000:03:00.0: Adding to iommu group 19
> [ 1673.205451] pci 0000:03:00.0: vgaarb: setting as boot VGA device
> [ 1673.205454] pci 0000:03:00.0: vgaarb: bridge control possible
> [ 1673.205455] pci 0000:03:00.0: vgaarb: VGA device added:
> decodes=io+mem,owns=none,locks=none
> [ 1673.205534] pci 0000:02:01.0: PCI bridge to [bus 03-04]
> [ 1673.205543] pci_bus 0000:03: busn_res: [bus 03-04] end is updated to 03
> [ 1673.205787] pci 0000:04:00.0: [8086:e2f7] type 00 class 0x040300 PCIe
> Endpoint
> [ 1673.205848] pci 0000:04:00.0: BAR 0 [mem 0x00000000-0x00003fff 64bit]
> [ 1673.205867] pci 0000:04:00.0: Max Payload Size set to 256 (was 128, max
> 256)
> [ 1673.205872] pci 0000:04:00.0: enabling Extended Tags
> [ 1673.206012] pci 0000:04:00.0: PME# supported from D3hot D3cold
> [ 1673.206528] pci 0000:04:00.0: Adding to iommu group 20
> [ 1673.208271] pci 0000:02:02.0: PCI bridge to [bus 04]
> [ 1673.208284] pci_bus 0000:04: busn_res: [bus 04] end is updated to 04
> [ 1673.208291] pci_bus 0000:02: busn_res: [bus 02-04] end is updated to 04
> [ 1673.232003] pcieport 0000:00:01.0: Assigned bridge window [mem
> 0x83000000-0x840fffff] to [bus 01-04] cannot fit 0x2000000 required for
> 0000:02:01.0 bridging to [bus 03]
> [ 1673.232009] pci 0000:02:01.0: bridge window [mem 0x00000000-0x000fffff] to
> [bus 03] requires relaxed alignment rules
> [ 1673.232016] pci 0000:02:01.0: bridge window [mem 0x01000000-0x01ffffff] to
> [bus 03] add_size 200000 add_align 1000000
> [ 1673.232020] pcieport 0000:00:01.0: Assigned bridge window [mem
> 0x83000000-0x840fffff] to [bus 01-04] cannot fit 0x1800000 required for
> 0000:01:00.0 bridging to [bus 02-04]
> [ 1673.232025] pci 0000:01:00.0: bridge window [mem 0x00000000-0x000fffff] to
> [bus 02-04] requires relaxed alignment rules
> [ 1673.232027] pcieport 0000:00:01.0: Assigned bridge window [mem
> 0x83000000-0x840fffff] to [bus 01-04] cannot fit 0x2000000 required for
> 0000:01:00.0 bridging to [bus 02-04]
> [ 1673.232031] pci 0000:01:00.0: bridge window [mem 0x00000000-0x000fffff] to
> [bus 02-04] requires relaxed alignment rules
> [ 1673.232036] pci 0000:01:00.0: bridge window [mem 0x01000000-0x020fffff] to
> [bus 02-04] add_size 200000 add_align 1000000
> [ 1673.232077] pci 0000:01:00.0: bridge window [mem 0x4000000000-0x4017ffffff
> 64bit pref]: assigned
> [ 1673.232080] pci 0000:01:00.0: bridge window [mem size 0x01300000]: can't
> assign; no space
> [ 1673.232082] pci 0000:01:00.0: bridge window [mem size 0x01300000]: failed
> to assign
> [ 1673.232090] pci 0000:01:00.0: BAR 0 [mem 0x4018000000-0x40187fffff 64bit
> pref]: assigned
> [ 1673.232103] pci 0000:01:00.0: bridge window [io  0x8000-0x9fff]: assigned
> [ 1673.232129] pci 0000:01:00.0: bridge window [mem 0x83000000-0x840fffff]:
> assigned
> [ 1673.232131] pci 0000:01:00.0: bridge window [mem 0x83000000-0x840fffff]:
> failed to expand by 0x200000
> [ 1673.232136] pci 0000:01:00.0: bridge window [mem 0x83000000-0x840fffff]:
> failed to add optional 200000
> [ 1673.232192] pci 0000:02:01.0: bridge window [mem 0x4000000000-0x400fffffff
> 64bit pref]: assigned
> [ 1673.232196] pci 0000:02:01.0: bridge window [mem 0x83000000-0x83ffffff]:
> assigned
> [ 1673.232200] pci 0000:02:02.0: bridge window [mem 0x84000000-0x840fffff]:
> assigned
> [ 1673.232202] pci 0000:02:02.0: bridge window [mem 0x4010000000-0x40100fffff
> 64bit pref]: assigned
> [ 1673.232204] pci 0000:02:01.0: bridge window [io  0x8000-0x8fff]: assigned
> [ 1673.232206] pci 0000:02:02.0: bridge window [io  0x9000-0x9fff]: assigned
> [ 1673.232241] pci 0000:03:00.0: BAR 2 [mem 0x4000000000-0x400fffffff 64bit
> pref]: assigned
> [ 1673.232250] pci 0000:03:00.0: BAR 0 [mem 0x83000000-0x83ffffff 64bit]:
> assigned
> [ 1673.232259] pci 0000:03:00.0: ROM [mem size 0x00200000 pref]: can't assign;
> no space
> [ 1673.232261] pci 0000:03:00.0: ROM [mem size 0x00200000 pref]: failed to
> assign
> [ 1673.232272] pci 0000:03:00.0: BAR 2 [mem 0x4000000000-0x400fffffff 64bit
> pref]: assigned
> [ 1673.232280] pci 0000:03:00.0: BAR 0 [mem 0x83000000-0x83ffffff 64bit]:
> assigned
> [ 1673.232289] pci 0000:03:00.0: ROM [mem size 0x00200000 pref]: can't assign;
> no space
> [ 1673.232291] pci 0000:03:00.0: ROM [mem size 0x00200000 pref]: failed to
> assign
> [ 1673.232302] pci 0000:02:01.0: PCI bridge to [bus 03]
> [ 1673.232304] pci 0000:02:01.0:   bridge window [io  0x8000-0x8fff]
> [ 1673.232309] pci 0000:02:01.0:   bridge window [mem 0x83000000-0x83ffffff]
> [ 1673.232313] pci 0000:02:01.0:   bridge window [mem
> 0x4000000000-0x400fffffff 64bit pref]
> [ 1673.232321] pci 0000:04:00.0: BAR 0 [mem 0x84000000-0x84003fff 64bit]:
> assigned
> [ 1673.232336] pci 0000:02:02.0: PCI bridge to [bus 04]
> [ 1673.232339] pci 0000:02:02.0:   bridge window [io  0x9000-0x9fff]
> [ 1673.232345] pci 0000:02:02.0:   bridge window [mem 0x84000000-0x840fffff]
> [ 1673.232349] pci 0000:02:02.0:   bridge window [mem
> 0x4010000000-0x40100fffff 64bit pref]
> [ 1673.232356] pci 0000:01:00.0: PCI bridge to [bus 02-04]
> [ 1673.232359] pci 0000:01:00.0:   bridge window [io  0x8000-0x9fff]
> [ 1673.232363] pci 0000:01:00.0:   bridge window [mem 0x83000000-0x840fffff]
> [ 1673.232366] pci 0000:01:00.0:   bridge window [mem
> 0x4000000000-0x4017ffffff 64bit pref]
> [ 1673.232471] pcieport 0000:01:00.0: enabling device (0000 -> 0003)
> [ 1673.233508] pcieport 0000:02:01.0: enabling device (0000 -> 0003)
> [ 1673.233692] pcieport 0000:02:02.0: enabling device (0000 -> 0003)
> 
> # echo 9 > /sys/bus/pci/devices/0000\:03\:00.0/resource2_resize -bash: echo:
> write error: No space left on device
> 
> 
> [1] # echo 1 > /sys/bus/pci/devices/0000\:01\:00.0/remove
>     # echo 0 > /sys/bus/pci/drivers_autoprobe
>     # echo 1 > /sys/bus/pci/rescan
> 
> 
> I can share the xe patch so you check if it at least fixes it in your
> test scenario.

Ah, one thing I didn't remember mention is that in my case the BAR is 
already at its maximum size, so to test the resize is working, I made
the target size smaller, not larger. (I understand this might not be very 
helpful in your case but I was only interested that resize code still 
works after this series).

-- 
 i.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-diff; name=0001-PCI-Release-BAR0-of-an-integrated-bridge-to-allow-GP.patch, Size: 3715 bytes --]

From 948a49f01df54b3435861138a0eae85bb2c3f1f3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= <ilpo.jarvinen@linux.intel.com>
Date: Wed, 17 Sep 2025 15:24:53 +0300
Subject: [PATCH 1/1] PCI: Release BAR0 of an integrated bridge to allow GPU
 BAR resize
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

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.demarchi@intel.com>
Link: https://lore.kernel.org/linux-pci/fl6tx5ztvttg7txmz2ps7oyd745wg3lwcp3h7esmvnyg26n44y@owo2ojiu2mov/
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
---

This feels quite hacky to me and I'm working towards a better solution
which is to consider Resizable BAR maximum size the resource fitting
algorithm. But then, I don't expect the better solution to be something
we want to push into stable due to extremely invasive dependencies. So
maybe consider this an interim/legacy solution to the resizing problem
and remove it once the algorithmic approach works (or more precisely
retain it only in the old kernel versions).
---
 drivers/pci/quirks.c | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index d97335a40193..98a4f0a1285b 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);

base-commit: 8f5ae30d69d7543eee0d70083daf4de8fe15d585
-- 
2.39.5

Re: [PATCH v2 00/11] PCI: Resizable BAR improvements

[Lucas De Marchi]

[-- Attachment #1: Type: text/plain, Size: 24455 bytes --]

On Wed, Sep 17, 2025 at 04:00:10PM +0300, Ilpo Järvinen wrote:
>On Tue, 16 Sep 2025, Lucas De Marchi wrote:
>
>> On Mon, Sep 15, 2025 at 08:24:06PM +0300, Ilpo Järvinen wrote:
>> > On Mon, 15 Sep 2025, Lucas De Marchi wrote:
>> >
>> > > On Mon, Sep 15, 2025 at 12:13:47PM +0300, Ilpo Järvinen wrote:
>> > > > pci.c has been used as catch everything that doesn't fits elsewhere
>> > > > within PCI core and thus resizable BAR code has been placed there as
>> > > > well. Move Resizable BAR related code to a newly introduced rebar.c to
>> > > > reduce size of pci.c. After move, there are no pci_rebar_*() calls from
>> > > > pci.c indicating this is indeed well-defined subset of PCI core.
>> > > >
>> > > > Endpoint drivers perform Resizable BAR related operations which could
>> > > > well be performed by PCI core to simplify driver-side code. This
>> > > > series adds a few new API functions to that effect and converts the
>> > > > drivers to use the new APIs (in separate patches).
>> > > >
>> > > > While at it, also convert BAR sizes bitmask to u64 as PCIe spec already
>> > > > specifies more sizes than what will fit u32 to make the API typing more
>> > > > future-proof. The extra sizes beyond 128TB are not added at this point.
>> > > >
>> > > > These are based on pci/main plus a simple "adapter" patch to add the
>> > > > include for xe_vram_types.h that was added by a commit in drm-tip.
>> > > > Hopefully that is enough to avoid the within context conflict with
>> > > > BAR_SIZE_SHIFT removal to let the xe CI tests to be run for this
>> > > > series.
>> > > >
>> > > > There are two minor conflicts with the work in pci/resource but I'm
>> > > > hesitant to base this on top of it as this is otherwise entirely
>> > > > independent (and would likely prevent GPU CI tests as well). If we end
>> > > > up having to pull the bridge window select changes, there should be no
>> > > > reason why this does have to become collateral damage (so my
>> > > > suggestion, if this is good to go in this cycle, to take this into a
>> > > > separate branch than pci/resource and deal with those small conflicts
>> > > > while merging into pci/next).
>> > > >
>> > > > I've tested sysfs resize, i915, and xe BAR resizing functionality. In
>> > > > the case of xe, I did small hack patch as its resize is anyway broken
>> > > > as is because BAR0 pins the bridge window so resizing BAR2 fails. My
>> > > > hack caused other problems further down the road (likely because BAR0
>> > > > is in use by the driver so releasing it messed assumptions xe driver
>> > > > has) but the BAR resize itself was working which was all I was
>> > >
>> > > is the hack you mention here to release all BARs before attempting the
>> > > resize?
>> >
>> > Yes, the patch added release of BAR0 prior to resize. The existing xe code
>> > in _resize_bar() already releases BAR2.
>> >
>> > During resize, if the first loop in pbus_reassign_bridge_resources()
>> > (called from pci_resize_resource()) finds the bridge window closest to the
>> > endpoint still has a child, it results in having empty saved list because
>> > all upstream bridge windows will then have a child as well.
>> >
>> > Empty saved list is checked after the loop and
>> > pbus_reassign_bridge_resources() returns -ENOENT without even trying to
>> > assign the resources. The error is returned even if the actual bridge
>> > window size is large enough to fit the resized resource.
>> >
>> > The logic in pci_resize_resource() and pbus_reassign_bridge_resources()
>> > need some other improvements besides that problem, but I likely won't
>> > have time to look at that until completing the fitting algorithm changes.
>> > I'd actually want to add pci_release_and_resize_resource() which would
>> > take care of releasing all the resources of the device (obviously driver
>> > must have its hands off all those BARs when it calls that function). With
>> > the current pci_resize_resource() API, handling the restore of BARs in
>> > case of failure is not as robust as I'd like to make it.
>> >
>> > > > interested to know. I'm not planning to pursue fixing the pinning
>> > > > problem within xe driver because the core changes to consider maximum
>> > > > size of the resizable BARs should take care of the main problem by
>> > > > different means.
>> > >
>> > > I'd actually like to pursue that myself as that could be propagated to
>> > > stable since we do have some resize errors in xe with BMG that I wasn't
>> > > understanding. It's likely due to xe_mmio_probe_early() taking a hold of
>> > > BAR0 and not expecting it to be moved. We could either remap if we have
>> > > have to resize or just move the resize logic early on.
>> >
>> > Great. If you have any questions when it comes to the PCI core side code,
>> > please let me know.
>>
>> I moved the resize to happen before anything else in xe. However when
>> testing I noticed a scenario failing without involving the driver.
>> With and without this series I still have the same pass/failure
>> scenarios:
>>
>> Tests executed with a BMG. Just after boot, BAR2 is 16GB.
>>
>> 1) If I resize it via sysfs to 8GB and then load the driver, it resizes
>> it back. Resize from sysfs works too. No change in behavior.
>
>It's expected that resizing smaller size -> back to the original works
>through sysfs because the upstream window pins won't prevent reacquiring
>the same or less space.
>
>But the way resize is called from current xe code, sizing even to a
>smaller size fails because BAR0 pins the closest upstream window,
>resulting in -ENOENT as explained above. I don't see fixing this on core
>side as priority because I plan to rework the resizing code anyway and
>resizing to a smaller size doesn't seem overly useful use case.

that was not what I saw: for me it works without any additional patch if
all that is needed is to go back to the previously acquired large space.

In  other words, this works for me today with no extra changes:

# echo 8 > /sys/bus/pci/devices/0000\:03\:00.0/resource2_resize
# lspci -v -s 03:00.0 | grep -i mem
         Memory at 83000000 (64-bit, non-prefetchable) [size=16M]
         Memory at 4000000000 (64-bit, prefetchable) [size=256M]

# modprobe xe

# lspci -v -s 03:00.0 | grep -i mem
         Memory at 83000000 (64-bit, non-prefetchable) [size=16M]
         Memory at 4000000000 (64-bit, prefetchable) [size=16G]

>
>> 2) If I do "remove the bridge via sysfs and rescan the bus"[1], it fails to
>> resize (either automatically, on rescan, via sysfs, or loading the xe
>> driver). It just stays at 256M.
>
>This is because the larger resource sizes are only calculated on the
>actual resize call which occurs after the bridge windows were already
>sized on rescan to the smaller size. At that point, the critical bridge
>windows are already pinned in place and thus cannot be relocated to free
>area I assume there would be somewhere within 4000000000-7fffffffff.
>
>> The only thing that brings it back is a reboot. /proc/iomem shows this:
>>
>> 4000000000-7fffffffff : PCI Bus 0000:00
>>   4000000000-44007fffff : PCI Bus 0000:01
>>     4000000000-4017ffffff : PCI Bus 0000:02
>>       4000000000-400fffffff : PCI Bus 0000:03    <<<< BMG
>>         4000000000-400fffffff : 0000:03:00.0
>
>>       4010000000-40100fffff : PCI Bus 0000:04
>
>This pins 0000:01:00.0's window in place. And also prevents enlarging the
>siblings.

oh. I see my mistake. I removed 0000:04:00.0, but then we still have the
PCI Bus, so it's still pinned. If I rather remove its parent, then it works
with your additional pci quirk:

# echo 0 > /sys/bus/pci/drivers_autoprobe
# echo 1 > /sys/bus/pci/devices/0000\:01\:00.0/remove
# echo 1 > /sys/bus/pci/rescan
# # BAR2 is back to 256M as it couldn't resize to max
# lspci -v -s 03:00.0 | grep -i mem
         Memory at 83000000 (64-bit, non-prefetchable) [disabled] [size=16M]
         Memory at 4000000000 (64-bit, prefetchable) [disabled] [size=256M]

# echo 1 > /sys/bus/pci/devices/0000\:02\:02.0/remove

# # with my additional patch in xe (attached), but doing via sysfs also
# works
# echo 0000:03:00.0 > /sys/bus/pci/drivers/xe/bind
# dmesg 
...
xe 0000:03:00.0: [drm] Attempting to resize bar from 256MiB -> 16384MiB
xe 0000:03:00.0: BAR 0 [mem 0x83000000-0x83ffffff 64bit]: releasing
xe 0000:03:00.0: BAR 2 [mem 0x4000000000-0x400fffffff 64bit pref]: releasing
pcieport 0000:02:01.0: bridge window [mem 0x4000000000-0x400fffffff 64bit pref]: releasing
pcieport 0000:01:00.0: bridge window [mem 0x4000000000-0x4017ffffff 64bit pref]: releasing
pcieport 0000:00:01.0: bridge window [mem 0x4000000000-0x44007fffff 64bit pref]: releasing
pcieport 0000:00:01.0: bridge window [mem 0x4000000000-0x43ffffffff 64bit pref]: assigned
pcieport 0000:01:00.0: bridge window [mem 0x4000000000-0x43ffffffff 64bit pref]: assigned
pcieport 0000:02:01.0: bridge window [mem 0x4000000000-0x43ffffffff 64bit pref]: assigned
xe 0000:03:00.0: BAR 2 [mem 0x4000000000-0x43ffffffff 64bit pref]: assigned
xe 0000:03:00.0: BAR 0 [mem 0x83000000-0x83ffffff 64bit]: assigned
pcieport 0000:00:01.0: PCI bridge to [bus 01-04]
pcieport 0000:00:01.0:   bridge window [io  0x8000-0x9fff]
pcieport 0000:00:01.0:   bridge window [mem 0x83000000-0x840fffff]
pcieport 0000:00:01.0:   bridge window [mem 0x4000000000-0x43ffffffff 64bit pref]
pcieport 0000:01:00.0: PCI bridge to [bus 02-04]
pcieport 0000:01:00.0:   bridge window [io  0x8000-0x9fff]
pcieport 0000:01:00.0:   bridge window [mem 0x83000000-0x840fffff]
pcieport 0000:01:00.0:   bridge window [mem 0x4000000000-0x43ffffffff 64bit pref]
pcieport 0000:02:01.0: PCI bridge to [bus 03]
pcieport 0000:02:01.0:   bridge window [io  0x8000-0x8fff]
pcieport 0000:02:01.0:   bridge window [mem 0x83000000-0x83ffffff]
pcieport 0000:02:01.0:   bridge window [mem 0x4000000000-0x43ffffffff 64bit pref]
xe 0000:03:00.0: [drm] BAR2 resized to 16384M


>
>It would possible, though, to release it and still use sysfs to perform
>resize on 0000:03:00.0 as removing 0000:04:00.0 doesn't require removing
>0000:03:00.0. But...
>
>>     4018000000-40187fffff : 0000:01:00.0
>
>...This resource pins 0000:00:01.0's window in place. AFAIK, it cannot be
>released other than by removing 0000:01:00.0 which results in removing
>0000:03:00.0 as well, thus making it impossible to perform the BAR resize
>for 0000:03:00.0 through sysfs anymore. Catch-22.
>
>Could you test if the attached quirk patch helps. Maybe it could be
>considered as the interim solution until the bridge sizing logic becomes
>aware of the resizable BARs. To use a quirk to do this feels hacky to me,
>but then it's hard to point out any real downsides with that approach
>(other than having to quirk it).

it does help. Probably needs this in the commit message:

Link: https://lore.kernel.org/intel-xe/20250721173057.867829-1-uwu@icenowy.me/

and then possibly add the other PCI IDs for upstream ports as well.

>
>You'll still need to manually release 0000:04:00.0 but the BAR0 on the

As mentioned above, I needed to release its parent for that to work.

I have the xe patch on top of drm-tip as well as on top of this series
(attached). Conflicts are easy to solve, but I may split this patch to
avoid the conflicts to be able to merge it soon and propagate to stable.

>switch should be gone thanks to the quirk. When both of the window pins
>are gone, I think the resize through sysfs should work.
>
>> And dmesg shows this for the rescan:
>>
>> [ 1673.189737] pci 0000:01:00.0: [8086:e2ff] type 01 class 0x060400 PCIe
>> Switch Upstream Port
>> [ 1673.189794] pci 0000:01:00.0: BAR 0 [mem 0x00000000-0x007fffff 64bit pref]
>> [ 1673.189808] pci 0000:01:00.0: PCI bridge to [bus 00]
>> [ 1673.189824] pci 0000:01:00.0:   bridge window [io  0x0000-0x0fff]
>> [ 1673.189834] pci 0000:01:00.0:   bridge window [mem 0x00000000-0x000fffff]
>> [ 1673.189856] pci 0000:01:00.0:   bridge window [mem 0x00000000-0x000fffff
>> 64bit pref]
>> [ 1673.189878] pci 0000:01:00.0: Max Payload Size set to 256 (was 128, max
>> 256)
>> [ 1673.190164] pci 0000:01:00.0: PME# supported from D0 D3hot D3cold
>> [ 1673.193531] pci 0000:01:00.0: Adding to iommu group 16
>> [ 1673.196997] pcieport 0000:00:01.0: ASPM: current common clock configuration
>> is inconsistent, reconfiguring
>> [ 1673.197061] pci 0000:01:00.0: bridge configuration invalid ([bus 00-00]),
>> reconfiguring
>> [ 1673.197421] pci 0000:02:01.0: [8086:e2f0] type 01 class 0x060400 PCIe
>> Switch Downstream Port
>> [ 1673.197452] pci 0000:02:01.0: PCI bridge to [bus 00]
>> [ 1673.197463] pci 0000:02:01.0:   bridge window [io  0x0000-0x0fff]
>> [ 1673.197468] pci 0000:02:01.0:   bridge window [mem 0x00000000-0x000fffff]
>> [ 1673.197482] pci 0000:02:01.0:   bridge window [mem 0x00000000-0x000fffff
>> 64bit pref]
>> [ 1673.197497] pci 0000:02:01.0: Max Payload Size set to 256 (was 128, max
>> 256)
>> [ 1673.197503] pci 0000:02:01.0: enabling Extended Tags
>> [ 1673.197660] pci 0000:02:01.0: PME# supported from D0 D3hot D3cold
>> [ 1673.198411] pci 0000:02:01.0: Adding to iommu group 17
>> [ 1673.200258] pci 0000:02:02.0: [8086:e2f1] type 01 class 0x060400 PCIe
>> Switch Downstream Port
>> [ 1673.200289] pci 0000:02:02.0: PCI bridge to [bus 00]
>> [ 1673.200299] pci 0000:02:02.0:   bridge window [io  0x0000-0x0fff]
>> [ 1673.200304] pci 0000:02:02.0:   bridge window [mem 0x00000000-0x000fffff]
>> [ 1673.200317] pci 0000:02:02.0:   bridge window [mem 0x00000000-0x000fffff
>> 64bit pref]
>> [ 1673.200333] pci 0000:02:02.0: Max Payload Size set to 256 (was 128, max
>> 256)
>> [ 1673.200337] pci 0000:02:02.0: enabling Extended Tags
>> [ 1673.200470] pci 0000:02:02.0: PME# supported from D0 D3hot D3cold
>> [ 1673.201059] pci 0000:02:02.0: Adding to iommu group 18
>> [ 1673.202761] pci 0000:01:00.0: PCI bridge to [bus 02-04]
>> [ 1673.202774] pci 0000:02:01.0: bridge configuration invalid ([bus 00-00]),
>> reconfiguring
>> [ 1673.202782] pci 0000:02:02.0: bridge configuration invalid ([bus 00-00]),
>> reconfiguring
>> [ 1673.203024] pci 0000:03:00.0: [8086:e221] type 00 class 0x030000 PCIe
>> Endpoint
>> [ 1673.203060] pci 0000:03:00.0: BAR 0 [mem 0x00000000-0x00ffffff 64bit]
>> [ 1673.203064] pci 0000:03:00.0: BAR 2 [mem 0x00000000-0x0fffffff 64bit pref]
>> [ 1673.203069] pci 0000:03:00.0: ROM [mem 0x00000000-0x001fffff pref]
>> [ 1673.203077] pci 0000:03:00.0: Max Payload Size set to 256 (was 128, max
>> 256)
>> [ 1673.203209] pci 0000:03:00.0: PME# supported from D0 D3hot
>> [ 1673.203770] pci 0000:03:00.0: Adding to iommu group 19
>> [ 1673.205451] pci 0000:03:00.0: vgaarb: setting as boot VGA device
>> [ 1673.205454] pci 0000:03:00.0: vgaarb: bridge control possible
>> [ 1673.205455] pci 0000:03:00.0: vgaarb: VGA device added:
>> decodes=io+mem,owns=none,locks=none
>> [ 1673.205534] pci 0000:02:01.0: PCI bridge to [bus 03-04]
>> [ 1673.205543] pci_bus 0000:03: busn_res: [bus 03-04] end is updated to 03
>> [ 1673.205787] pci 0000:04:00.0: [8086:e2f7] type 00 class 0x040300 PCIe
>> Endpoint
>> [ 1673.205848] pci 0000:04:00.0: BAR 0 [mem 0x00000000-0x00003fff 64bit]
>> [ 1673.205867] pci 0000:04:00.0: Max Payload Size set to 256 (was 128, max
>> 256)
>> [ 1673.205872] pci 0000:04:00.0: enabling Extended Tags
>> [ 1673.206012] pci 0000:04:00.0: PME# supported from D3hot D3cold
>> [ 1673.206528] pci 0000:04:00.0: Adding to iommu group 20
>> [ 1673.208271] pci 0000:02:02.0: PCI bridge to [bus 04]
>> [ 1673.208284] pci_bus 0000:04: busn_res: [bus 04] end is updated to 04
>> [ 1673.208291] pci_bus 0000:02: busn_res: [bus 02-04] end is updated to 04
>> [ 1673.232003] pcieport 0000:00:01.0: Assigned bridge window [mem
>> 0x83000000-0x840fffff] to [bus 01-04] cannot fit 0x2000000 required for
>> 0000:02:01.0 bridging to [bus 03]
>> [ 1673.232009] pci 0000:02:01.0: bridge window [mem 0x00000000-0x000fffff] to
>> [bus 03] requires relaxed alignment rules
>> [ 1673.232016] pci 0000:02:01.0: bridge window [mem 0x01000000-0x01ffffff] to
>> [bus 03] add_size 200000 add_align 1000000
>> [ 1673.232020] pcieport 0000:00:01.0: Assigned bridge window [mem
>> 0x83000000-0x840fffff] to [bus 01-04] cannot fit 0x1800000 required for
>> 0000:01:00.0 bridging to [bus 02-04]
>> [ 1673.232025] pci 0000:01:00.0: bridge window [mem 0x00000000-0x000fffff] to
>> [bus 02-04] requires relaxed alignment rules
>> [ 1673.232027] pcieport 0000:00:01.0: Assigned bridge window [mem
>> 0x83000000-0x840fffff] to [bus 01-04] cannot fit 0x2000000 required for
>> 0000:01:00.0 bridging to [bus 02-04]
>> [ 1673.232031] pci 0000:01:00.0: bridge window [mem 0x00000000-0x000fffff] to
>> [bus 02-04] requires relaxed alignment rules
>> [ 1673.232036] pci 0000:01:00.0: bridge window [mem 0x01000000-0x020fffff] to
>> [bus 02-04] add_size 200000 add_align 1000000
>> [ 1673.232077] pci 0000:01:00.0: bridge window [mem 0x4000000000-0x4017ffffff
>> 64bit pref]: assigned
>> [ 1673.232080] pci 0000:01:00.0: bridge window [mem size 0x01300000]: can't
>> assign; no space
>> [ 1673.232082] pci 0000:01:00.0: bridge window [mem size 0x01300000]: failed
>> to assign
>> [ 1673.232090] pci 0000:01:00.0: BAR 0 [mem 0x4018000000-0x40187fffff 64bit
>> pref]: assigned
>> [ 1673.232103] pci 0000:01:00.0: bridge window [io  0x8000-0x9fff]: assigned
>> [ 1673.232129] pci 0000:01:00.0: bridge window [mem 0x83000000-0x840fffff]:
>> assigned
>> [ 1673.232131] pci 0000:01:00.0: bridge window [mem 0x83000000-0x840fffff]:
>> failed to expand by 0x200000
>> [ 1673.232136] pci 0000:01:00.0: bridge window [mem 0x83000000-0x840fffff]:
>> failed to add optional 200000
>> [ 1673.232192] pci 0000:02:01.0: bridge window [mem 0x4000000000-0x400fffffff
>> 64bit pref]: assigned
>> [ 1673.232196] pci 0000:02:01.0: bridge window [mem 0x83000000-0x83ffffff]:
>> assigned
>> [ 1673.232200] pci 0000:02:02.0: bridge window [mem 0x84000000-0x840fffff]:
>> assigned
>> [ 1673.232202] pci 0000:02:02.0: bridge window [mem 0x4010000000-0x40100fffff
>> 64bit pref]: assigned
>> [ 1673.232204] pci 0000:02:01.0: bridge window [io  0x8000-0x8fff]: assigned
>> [ 1673.232206] pci 0000:02:02.0: bridge window [io  0x9000-0x9fff]: assigned
>> [ 1673.232241] pci 0000:03:00.0: BAR 2 [mem 0x4000000000-0x400fffffff 64bit
>> pref]: assigned
>> [ 1673.232250] pci 0000:03:00.0: BAR 0 [mem 0x83000000-0x83ffffff 64bit]:
>> assigned
>> [ 1673.232259] pci 0000:03:00.0: ROM [mem size 0x00200000 pref]: can't assign;
>> no space
>> [ 1673.232261] pci 0000:03:00.0: ROM [mem size 0x00200000 pref]: failed to
>> assign
>> [ 1673.232272] pci 0000:03:00.0: BAR 2 [mem 0x4000000000-0x400fffffff 64bit
>> pref]: assigned
>> [ 1673.232280] pci 0000:03:00.0: BAR 0 [mem 0x83000000-0x83ffffff 64bit]:
>> assigned
>> [ 1673.232289] pci 0000:03:00.0: ROM [mem size 0x00200000 pref]: can't assign;
>> no space
>> [ 1673.232291] pci 0000:03:00.0: ROM [mem size 0x00200000 pref]: failed to
>> assign
>> [ 1673.232302] pci 0000:02:01.0: PCI bridge to [bus 03]
>> [ 1673.232304] pci 0000:02:01.0:   bridge window [io  0x8000-0x8fff]
>> [ 1673.232309] pci 0000:02:01.0:   bridge window [mem 0x83000000-0x83ffffff]
>> [ 1673.232313] pci 0000:02:01.0:   bridge window [mem
>> 0x4000000000-0x400fffffff 64bit pref]
>> [ 1673.232321] pci 0000:04:00.0: BAR 0 [mem 0x84000000-0x84003fff 64bit]:
>> assigned
>> [ 1673.232336] pci 0000:02:02.0: PCI bridge to [bus 04]
>> [ 1673.232339] pci 0000:02:02.0:   bridge window [io  0x9000-0x9fff]
>> [ 1673.232345] pci 0000:02:02.0:   bridge window [mem 0x84000000-0x840fffff]
>> [ 1673.232349] pci 0000:02:02.0:   bridge window [mem
>> 0x4010000000-0x40100fffff 64bit pref]
>> [ 1673.232356] pci 0000:01:00.0: PCI bridge to [bus 02-04]
>> [ 1673.232359] pci 0000:01:00.0:   bridge window [io  0x8000-0x9fff]
>> [ 1673.232363] pci 0000:01:00.0:   bridge window [mem 0x83000000-0x840fffff]
>> [ 1673.232366] pci 0000:01:00.0:   bridge window [mem
>> 0x4000000000-0x4017ffffff 64bit pref]
>> [ 1673.232471] pcieport 0000:01:00.0: enabling device (0000 -> 0003)
>> [ 1673.233508] pcieport 0000:02:01.0: enabling device (0000 -> 0003)
>> [ 1673.233692] pcieport 0000:02:02.0: enabling device (0000 -> 0003)
>>
>> # echo 9 > /sys/bus/pci/devices/0000\:03\:00.0/resource2_resize -bash: echo:
>> write error: No space left on device
>>
>>
>> [1] # echo 1 > /sys/bus/pci/devices/0000\:01\:00.0/remove
>>     # echo 0 > /sys/bus/pci/drivers_autoprobe
>>     # echo 1 > /sys/bus/pci/rescan
>>
>>
>> I can share the xe patch so you check if it at least fixes it in your
>> test scenario.
>
>Ah, one thing I didn't remember mention is that in my case the BAR is
>already at its maximum size, so to test the resize is working, I made
>the target size smaller, not larger. (I understand this might not be very
>helpful in your case but I was only interested that resize code still
>works after this series).
>
>-- 
> i.

>From 948a49f01df54b3435861138a0eae85bb2c3f1f3 Mon Sep 17 00:00:00 2001
>From: =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= <ilpo.jarvinen@linux.intel.com>
>Date: Wed, 17 Sep 2025 15:24:53 +0300
>Subject: [PATCH 1/1] PCI: Release BAR0 of an integrated bridge to allow GPU
> BAR resize
>MIME-Version: 1.0
>Content-Type: text/plain; charset=UTF-8
>Content-Transfer-Encoding: 8bit
>
>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.demarchi@intel.com>
>Link: https://lore.kernel.org/linux-pci/fl6tx5ztvttg7txmz2ps7oyd745wg3lwcp3h7esmvnyg26n44y@owo2ojiu2mov/
>Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
>---
>
>This feels quite hacky to me and I'm working towards a better solution
>which is to consider Resizable BAR maximum size the resource fitting
>algorithm. But then, I don't expect the better solution to be something
>we want to push into stable due to extremely invasive dependencies. So
>maybe consider this an interim/legacy solution to the resizing problem
>and remove it once the algorithmic approach works (or more precisely
>retain it only in the old kernel versions).
>---
> drivers/pci/quirks.c | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
>diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
>index d97335a40193..98a4f0a1285b 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);
>
>base-commit: 8f5ae30d69d7543eee0d70083daf4de8fe15d585
>-- 
>2.39.5
>


[-- Attachment #2: 0001-drm-xe-Move-rebar-support.patch --]
[-- Type: text/plain, Size: 12246 bytes --]

From 353ab1ff93a483154273cd2ded85e5f2190bcedb Mon Sep 17 00:00:00 2001
From: Lucas De Marchi <lucas.demarchi@intel.com>
Date: Mon, 15 Sep 2025 14:36:28 -0700
Subject: [PATCH] drm/xe: Move rebar support
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Create a xe_pci_rebar.c to contain the logic about resizing the lmembar.
Trying to do a resize later inside xe_vram is way too late. At that time
the BAR0 will already be mapped for register access and the driver would
need to remap to continue working.

All the rebar logic is more pci-specific than xe-specific and can be
done very early in the probe sequence, resulting in messages like below,

	[] xe 0000:03:00.0: vgaarb: deactivate vga console
	[] xe 0000:03:00.0: [drm] Attempting to resize bar from 8192MiB -> 16384MiB
	[] xe 0000:03:00.0: BAR 0 [mem 0x83000000-0x83ffffff 64bit]: releasing
	[] xe 0000:03:00.0: BAR 2 [mem 0x4000000000-0x41ffffffff 64bit pref]: releasing
	[] pcieport 0000:02:01.0: bridge window [mem 0x4000000000-0x41ffffffff 64bit pref]: releasing
	[] pcieport 0000:01:00.0: bridge window [mem 0x4000000000-0x41ffffffff 64bit pref]: releasing
	[] pcieport 0000:01:00.0: bridge window [mem 0x4000000000-0x43ffffffff 64bit pref]: assigned
	[] pcieport 0000:02:01.0: bridge window [mem 0x4000000000-0x43ffffffff 64bit pref]: assigned
	[] xe 0000:03:00.0: BAR 2 [mem 0x4000000000-0x43ffffffff 64bit pref]: assigned
	[] xe 0000:03:00.0: BAR 0 [mem 0x83000000-0x83ffffff 64bit]: assigned
	[] pcieport 0000:00:01.0: PCI bridge to [bus 01-04]
	[] pcieport 0000:00:01.0:   bridge window [mem 0x83000000-0x840fffff]
	[] pcieport 0000:00:01.0:   bridge window [mem 0x4000000000-0x44007fffff 64bit pref]
	[] pcieport 0000:01:00.0: PCI bridge to [bus 02-04]
	[] pcieport 0000:01:00.0:   bridge window [mem 0x83000000-0x840fffff]
	[] pcieport 0000:01:00.0:   bridge window [mem 0x4000000000-0x43ffffffff 64bit pref]
	[] pcieport 0000:02:01.0: PCI bridge to [bus 03]
	[] pcieport 0000:02:01.0:   bridge window [mem 0x83000000-0x83ffffff]
	[] pcieport 0000:02:01.0:   bridge window [mem 0x4000000000-0x43ffffffff 64bit pref]
	[] xe 0000:03:00.0: [drm] BAR2 resized to 16384M
	[] xe 0000:03:00.0: [drm:xe_pci_probe [xe]] BATTLEMAGE  e221:0000 dgfx:1 gfx:Xe2_HPG (20.02) ...

As shown above, it happens even before we try to read any register for
platform identification. With that move, the BAR0 won't be in use by the
driver and it can be released prior to the resize, avoiding the
shortcomings of how pbus_reassign_bridge_resources() handles that case.
Improving pbus_reassign_bridge_resources() is something to be done, but
it wouldn't be able to fix this case since xe was already using BAR0.

Cc: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Cc: <stable@vger.kernel.org> # 6.12+
Link: https://lore.kernel.org/intel-xe/fafda2a3-fc63-ce97-d22b-803f771a4d19@linux.intel.com
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>

---

Tested with some BAR resizes prior to loading xe and also with a SBR
which makes the BMG's BAR2 to come back as 256M when rescanning the bus
---
 drivers/gpu/drm/xe/Makefile       |   1 +
 drivers/gpu/drm/xe/xe_pci.c       |   3 +
 drivers/gpu/drm/xe/xe_pci_rebar.c | 123 ++++++++++++++++++++++++++++++
 drivers/gpu/drm/xe/xe_pci_rebar.h |  13 ++++
 drivers/gpu/drm/xe/xe_vram.c      |  98 +-----------------------
 5 files changed, 141 insertions(+), 97 deletions(-)
 create mode 100644 drivers/gpu/drm/xe/xe_pci_rebar.c
 create mode 100644 drivers/gpu/drm/xe/xe_pci_rebar.h

diff --git a/drivers/gpu/drm/xe/Makefile b/drivers/gpu/drm/xe/Makefile
index 7a065c98a3b85..5a66d7a53d0db 100644
--- a/drivers/gpu/drm/xe/Makefile
+++ b/drivers/gpu/drm/xe/Makefile
@@ -95,6 +95,7 @@ xe-y += xe_bb.o \
 	xe_observation.o \
 	xe_pat.o \
 	xe_pci.o \
+	xe_pci_rebar.o \
 	xe_pcode.o \
 	xe_pm.o \
 	xe_preempt_fence.o \
diff --git a/drivers/gpu/drm/xe/xe_pci.c b/drivers/gpu/drm/xe/xe_pci.c
index 701ba9baa9d7e..6cc5e7b6901a8 100644
--- a/drivers/gpu/drm/xe/xe_pci.c
+++ b/drivers/gpu/drm/xe/xe_pci.c
@@ -27,6 +27,7 @@
 #include "xe_macros.h"
 #include "xe_mmio.h"
 #include "xe_module.h"
+#include "xe_pci_rebar.h"
 #include "xe_pci_sriov.h"
 #include "xe_pci_types.h"
 #include "xe_pm.h"
@@ -866,6 +867,8 @@ static int xe_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
 	if (err)
 		return err;
 
+	xe_pci_rebar(xe);
+
 	err = xe_device_probe_early(xe);
 	/*
 	 * In Boot Survivability mode, no drm card is exposed and driver
diff --git a/drivers/gpu/drm/xe/xe_pci_rebar.c b/drivers/gpu/drm/xe/xe_pci_rebar.c
new file mode 100644
index 0000000000000..3487845596d88
--- /dev/null
+++ b/drivers/gpu/drm/xe/xe_pci_rebar.c
@@ -0,0 +1,123 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2025 Intel Corporation
+ */
+
+#include "xe_pci_rebar.h"
+
+#include <linux/pci.h>
+#include <linux/types.h>
+
+#include <drm/drm_print.h>
+
+#include "regs/xe_bars.h"
+#include "xe_device_types.h"
+#include "xe_module.h"
+
+#define BAR_SIZE_SHIFT 20
+
+static void release_bars(struct pci_dev *pdev)
+{
+	int resno;
+
+	for (resno = PCI_STD_RESOURCES; resno < PCI_STD_RESOURCE_END; resno++) {
+		if (pci_resource_len(pdev, resno))
+			pci_release_resource(pdev, resno);
+	}
+}
+
+static void resize_bar(struct xe_device *xe, int resno, resource_size_t size)
+{
+	struct pci_dev *pdev = to_pci_dev(xe->drm.dev);
+	int bar_size = pci_rebar_bytes_to_size(size);
+	int ret;
+
+	release_bars(pdev);
+
+	ret = pci_resize_resource(pdev, resno, bar_size);
+	if (ret) {
+		drm_info(&xe->drm, "Failed to resize BAR%d to %dM (%pe). Consider enabling 'Resizable BAR' support in your BIOS\n",
+			 resno, 1 << bar_size, ERR_PTR(ret));
+		return;
+	}
+
+	drm_info(&xe->drm, "BAR%d resized to %dM\n", resno, 1 << bar_size);
+}
+
+void xe_pci_rebar(struct xe_device *xe)
+{
+	int force_vram_bar_size = xe_modparam.force_vram_bar_size;
+	struct pci_dev *pdev = to_pci_dev(xe->drm.dev);
+	struct pci_bus *root = pdev->bus;
+	resource_size_t current_size;
+	resource_size_t rebar_size;
+	struct resource *root_res;
+	int max_size, i;
+	u32 pci_cmd;
+
+	/* gather some relevant info */
+	current_size = pci_resource_len(pdev, LMEM_BAR);
+
+	/*
+	 * Handle force_vram_bar_size:
+	 * - negative: resize is disabled
+	 * - 0: try to resize to maximum possible
+	 * - positive: resize to specific value
+	 */
+
+	if (force_vram_bar_size < 0)
+		return;
+
+	/* set to a specific size? */
+	if (force_vram_bar_size) {
+		rebar_size = pci_rebar_bytes_to_size(force_vram_bar_size *
+						     (resource_size_t)SZ_1M);
+
+		if (!pci_rebar_size_supported(pdev, LMEM_BAR, rebar_size)) {
+			drm_info(&xe->drm,
+				 "Requested size: %lluMiB is not supported by rebar sizes: 0x%llx. Leaving default: %lluMiB\n",
+				 (u64)pci_rebar_size_to_bytes(rebar_size) >> 20,
+				 pci_rebar_get_possible_sizes(pdev, LMEM_BAR),
+				 (u64)current_size >> 20);
+			return;
+		}
+
+		rebar_size = pci_rebar_size_to_bytes(rebar_size);
+		if (rebar_size == current_size)
+			return;
+	} else {
+		max_size = pci_rebar_get_max_size(pdev, LMEM_BAR);
+		if (max_size < 0)
+			return;
+		rebar_size = pci_rebar_size_to_bytes(max_size);
+
+		/* only resize if larger than current */
+		if (rebar_size <= current_size)
+			return;
+	}
+
+	drm_info(&xe->drm, "Attempting to resize bar from %lluMiB -> %lluMiB\n",
+		 (u64)current_size >> 20, (u64)rebar_size >> 20);
+
+	while (root->parent)
+		root = root->parent;
+
+	pci_bus_for_each_resource(root, root_res, i) {
+		if (root_res && root_res->flags & (IORESOURCE_MEM | IORESOURCE_MEM_64) &&
+		    (u64)root_res->start > 0x100000000ul)
+			break;
+	}
+
+	if (!root_res) {
+		drm_info(&xe->drm, "Can't resize VRAM BAR - platform support is missing. Consider enabling 'Resizable BAR' support in your BIOS\n");
+		return;
+	}
+
+	pci_read_config_dword(pdev, PCI_COMMAND, &pci_cmd);
+	pci_write_config_dword(pdev, PCI_COMMAND, pci_cmd & ~PCI_COMMAND_MEMORY);
+
+	resize_bar(xe, LMEM_BAR, rebar_size);
+
+	pci_assign_unassigned_bus_resources(pdev->bus);
+	pci_write_config_dword(pdev, PCI_COMMAND, pci_cmd);
+}
diff --git a/drivers/gpu/drm/xe/xe_pci_rebar.h b/drivers/gpu/drm/xe/xe_pci_rebar.h
new file mode 100644
index 0000000000000..c87aa58aee718
--- /dev/null
+++ b/drivers/gpu/drm/xe/xe_pci_rebar.h
@@ -0,0 +1,13 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2025 Intel Corporation
+ */
+
+#ifndef _XE_PCI_REBAR_H_
+#define _XE_PCI_REBAR_H_
+
+struct xe_device;
+
+void xe_pci_rebar(struct xe_device *xe);
+
+#endif
diff --git a/drivers/gpu/drm/xe/xe_vram.c b/drivers/gpu/drm/xe/xe_vram.c
index f182326688106..989cf705f1b17 100644
--- a/drivers/gpu/drm/xe/xe_vram.c
+++ b/drivers/gpu/drm/xe/xe_vram.c
@@ -24,101 +24,6 @@
 #include "xe_vram.h"
 #include "xe_vram_types.h"
 
-static void
-_resize_bar(struct xe_device *xe, int resno, resource_size_t size)
-{
-	struct pci_dev *pdev = to_pci_dev(xe->drm.dev);
-	int bar_size = pci_rebar_bytes_to_size(size);
-	int ret;
-
-	if (pci_resource_len(pdev, resno))
-		pci_release_resource(pdev, resno);
-
-	ret = pci_resize_resource(pdev, resno, bar_size);
-	if (ret) {
-		drm_info(&xe->drm, "Failed to resize BAR%d to %dM (%pe). Consider enabling 'Resizable BAR' support in your BIOS\n",
-			 resno, 1 << bar_size, ERR_PTR(ret));
-		return;
-	}
-
-	drm_info(&xe->drm, "BAR%d resized to %dM\n", resno, 1 << bar_size);
-}
-
-/*
- * if force_vram_bar_size is set, attempt to set to the requested size
- * else set to maximum possible size
- */
-static void resize_vram_bar(struct xe_device *xe)
-{
-	int force_vram_bar_size = xe_modparam.force_vram_bar_size;
-	struct pci_dev *pdev = to_pci_dev(xe->drm.dev);
-	struct pci_bus *root = pdev->bus;
-	resource_size_t current_size;
-	resource_size_t rebar_size;
-	struct resource *root_res;
-	int max_size, i;
-	u32 pci_cmd;
-
-	/* gather some relevant info */
-	current_size = pci_resource_len(pdev, LMEM_BAR);
-
-	if (force_vram_bar_size < 0)
-		return;
-
-	/* set to a specific size? */
-	if (force_vram_bar_size) {
-		rebar_size = pci_rebar_bytes_to_size(force_vram_bar_size *
-						     (resource_size_t)SZ_1M);
-
-		if (!pci_rebar_size_supported(pdev, LMEM_BAR, rebar_size)) {
-			drm_info(&xe->drm,
-				 "Requested size: %lluMiB is not supported by rebar sizes: 0x%llx. Leaving default: %lluMiB\n",
-				 (u64)pci_rebar_size_to_bytes(rebar_size) >> 20,
-				 pci_rebar_get_possible_sizes(pdev, LMEM_BAR),
-				 (u64)current_size >> 20);
-			return;
-		}
-
-		rebar_size = pci_rebar_size_to_bytes(rebar_size);
-		if (rebar_size == current_size)
-			return;
-	} else {
-		max_size = pci_rebar_get_max_size(pdev, LMEM_BAR);
-		if (max_size < 0)
-			return;
-		rebar_size = pci_rebar_size_to_bytes(max_size);
-
-		/* only resize if larger than current */
-		if (rebar_size <= current_size)
-			return;
-	}
-
-	drm_info(&xe->drm, "Attempting to resize bar from %lluMiB -> %lluMiB\n",
-		 (u64)current_size >> 20, (u64)rebar_size >> 20);
-
-	while (root->parent)
-		root = root->parent;
-
-	pci_bus_for_each_resource(root, root_res, i) {
-		if (root_res && root_res->flags & (IORESOURCE_MEM | IORESOURCE_MEM_64) &&
-		    (u64)root_res->start > 0x100000000ul)
-			break;
-	}
-
-	if (!root_res) {
-		drm_info(&xe->drm, "Can't resize VRAM BAR - platform support is missing. Consider enabling 'Resizable BAR' support in your BIOS\n");
-		return;
-	}
-
-	pci_read_config_dword(pdev, PCI_COMMAND, &pci_cmd);
-	pci_write_config_dword(pdev, PCI_COMMAND, pci_cmd & ~PCI_COMMAND_MEMORY);
-
-	_resize_bar(xe, LMEM_BAR, rebar_size);
-
-	pci_assign_unassigned_bus_resources(pdev->bus);
-	pci_write_config_dword(pdev, PCI_COMMAND, pci_cmd);
-}
-
 static bool resource_is_valid(struct pci_dev *pdev, int bar)
 {
 	if (!pci_resource_flags(pdev, bar))
@@ -142,8 +47,6 @@ static int determine_lmem_bar_size(struct xe_device *xe, struct xe_vram_region *
 		return -ENXIO;
 	}
 
-	resize_vram_bar(xe);
-
 	lmem_bar->io_start = pci_resource_start(pdev, LMEM_BAR);
 	lmem_bar->io_size = pci_resource_len(pdev, LMEM_BAR);
 	if (!lmem_bar->io_size)
@@ -366,6 +269,7 @@ int xe_vram_probe(struct xe_device *xe)
 	err = determine_lmem_bar_size(xe, &lmem_bar);
 	if (err)
 		return err;
+
 	drm_info(&xe->drm, "VISIBLE VRAM: %pa, %pa\n", &lmem_bar.io_start, &lmem_bar.io_size);
 
 	remain_io_size = lmem_bar.io_size;
-- 
2.50.1