I agree resource allocator to be very limited (MEM and PREFMEM particularly), yet I have not seen serious attemps of previously mentioned companies fixing it themselves or contracting anyone familiar with the subsystem to work on the topic.

Please list your design requirements rather than saying "this is a requested feature by 4 companies". Is it only about the 32bit MMIO space or maybe also the some dozen milliseconds lost in ramstage probing for PCI devices that could never ever be present?

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.

4 comments:

File src/Kconfig:
- Patch Set #9, Line 340: default y if ARCH_X86
  Why the arch dependency?
- Patch Set #9, Line 348: help
  This option should only be visible for boards with devicetree.cb files modified to have 'mandatory' entries.
  Also:
```
   depends on PCI
```
File src/device/pci_device.c:
- Patch Set #8, Line 1191: dev = pcidev_path_behind(bus, devfn);
  yes it should. And it will. […]
  Can you give links to reviews of these past "bikeshedded passes" because I don't remember reviewing much PCI related changes on this topic. And both Subrata and You are saying this is not related to that "move payload loader into postcar" change that possibly was bikeshedded for a good reason.
- Patch Set #8, Line 1229: *prev = dev->sibling;
  yes we are.
  To skip scanning of devices also affects ACPI namespace. You would probably still need some way of communicating certain platform details (power management events come to mind) from the firmware. You possibly end up creating more static .asl files and that might get very ugly with PCI bifurcation/coalesce.
  I think ACPI does not reference PCI buses by secondary numbers, but you probably should not create (obsolete) MP tables at all if PCI busses are not enumerated.

To view, visit change 36221. To unsubscribe, or for help writing mail filters, visit settings.