kernel/linux.git/drivers/pci/setup-bus.c, branch v7.2-rc6

PCI: Remove const removal cast

2026-06-23T17:08:51+00:00

__pci_bridge_assign_resources() inputs const pci_dev *bridge, but then immediately casts const away to pass the bridge to pdev_assign_resources_sorted(). As pdev_assign_resources_sorted() performs assignment of resources, it is not possible to make its input parameter to const. Neither of the __pci_bridge_assign_resources() callers requires the bridge parameter to be const. Thus, simply remove the out of place cast and convert the input parameter to non-const. Signed-off-by: Ilpo Järvinen Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260429122617.7324-5-ilpo.jarvinen@linux.intel.com

PCI: Consolidate add_list (aka realloc_head) empty sanity checks

2026-06-23T17:08:21+00:00

Callers of __pci_bridge_assign_resources() and __pci_bus_assign_resources() perform WARN_ON_ONCE(list_empty(add_list))) checks to sanity check that all optional sizes were processed (and removed) from the list. The empty list sanity check is duplicated code so the more appropriate place for it would be inside the called function. Placing the empty list check into __pci_bus_assign_resources() also ensures all callsites do perform the sanity check which currently is not the case when being called from enable_slot(). This inconsistency was noted by Sashiko though only inside its in depth log but not flagged as a real problem, possibly because this is only a sanity check that should never fire. Nonetheless, this sanity check has been very useful to catch problems early in the past so it's good to do it consistently everywhere. As __pci_bus_assign_resources() is a recursive function, it needs to be renamed to __pci_bus_assign_resources_one() to only perform the empty list check at the end of processing the entire hierarchy in __pci_bus_assign_resources(). Suggested-by: sashiko.dev # Sanity check missing from enable_slot() Signed-off-by: Ilpo Järvinen Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260429122617.7324-4-ilpo.jarvinen@linux.intel.com

PCI: Rename 'added' to 'add_list'

2026-06-23T17:07:04+00:00

The resource fitting algorithm uses different names from the list holding the optional sizes: added, add_head, add_list, and realloc_head. 'add_list' sounds the most natural and some of the related variables also use 'add' such as 'add_size'. To reduce variation, rename 'added' and 'add_head' to 'add_list'. Also rename some 'realloc_head' cases selectively to 'add_list'. While it would be nice to rename every 'realloc_head' to 'add_list' for consistency, it might create a backport headache with all the work going into this algorithm that may need to be eventually backported. Thus, it's better to leave 'realloc_head' as is for now. Signed-off-by: Ilpo Järvinen Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260429122617.7324-3-ilpo.jarvinen@linux.intel.com

PCI: Fix alignment calculation for resource size larger than align

2026-03-27T15:19:08+00:00

The commit bc75c8e50711 ("PCI: Rewrite bridge window head alignment function") did not use if (r_size <= align) check from pbus_size_mem() for the new head alignment bookkeeping structure (aligns2[]). In some configurations, this can result in producing a gap into the bridge window which the resource larger than its alignment cannot fill. The old alignment calculation algorithm was removed by the subsequent commit 3958bf16e2fe ("PCI: Stop over-estimating bridge window size") which renamed the aligns2[] array leaving only aligns[] array. Add the if (r_size <= align) check back to avoid this problem. Fixes: bc75c8e50711 ("PCI: Rewrite bridge window head alignment function") Reported-by: Guenter Roeck Closes: https://lore.kernel.org/all/b05a6f14-979d-42c9-924c-d8408cb12ae7@roeck-us.net/ Signed-off-by: Ilpo Järvinen Signed-off-by: Bjorn Helgaas Tested-by: Xifer Link: https://patch.msgid.link/20260324165633.4583-11-ilpo.jarvinen@linux.intel.com

PCI: Rename window_alignment() to pci_min_window_alignment()

2026-03-27T15:19:08+00:00

window_alignment() lacks prefix. Rename it to pci_min_window_alignment() in order to include the prefix and also add min to indicate the returned window alignment is the minimum PCI spec and arch allows. Also make it available in drivers/pci/pci.h as upcoming changes will need to call it from outside of setup-bus.c. Signed-off-by: Ilpo Järvinen Signed-off-by: Bjorn Helgaas Tested-by: Xifer Link: https://patch.msgid.link/20260324165633.4583-9-ilpo.jarvinen@linux.intel.com

PCI: Fix premature removal from realloc_head list during resource assignment

2026-03-26T20:00:39+00:00

reassign_resources_sorted() checks for two things: a) Resource assignment failures for mandatory resources by checking if the resource remains unassigned, which are known to always repeat, and does not attempt to assign them again. b) That resource is not among the ones being processed/assigned at this stage, leading to skip processing such resources in reassign_resources_sorted() as well (resource assignment progresses one PCI hierarchy level at a time). The problem here is that a) is checked before b), but b) also implies the resource is not being assigned yet, making also a) true. As a) only skips resource assignment but still removes the resource from realloc_head, the later stages that would need to process the information in realloc_head cannot obtain the optional size information anymore. This leads to considering only non-optional part for bridge windows deeper in the PCI hierarchy. This problem has been observed during rescan (add_size is not considered while attempting assignment for 0000:e2:00.0 indicating the corresponding entry was removed from realloc_head while processing resource assignments for 0000:e1): pci_bus 0000:e1: scanning bus ... pci 0000:e3:01.0: bridge window [mem 0x800000000-0x1000ffffff 64bit pref] to [bus e4] add_size 60c000000 add_align 800000000 pci 0000:e3:01.0: bridge window [mem 0x00100000-0x000fffff] to [bus e4] add_size 200000 add_align 200000 pci 0000:e3:02.0: disabling bridge window [mem 0x00000000-0x000fffff 64bit pref] to [bus e5] (unused) pci 0000:e2:00.0: bridge window [mem 0x800000000-0x1000ffffff 64bit pref] to [bus e3-e5] add_size 60c000000 add_align 800000000 pci 0000:e2:00.0: bridge window [mem 0x00100000-0x001fffff] to [bus e3-e5] add_size 200000 add_align 200000 pcieport 0000:e1:02.0: bridge window [io size 0x2000]: can't assign; no space pcieport 0000:e1:02.0: bridge window [io size 0x2000]: failed to assign pcieport 0000:e1:02.0: bridge window [io 0x1000-0x2fff]: resource restored pcieport 0000:e1:02.0: bridge window [io 0x1000-0x2fff]: resource restored pcieport 0000:e1:02.0: bridge window [io size 0x2000]: can't assign; no space pcieport 0000:e1:02.0: bridge window [io size 0x2000]: failed to assign pci 0000:e2:00.0: bridge window [mem 0x28f000000000-0x28f800ffffff 64bit pref]: assigned Fixes: 96336ec70264 ("PCI: Perform reset_resource() and build fail list in sync") Reported-by: Peter Nisbet Signed-off-by: Ilpo Järvinen Signed-off-by: Bjorn Helgaas Tested-by: Peter Nisbet Link: https://patch.msgid.link/20260313084551.1934-1-ilpo.jarvinen@linux.intel.com

PCI: Prevent shrinking bridge window from its required size

2026-03-26T19:30:21+00:00

Steve reported an eGPU (either Radeon Instinct MI50 32GB or NVIDIA 3080 10GB) connected via Thunderbolt was not assigned sufficient BAR space in v6.11, so the amdgpu and nvidia drivers were unable to initialize the device. pci_bridge_distribute_available_resources() -> ... -> adjust_bridge_window() is called between __pci_bus_size_bridges() and assigning the resources. Since the commit 948675736a77 ("PCI: Allow adjust_bridge_window() to shrink resource if necessary") adjust_bridge_window() can also shrink the bridge window. The shrunken size, however, conflicts with what __pci_bus_size_bridges() -> pbus_size_mem() calculated as the required bridge window size. By shrinking the size, adjust_bridge_window() prevents the rest of the resource fitting algorithm from working as intended. Resource fitting logic is expecting assignment failures when bridge windows need resizing, but there are cases where failures are no longer happening after the commit 948675736a77 ("PCI: Allow adjust_bridge_window() to shrink resource if necessary"). The commit 948675736a77 ("PCI: Allow adjust_bridge_window() to shrink resource if necessary") justifies the change by the extra reservation made due to hpmemsize parameter, however, the kernel code contradicts that statement. (For simplicity, finer-grained hpmmiosize and hpmmiopref parameters that can be used to the same effect as hpmemsize are ignored in this description.) pbus_size_mem() calls calculate_memsize() twice. First with add_size=0 to find out the minimal required resource size. The second call occurs with add_size=hpmemsize (effectively) but the result does not directly affect the resource size only resulting in an entry on the realloc_head list (a.k.a. add_list). Yet, adjust_bridge_window() directly changes the resource size which does not include what is reserved due to hpmemsize. Also, if the required size for the bridge window exceeds hpmemsize, the parameter does not have any effect even on the second size calculation made by pbus_size_mem(); from calculate_memsize(): size = max(size, add_size) + children_add_size; The commit ae4611f1d7e9 ("PCI: Set resource size directly in adjust_bridge_window()") that precedes the commit 948675736a77 ("PCI: Allow adjust_bridge_window() to shrink resource if necessary") is also related to causing this problem. Its changelog explicitly states adjust_bridge_window() wants to "guarantee" allocation success. Guaranteed allocations, however, are incompatible with how the other parts of the resource fitting algorithm work. The given justification fails to explain why guaranteed allocations at this stage are required nor why forcing window to a smaller value than what was calculated by pbus_size_mem() is correct. While the change might have worked by chance in some test scenario, too small bridge window does not "guarantee" success from the point of view of the endpoint device resource assignments. No issue is mentioned within the changelog so it's unclear if the change was made to fix some observed issue nor and what that issue was. The unwanted shrinking of a bridge window occurs, e.g., when a device with large BARs such as eGPU is attached using Thunderbolt and the Root Port holds less than enough resource space for the eGPU. The GPU resources are in order of GBs and the default hotplug allocation is a mere 2MB (DEFAULT_HOTPLUG_MMIO_PREF_SIZE). The problem is illustrated by this log (filtered to the relevant content only): pci 0000:00:07.0: PCI bridge to [bus 03-2c] pci 0000:00:07.0: bridge window [mem 0x6000000000-0x601bffffff 64bit pref] pci 0000:03:00.0: PCI bridge to [bus 00] pci 0000:03:00.0: bridge window [mem 0x00000000-0x000fffff 64bit pref] pci 0000:03:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring pci 0000:03:00.0: PCI bridge to [bus 04-2c] pcieport 0000:00:07.0: Assigned bridge window [mem 0x6000000000-0x601bffffff 64bit pref] to [bus 03-2c] cannot fit 0xc00000000 required for 0000:03:00.0 bridging to [bus 04-2c] pci 0000:03:00.0: bridge window [mem 0x800000000-0x10003fffff 64bit pref] to [bus 04-2c] add_size 100000 add_align 100000 pcieport 0000:00:07.0: distributing available resources pci 0000:03:00.0: bridge window [mem 0x800000000-0x10003fffff 64bit pref] shrunken by 0x00000007e4400000 pci 0000:03:00.0: bridge window [mem 0x6000000000-0x601bffffff 64bit pref]: assigned The initial size of the Root Port's window is 448MB (0x601bffffff - 0x6000000000). __pci_bus_size_bridges() -> pbus_size_mem() calculates the required size to be 32772 MB (0x10003fffff - 0x800000000) which would fit the eGPU resources. adjust_bridge_window() then shrinks the bridge window down to what is guaranteed to fit into the Root Port's bridge window. The bridge window for 03:00.0 is also eliminated from the add_list (a.k.a. realloc_head) list by adjust_bridge_window(). After adjustment, the resources are assigned and as the bridge window for 03:00.0 is assigned successfully, no failure is recorded. Without a failure, no attempt to resize the window of the Root Port is required. The end result is eGPU not having large enough resources to work. The commit 948675736a77 ("PCI: Allow adjust_bridge_window() to shrink resource if necessary") also claims nested bridge windows are sized the same, which is false. pbus_size_mem() calculates the size for the parent bridge window by summing all the downstream resources so the resource fitting calculates larger bridge window for the parent to accommodate the childen. That is, hpmemsize does not result the same size for the case where there are nested bridge windows. In order to fix the most immediate problem, don't shrink the resource size in adjust_bridge_window() as hpmemsize had nothing to do with it. When considering add_size, only reduce it up to what is added due to hpmemsize (if required size is larger than hpmemsize, the parameter has no impact, see calculate_memsize()). Unfortunately, if the tail of the bridge window was aligned in calculate_memsize() from below hpmemsize to above it, the size check will falsely match but the check at least errs to the side of caution. There's not enough information available in adjust_bridge_window() to know the calculated size precisely. This is not exactly a revert of the commits e4611f1d7e9 ("PCI: Set resource size directly in adjust_bridge_window()") and 948675736a77 ("PCI: Allow adjust_bridge_window() to shrink resource if necessary") as shrinking still remains in place but is implemented differently, and the end result behaves very differently. It is possible that those two commits fixed some other issue that is not described with enough detail in the changelog and undoing parts of them results in another regression due to behavioral change. Nonetheless, as described above, the solution by those two commits was flawed and the issue, if one exists, should be solved in a way that is compatible with the rest of the resource fitting algorithm instead of working against it. Besides shrinking, the case where adjust_bridge_window() expands the bridge window is likely somewhat wrong as well because it removes the entry from add_list (a.k.a. realloc_head), but it is less damaging as that only impacts optional resources and may have no impact if expanding by hpmemsize is larger than what add_size was. Fixing it is left as further work. Fixes: 948675736a77 ("PCI: Allow adjust_bridge_window() to shrink resource if necessary") Fixes: ae4611f1d7e9 ("PCI: Set resource size directly in adjust_bridge_window()") Reported-by: Steve Oswald Closes: https://lore.kernel.org/linux-pci/CAN95MYEaO8QYYL=5cN19nv_qDGuuP5QOD17pD_ed6a7UqFVZ-g@mail.gmail.com/ Signed-off-by: Ilpo Järvinen Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260219153951.68869-1-ilpo.jarvinen@linux.intel.com

Convert 'alloc_obj' family to use the new default GFP_KERNEL argument

2026-02-22T01:09:51+00:00

This was done entirely with mindless brute force, using git grep -l '\

treewide: Replace kmalloc with kmalloc_obj for non-scalar types

2026-02-21T09:02:28+00:00

This is the result of running the Coccinelle script from scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to avoid scalar types (which need careful case-by-case checking), and instead replace kmalloc-family calls that allocate struct or union object instances: Single allocations: kmalloc(sizeof(TYPE), ...) are replaced with: kmalloc_obj(TYPE, ...) Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...) are replaced with: kmalloc_objs(TYPE, COUNT, ...) Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...) are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...) (where TYPE may also be *VAR) The resulting allocations no longer return "void *", instead returning "TYPE *". Signed-off-by: Kees Cook

PCI: Account fully optional bridge windows correctly

2026-02-19T21:33:40+00:00

pbus_size_mem_optional() adds dev_res->add_size of a bridge window into children_add_size when the window has a non-optional part. However, if the bridge window is fully optional, only r_size is added (which is zero for such a window). Also, a second dev_res entry will be added by pci_dev_res_add_to_list() into realloc_head for the bridge window (resulting in triggering the realloc_head-must-be-fully-consumed sanity check after a single pass of the resource assignment algorithm): WARNING: drivers/pci/setup-bus.c:2153 at pci_assign_unassigned_root_bus_resources+0xa5/0x260 Correct these problems by always adding dev_res->add_size for bridge windows and not calling pci_dev_res_add_to_list() if the dev_res entry exists. Fixes: 6a5e64c75e82 ("PCI: Add pbus_mem_size_optional() to handle optional sizes") Reported-by: RavitejaX Veesam Signed-off-by: Ilpo Järvinen Signed-off-by: Bjorn Helgaas Tested-by: RavitejaX Veesam Link: https://patch.msgid.link/20260218223419.22366-1-ilpo.jarvinen@linux.intel.com