Re: [PATCH 24/25] PCI: Perform reset_resource() and build fail list in sync

[Tudor Ambarus]

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