On 6/2/25 4:08 PM, Ilpo Järvinen wrote: >>> I think I figured out more about the reason. It's not related to that >>> bridge window resource. >>> >>> pbus_size_mem() will add also that ROM resource into realloc_head >>> as it is considered (intentionally) optional after the optional change >>> (as per "tudor: 2:" line). And that resource is never assigned because cut >>> pdev_sort_resources() didn't pick it up into the head list. The next >>> question is why the ROM resource isn't in the head list. >>> >> It seems the ROM resource is skipped at: >> https://web.git.kernel.org/pub/scm/linux/kernel/git/next/linux- >> next.git/tree/drivers/pci/setup-bus.c#n175 >> >> tudor: pdev_sort_resources: ROM [??? 0x00000000 flags 0x0] resource >> skipped due to !(r->flags) || r->parent > I don't see the device in this print, hope it is for the same device. > > In any case, I don't understand what reset resource's flags in between > pbus_size_mem() and pdev_sort_resources(), or alternative, why type > checking in pbus_size_mem() matches if flags == 0 at that point. > > Those two functions should work on the same resources, if one skips > something, the other should too. Disparity between them can cause issues, > but despite reading the code multiple times, I couldn't figure out how > that disparity occurs (except for the !pdev_resources_assignable() case). cut > It is of interest to know why the same resource is treated differently. > So what were the resource flags, type* args when it's processed by > pbus_size_mem()? If resource's flags are zero at that point but it matches This is the full output: https://termbin.com/mn1x for the following prints: https://termbin.com/q57h It seems ROM resource is of type 2 at pbus_size_mem() time. > one of the types, that would be a bug. I'll give another try tomorrow. Thanks, ta
