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

[Bjorn Helgaas]

On Wed, Sep 16, 2026 at 11:14:25AM +0000, Angel J wrote:
> Hi Bjorn, Andrea,
> 
> Thanks, that clears it up. I agree the of_property fix is simpler. If a
> Type 1 device can legitimately have no bus below it, I don't see a reason
> to change its class or header just to avoid that case.

Yes.  And I suspect this affects more than just the [8086:4c43]
device, so I think it will be easier if we don't have to list
individual devices for a quirk.  I think it's very common to have this
kind of bridge for Intel uncore at bridge 0xff or 0x7f.

> On Tuesday, September 15th, 2026 at 18:21, Bjorn Helgaas <helgaas@xxxxxxxxxx> wrote:
> 
> > 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.
> >