kernel/linux.git/drivers/pci/setup-res.c, branch v6.19.11

PCI: Move Resizable BAR code to rebar.c

2025-11-14T18:34:21+00:00

For lack of a 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 functions, increasing the code size. As pci.c is huge as is, move the Resizable BAR related code and the BAR resize code from setup-res.c to rebar.c. Signed-off-by: Ilpo Järvinen Signed-off-by: Bjorn Helgaas Reviewed-by: Christian König Link: https://patch.msgid.link/20251113180053.27944-2-ilpo.jarvinen@linux.intel.com

PCI: Add kerneldoc for pci_resize_resource()

2025-11-14T18:33:21+00:00

As pci_resize_resource() is meant to be used also outside of PCI core, document the interface with kerneldoc. Signed-off-by: Ilpo Järvinen Signed-off-by: Bjorn Helgaas Tested-by: Alex Bennée # AVA, AMD GPU Link: https://patch.msgid.link/20251113162628.5946-8-ilpo.jarvinen@linux.intel.com

PCI: Fix restoring BARs on BAR resize rollback path

2025-11-14T18:33:14+00:00

BAR resize operation is implemented in the pci_resize_resource() and pbus_reassign_bridge_resources() functions. pci_resize_resource() can be called either from __resource_resize_store() from sysfs or directly by the driver for the Endpoint Device. The pci_resize_resource() requires that caller has released the device resources that share the bridge window with the BAR to be resized as otherwise the bridge window is pinned in place and cannot be changed. pbus_reassign_bridge_resources() rolls back resources if the resize operation fails, but rollback is performed only for the bridge windows. Because releasing the device resources are done by the caller of the BAR resize interface, these functions performing the BAR resize do not have access to the device resources as they were before the resize. pbus_reassign_bridge_resources() could try __pci_bridge_assign_resources() after rolling back the bridge windows as they were, however, it will not guarantee the resource are assigned due to differences in how FW and the kernel assign the resources (alignment of the start address and tail). To perform rollback robustly, the BAR resize interface has to be altered to also release the device resources that share the bridge window with the BAR to be resized. Also, remove restoring from the entries failed list as saved list should now contain both the bridge windows and device resources so the extra restore is duplicated work. Some drivers (currently only amdgpu) want to prevent releasing some resources. Add exclude_bars param to pci_resize_resource() and make amdgpu pass its register BAR (BAR 2 or 5), which should never be released during resize operation. Normally 64-bit prefetchable resources do not share a bridge window with the 32-bit only register BAR, but there are various fallbacks in the resource assignment logic which may make the resources share the bridge window in rare cases. This change (together with the driver side changes) is to counter the resource releases that had to be done to prevent resource tree corruption in the ("PCI: Release assigned resource before restoring them") change. As such, it likely restores functionality in cases where device resources were released to avoid resource tree conflicts which appeared to be "working" when such conflicts were not correctly detected by the kernel. Reported-by: Simon Richter Link: https://lore.kernel.org/linux-pci/f9a8c975-f5d3-4dd2-988e-4371a1433a60@hogyros.de/ Reported-by: Alex Bennée Link: https://lore.kernel.org/linux-pci/874irqop6b.fsf@draig.linaro.org/ Signed-off-by: Ilpo Järvinen [bhelgaas: squash amdgpu BAR selection from https://lore.kernel.org/r/20251114103053.13778-1-ilpo.jarvinen@linux.intel.com] Signed-off-by: Bjorn Helgaas Tested-by: Alex Bennée # AVA, AMD GPU Reviewed-by: Christian König Link: https://patch.msgid.link/20251113162628.5946-7-ilpo.jarvinen@linux.intel.com

PCI/IOV: Adjust ->barsz[] when changing BAR size

2025-11-14T18:32:47+00:00

pci_rebar_set_size() adjusts BAR size for both normal and IOV BARs. The struct pci_sriov keeps a cached copy of BAR size in ->barsz[] which is not adjusted by pci_rebar_set_size() but by pci_iov_resource_set_size(). pci_iov_resource_set_size() is called also from pci_resize_resource_set_size(). The current arrangement is problematic once BAR resize algorithm starts to roll back changes properly in case of a failure. The normal resource fitting algorithm rolls back resource size using the struct pci_dev_resource easily but also calling pci_resize_resource_set_size() or pci_iov_resource_set_size() to roll back BAR size would be an extra burden, whereas combining ->barsz[] update with pci_rebar_set_size() naturally rolls back it when restoring the old BAR size on a different layer of the BAR resize operation. Thus, rework pci_rebar_set_size() to also update ->barsz[]. Signed-off-by: Ilpo Järvinen Signed-off-by: Bjorn Helgaas Tested-by: Alex Bennée # AVA, AMD GPU Link: https://patch.msgid.link/20251113162628.5946-3-ilpo.jarvinen@linux.intel.com

PCI: Fix finding bridge window in pci_reassign_bridge_resources()

2025-09-16T16:19:31+00:00

pci_reassign_bridge_resources() walks upwards in the PCI bus hierarchy, locates the relevant bridge window on each level using flags check, and attempts to release the bridge window. The flags-based check is fragile due to various fallbacks in the bridge window selection logic. As such, the algorithm might not locate the correct bridge window. Refactor pci_reassign_bridge_resources() to determine the correct bridge window using pbus_select_window(), which contains logic to handle all fallback cases correctly. Change function prefix to pbus as it now inputs struct bus and resource for which to locate the bridge window. The main purpose is to make bridge window selection logic consistent across the entire PCI core (one step at a time). While this technically also fixes the commit 8bb705e3e79d ("PCI: Add pci_resize_resource() for resizing BARs") making the bridge window walk algorithm more robust, the normal setup having a 64-bit resizable BAR underneath bridge(s) with 64-bit prefetchable windows does not need to use any fallbacks. As such, the practical impact is low (requiring BAR resize use case and a non-typical bridge device). The way to detect if unrelated resource failed again is left to use the type based approximation which should not behave worse than before. Fixes: 8bb705e3e79d ("PCI: Add pci_resize_resource() for resizing BARs") Signed-off-by: Ilpo Järvinen Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20250829131113.36754-14-ilpo.jarvinen@linux.intel.com

PCI: Preserve bridge window resource type flags

2025-09-16T16:19:18+00:00

When a bridge window is found unused or fails to assign, the flags of the associated resource are cleared. Clearing flags is problematic as it also removes the type information of the resource which is needed later. Thus, always preserve the bridge window type flags and use IORESOURCE_UNSET and IORESOURCE_DISABLED to indicate the status of the bridge window. Also, when initializing resources, make sure all valid bridge windows do get their type flags set. Change various places that relied on resource flags being cleared to check for IORESOURCE_UNSET and IORESOURCE_DISABLED to allow bridge window resource to retain their type flags. Add pdev_resource_assignable() and pdev_resource_should_fit() helpers to filter out disabled bridge windows during resource fitting; the latter combines more common checks into the helper. When reading the bridge windows from the registers, instead of leaving the resource flags cleared for bridge windows that are not enabled, always set up the flags and set IORESOURCE_UNSET | IORESOURCE_DISABLED as needed. When resource fitting or assignment fails for a bridge window resource, or the bridge window is not needed, mark the resource with IORESOURCE_UNSET or IORESOURCE_DISABLED, respectively. Use dummy zero resource in resource_show() for backwards compatibility as lspci will otherwise misrepresent disabled bridge windows. This change fixes an issue which highlights the importance of keeping the resource type flags intact: At the end of __assign_resources_sorted(), reset_resource() is called, previously clearing the flags. Later, pci_prepare_next_assign_round() attempted to release bridge resources using pci_bus_release_bridge_resources() that calls into pci_bridge_release_resources() that assumes type flags are still present. As type flags were cleared, IORESOURCE_MEM_64 was not set leading to resources under an incorrect bridge window to be released (idx = 1 instead of idx = 2). While the assignments performed later covered this problem so that the wrongly released resources got assigned in the end, it was still causing extra release+assign pairs. There are other reasons why the resource flags should be retained in upcoming changes too. Removing the flag reset for non-bridge window resource is left as future work, in part because it has a much higher regression potential due to pci_enable_resources() that will start to work also for those resources then and due to what endpoint drivers might assume about resources. Despite the Fixes tag, backporting this (at least any time soon) is highly discouraged. The issue fixed is borderline cosmetic as the later assignments normally cover the problem entirely. Also there might be non-obvious dependencies. Fixes: 5b28541552ef ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources") Signed-off-by: Ilpo Järvinen Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20250829131113.36754-11-ilpo.jarvinen@linux.intel.com

PCI: Enable bridge even if bridge window fails to assign

2025-09-16T16:19:13+00:00

A normal PCI bridge has multiple bridge windows and not all of them are always required by devices underneath the bridge. If a Root Port or bridge does not have a device underneath, no bridge windows get assigned. Yet, pci_enable_resources() is set to fail indiscriminantly on any resource assignment failure if the resource is not known to be optional. In practice, the code in pci_enable_resources() is currently largely dormant. The kernel sets resource flags to zero for any unused bridge window and resets flags to zero in case of an resource assignment failure, which short-circuits pci_enable_resources() because of this check: if (!(r->flags & (IORESOURCE_IO | IORESOURCE_MEM))) continue; However, an upcoming change to resource flags will alter how bridge window resource flags behave activating these long dormants checks in pci_enable_resources(). While complex logic could be built to selectively enable a bridge only under some conditions, a few versions of such logic were tried during development of this change and none of them worked satisfactorily. Thus, I just gave up and decided to enable any bridge regardless of the bridge windows as there seems to be no clear benefit from not enabling it, but a major downside as pcieport will not be probed for the bridge if it's not enabled. Therefore, change pci_enable_resources() to not check if bridge window resources remain unassigned. Resource assignment failures are pretty noisy already so there is no need to log that for bridge windows in pci_enable_resources(). Ignoring bridge window failures hopefully prevents an obvious source of regressions when the upcoming change that no longer clears resource flags for bridge windows is enacted. I've hit this problem even during my own testing on multiple occasions so I expect it to be a quite common problem. This can always be revisited later if somebody thinks the enable check for bridges is not strict enough, but expect a mind-boggling number of regressions from such a change. Signed-off-by: Ilpo Järvinen Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20250829131113.36754-10-ilpo.jarvinen@linux.intel.com

PCI: Use pci_release_resource() instead of release_resource()

2025-09-16T16:19:10+00:00

A few places in setup-bus.c call release_resource() directly and end up duplicating functionality from pci_release_resource() such as parent check, logging, and clearing the resource. Worse yet, the way the resource is cleared is inconsistent between different sites. Convert release_resource() calls into pci_release_resource() to remove code duplication. This will also make the resource start, end, and flags behavior consistent, i.e., start address is cleared, and only IORESOURCE_UNSET is asserted for the resource. While at it, eliminate the unnecessary initialization of idx variable in pci_bridge_release_resources(). Signed-off-by: Ilpo Järvinen Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20250829131113.36754-9-ilpo.jarvinen@linux.intel.com

PCI/IOV: Allow IOV resources to be resized in pci_resize_resource()

2025-07-14T20:04:18+00:00

Similar to regular resizable BARs, VF BARs can also be resized. The capability layout is the same as PCI_EXT_CAP_ID_REBAR, which means we can reuse most of the implementation, the only difference being resource size calculation (which is multiplied by total VFs) and memory decoding (which is controlled by a separate VF MSE field in SR-IOV cap). Extend the pci_resize_resource() function to accept IOV resources. See PCIe r6.2, sec 7.8.7. Signed-off-by: Michał Winiarski Signed-off-by: Bjorn Helgaas Reviewed-by: Ilpo Järvinen Link: https://patch.msgid.link/20250702093522.518099-4-michal.winiarski@intel.com

PCI: Do not claim to release resource falsely

2025-03-07T17:26:19+00:00

pci_release_resource() will print "... releasing" regardless of the resource being assigned or not. Move the print after the res->parent check to avoid claiming the kernel would be releasing an unassigned resource. Likely, none of the current callers pass a resource that is unassigned so this change is mostly to correct the non-sensical order than to remove errorneous printouts. Link: https://lore.kernel.org/r/20250307140922.5776-1-ilpo.jarvinen@linux.intel.com Signed-off-by: Ilpo Järvinen Signed-off-by: Bjorn Helgaas