Patch Set 9:
Kyösti,
your concern seems to be mostly about "why do this at all?" rather than "is this the right approach to do and integrate it?", so that's what I'm responding to here:
Well I literally wrote this: "I am not at all convinced completely bypassing PCI probing and removing nodes from devicetree is the way to proceed, whatever the design requirements are."
The overhead of probing PCI device ID and keeping the node in devicetree is pretty minimal. I had suggested to only probe for PCI BDF already present in static devicetree instead of doing the full scan of 32 devices(potentially times 8 functioncs), if that couple milliseconds is of importance there.
One can probe the device IDs, keep the device PCI configuration space accessible, and still leave all standard PCI BARs unprogrammed and bypass all device init.
The development here is not orthogonal to 64-bit MMIO resource support; for payloads other than kernel one needs to make decisions what BARs are boot-critical and must be located in MMIO window below 4 GiB. That would serve/solve environments other than linux-as-a-payload too. I wonder if majority of those requesting better PCI resource allocations have just fundamentally stated that large (>256MiB) prefetch frame buffers don't work well with coreboot... IMHO development efforts should go here instead.
The requirement is to pursue the original vision of having a minimal piece of code that gets the hardware into a state that Linux can take over. Ron never went away from that goal, and he pursued it on and off over time.
And I am questioning if that original vision is viable with contemporary hardware. My impression is that there is an increasing amount of platform customisation present in devicetree.cb files, but maybe a lot of that is just passed to blobs instead of having coreboot proper do the actual register writes. I would not be surprised if those blobs temporarily opened up some BARs. I would rather not see a solution of MINIMAL_PCI_SCANNING that only works with FSP blobs and fails for those who still have open-source chipset configuration and need some resources assigned.
I also popped the question about dynamically created PCI methods in ACPI namespace. Is there anything critical or important there? Like PIRQ/MSI-X/GSI/IOAPIC routing information that OS drivers could not resolve without firmware assistance? I imagine it could be tricky for static platform .asl to assign properties (PME,hotplug?) to PCI devices whose generation is delayed to OS. ASL is not really my thing, this is just one more aspect where proof-of-concept runs on overly-simplified qemu-q35 might not fault or highlight issues.
To view, visit change 36221. To unsubscribe, or for help writing mail filters, visit settings.