So why is this driver only valid in those cases?

In D53202#1215346, @imp wrote:

So why is this driver only valid in those cases?

The panic is that it tries to do pci_get_vendor() on pcib0 (child of acpi0) and that isn't a valid IVAR and the accessor panics. In particular, note that this driver is expecting to call tb_pcib_find_ident on its parent, and tb_pcib_find_ident assumes the device it is operating on is a PCI device with a device ID, etc. That isn't true for host bridges that are children of ACPI or OFW, etc.

Also, FWIW, this just fixes a panic when the probe routine runs against pci0 on my laptop. Later when the driver tries to attach to the actual Thunderbolt slots in my laptop it panics in a different way (the attach still fails as it does post-boot, and I get a different form of a race with the interrupt handler that still results in an interrupt handler raising a GPF, presumably due to dereferencing freed memory field with 0xdeadc0de as in the other review),

Though a better answer to the question is that this bus driver is meant to take over PCI buses that are children of TB ports, and the only way to know (currently) if a given pcib device is a TB port is to check its PCI IDs. Alternatively, TB bridges could expose some sort of new IVAR that this driver could check for instead. That would be more inline with, say, the ACPI PCI bus driver which checks for the presence of a valid ACPI_HANDLE IVAR that ACPI pcib drivers provide. Maybe we could have a new TB_GEN IVAR that TB bridges would export to children. That would perhaps be cleaner solution to this.