On Tue, Jun 25, 2019 at 09:48:19PM +1000, Benjamin Herrenschmidt wrote: > On Tue, 2019-06-25 at 13:05 +0300, Mika Westerberg wrote: > > > We only every distribute resources when using > > > pci_assign_unassigned_bridge_resources which we only use some cases, > > > and it's completely non obvious why we would use it there and not in > > > other places. > > > > We added it only for native PCIe hotplug path with the assumption that > > the boot firmware takes care of the initial resource allocation. I don't > > see any particular reason why it could not be called for other paths as > > well, though. > > Ok, we need to look into this for all the platforms who just reassign > everything in Linux (ie, ignore whatever the boot firmware did, if it > did anything). > > I feel like all these platforms today will have a hard time getting > anything useful out of hotplug with our default "2M" add to the hotplug > bridges :) Yeah, at least if Thunderbolt is involved each "daisy-chained" device adds a complete PCIe switch running out of resources rather quick. > > > We also don't distribute during the initial root survey meaning afaik > > > that we get toast for any hotplug bridge that has stuff already there > > > at boot. > > > > The boot firmware obviously needs to follow the same logic. AFAICT > > recent PCs and Macs using native PCIe hotplug handle it. > > What's your experience in that area ? How (well) do they handle it in > the boot firmware ? at least on arm64, boot firmwares are rather > catastrophic when it comes to PCI, and on other embedded devices they > are basically non-existent. Well my experience is quite limited to recent Macs and PCs which usually handle the initial resource allocation just fine. In case of Thunderbolt some "older" PCs handle everything in firmware, even the runtime resource allocation via SMI handler accompanied with ACPI hotplug.
