Patch Set 12:
(1 comment)
Patch Set 11:
(1 comment)
for the read_resources approach, could I do this;
in the standard read_resources, if CONFIG_MINIMAL_PCI_SCANNING is set, I just return
and then add a new function
read_resources_always
which does not test CONFIG_MINIMAL_PCI_SCANNING?It would be nice to do this without changing the whole tree, at least until we know if it works.
I would want to see a solution that does not break when payload is other than kernel or TianoCore. That means a complete PCI tree enumeration and only leaving the problematic resources unassigned.
To maintain the boot diversity and leave a choice of payload to the 'user', I would hate to see SoC vendors telling their platforms now require MINIMAL_PCI_SCANNING=y to boot at all.
Those problematic resources can often be classified as PREFMEM and >= 64MiB in size. Often, they would also be graphics, so they might not be boot-critical for common payloads like SeaBIOS and GRUB. Does it matter when payload screen does not appear on 4 screens?
Currently, there should be few of these problematic resources within integrated PCI devices. The number of drivers where .read_resources needs to change is small, maybe even limited to that USB4/ThunderBolt. But Jeremy investigated even that could have generic solution by checking for some PCIe capability blocks? To handle all this ill-resource detection in pci_dev_read_resources() would take care of anonymous add-on PCIe cards too.
To view, visit change 36221. To unsubscribe, or for help writing mail filters, visit settings.