Re: [PATCH 1/2] PCI: Setup bridge resources earlier

[Val Packett]

On 10/10/25 2:01 PM, Ilpo Järvinen wrote:

> [..]
> Even if you were very likely joking here, I'm still sorry for breaking it,
> no matter which company's device.
>
> Perhaps I'll start Cc you in all upcoming resource changes as you seem to
> be so willing to volunteer to review them. ;-D

Perhaps Intel corporate could pay me for QAing the patches :D

> There seem to be cases where pci_assign_unassigned_root_bus_resources()
> executes for bus 0000:04 before 0004:01:00.0 is scanned as it is only
> recorded later.
>
> Hmm, qcom_pcie_global_irq_thread() seems to indicate the real enumeration
> can only occur after the link up event has arrived, and it starts another
> scan from there.

Right, I've even seen things about the link-up sequence in the commits 
for the PCIe driver, e.g. 4581403f6792 ("PCI: qcom: Enumerate endpoints 
based on Link up event in 'global_irq' interrupt").

Is this really that uncommon? Can we be sure that other drivers don't 
behave similarly?

> Perhaps this could be solved by inhibiting resource sizing and assignment
> per host bridge until the bus could be enumerated for real. Otherwise the
> resource assignment has no idea how the bridge windows should be sized
> which then can lead to this cornering itself if the initial assignment
> without knowledge of the necessary sizes.
>
> Could you please try if the patch below helps?
> [..]
> @@ -1825,6 +1826,8 @@ static int qcom_pcie_probe(struct platform_device *pdev)
>   		bridge->sysdata = cfg;
>   		bridge->ops = (struct pci_ops *)&pci_qcom_ecam_ops.pci_ops;
>   		bridge->msi_domain = true;
> +		// FIXME: Should this be specific to just some host bridges?
> +		bridge->enumeration_pending = 1;
>   
>   		ret = pci_host_probe(bridge);
>   		if (ret)

..and nope, particularly that assignment did not run because at least on 
x1e, the bridges are not firmware_managed, so they are enumerated normally.

~val