Re: [REGRESSION] PCI: Dynamic OF node creation hangs on invalid bridge configuration

[Bjorn Helgaas <helgaas@kernel.org>]

On Mon, Sep 14, 2026 at 11:28:45PM +0000, Angel J wrote:
> Ok, here it is...
> 
> I tested this quirk on Linux 6.18.44 with CONFIG_PCI_DYNAMIC_OF_NODES=y,
> and it boots without either OF fix. The diff below omits the test logging.
> 
> PCI_FIXUP_HEADER runs after the resources have been parsed using the
> original header type, and changing hdr_type also affects configuration
> restore. I don't know enough about this part of PCI to judge whether
> that's safe, so I'll wait for your advice before submitting it as a patch.
> 
> Thanks,
> Angel J
> 
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index de9bbccda..57df88a38 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -291,6 +291,22 @@ static int __init pci_apply_final_quirks(void)
>  }
>  fs_initcall_sync(pci_apply_final_quirks);
>  
> 
> +/*
> + * On the Dell XPS 8940, 8086:4c43 reports a PCI-to-PCI bridge but has no
> + * downstream bus. Use host-bridge class and a normal header so that
> + * pci_is_bridge() does not send it through bridge scanning.
> + */
> +static void quirk_intel_4c43_host_bridge(struct pci_dev *dev)
> +{
> +	if ((dev->class >> 8) != PCI_CLASS_BRIDGE_PCI ||
> +	    dev->hdr_type != PCI_HEADER_TYPE_BRIDGE)
> +		return;
> +
> +	dev->class = (PCI_CLASS_BRIDGE_HOST << 8) | (dev->class & 0xff);
> +	dev->hdr_type = PCI_HEADER_TYPE_NORMAL;
> +}
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x4c43, quirk_intel_4c43_host_bridge);

I think your of_property patch is better because it removes some
assumptions made in the of_pci_make_dev_node() path about what things
in the pci_dev are valid.  It's quite legal for a device to have a
Type 1 header (so pci_is_bridge() is true), but have no pci_bus below
it, e.g., a bridge on bus 0 with Secondary Bus Number also being 0.

I don't know what happened in this particular case, whether the
Secondary Bus Number and Subordinate Bus Numbers are hard-wired to
0xff or what (per spec, both should be read/write).  Maybe the system
"lspci -vv" and/or complete dmesg log would have a clue.

But I do think it's better if we don't assume that every pci_dev with
a Type 1 header has a pci_bus allocated.