While I think Kyösti is right, that should handle problematic
resources more directly, I don't see this would lead to a
"minimal scanning" requirement. And if it does, we'll give
them time until the next release to fix it.

Ron, if you want to pursue the course of patch set 13, there still need to be some safeguards added:

• As MINIMAL_PCI_SCANNING (can we find a better name? MINIMAL_PCI_RESOURCES?) likely breaks any platform that isn't prepared for it, how about adding another Kconfig, selected by prepared platforms and let the former depend on it.
• Unless we want to review every driver with a `.init` function if it can work without resources or runs into undefined behaviour, we should only call `.init` if `.read_resources` wasn't blocked. I guess we'll have to add some tag to `struct device`. This still means we'd have to review platform code that already avoids our devicetree model and accesses devices directly, e.g. with pci_dev_on_root(). Hmmm, same for `.final`.

Here's another thought, how we could avoid trouble: Instead
of opting out of minimal-scanning per device, we could opt in.
For instance, if MINIMAL_PCI_SCANNING is enabled, use a
pci_dev_optional_read_resource() by default, and every driver
that supports it, could use it too, but would have to do so
explicitly.

View Change

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