David Gibson <da...@gibson.dropbear.id.au> writes: > On Thu, Jul 16, 2020 at 12:32:44PM +0200, Greg Kurz wrote: >> On Thu, 16 Jul 2020 14:45:40 +1000 >> David Gibson <da...@gibson.dropbear.id.au> wrote: >> >> > On Thu, Jul 09, 2020 at 07:12:47PM +0200, Greg Kurz wrote: >> > > Some recent error handling cleanups unveiled issues with our support of >> > > PCI bridges: >> > > >> > > 1) QEMU aborts when using non-standard PCI bridge types, >> > > unveiled by commit 7ef1553dac "spapr_pci: Drop some dead error >> > > handling" >> > > >> > > $ qemu-system-ppc64 -M pseries -device pcie-pci-bridge >> > > Unexpected error in object_property_find() at qom/object.c:1240: >> > > qemu-system-ppc64: -device pcie-pci-bridge: Property '.chassis_nr' not >> > > found >> > > Aborted (core dumped) >> > >> > Oops, I thought we had a check that we actually had a "pci-bridge" >> > device before continuing with the hotplug, but I guess not. >> >> Ah... are you suggesting we should explicitly check the actual type >> of the bridge rather than looking for the "chassis_nr" property ? > > Uh.. I thought about it, but I don't think it matters much which way > we do it.
Would it make sense to add the "chassis_nr" property to *all* PCI bridge devices? [...]
