> ok, I get the point. Overall this will make it a bit more work for people who want to try minimal scanning out, but at the same time, there are very few people, I guess, who want to try minimal scanning out :-)
>
> I'll look at that tomorrow, it will basically flip the sense of the code but should not be a big deal and should do what you suggest.
I am in the favour of opting-out, and let's not forget that PCI subsystem code is unaware of the structure of register banks behind PCI device BARs, so we could make a ruling that only the PCI driver context is allowed to access the PCI device resources.
How do you feel about the statements below:
1. PCI devices that do not bind to PCI drivers can always implicitly opt-out, because nobody is going to access those BARs.
2. Most external/add-on PCIe devices located behind PCIe bridges would hit rule #1. This includes those troublsome PCIe graphics with large PREFMEM resources.
3. With the recursive nature of how .read_resources already works, upstream PCIe bridges would implicitly opt-out in the case all the secondary side devices have opted out.
4. Within PCI drivers, .init is the only callback where resource assignment may be required.
5. If .init is not implemented at all, we can implicitly opt-out.
6. If .init does not call any find_resource(), we can explicitly opt-out by using alternative .read_resources() implementation with a conditional MINIMAL_PCI_RESOURCES check in it.
7. If .init does call find_resource(), it's likely for the reason that does configurations that are dependent of either some Kconfig or devicetree.cb. Or it could be a static chipset configuration that is not easy to delay to payload. These devices can rarely opt-out, but it could be done explicitly using custom .read_resources() like rule #6.
8. Platforms with blobbed chipset initialisation would currently likely hit rule #6, but it might be possible to have them hit #5 instead by removing .init callbacks. I have not looked into them really.
9. If choice of payload is capable of completing the resource allocation, possibly extending to 64-bit MMIO space, it may be desirable to leave as many resources as possible unallocated and potentially even unallocate the ones that had been assigned.
To view, visit change 36221. To unsubscribe, or for help writing mail filters, visit settings.