On Thu, Jan 31, 2013 at 9:33 AM, Thomas Petazzoni <thomas.petazzoni@xxxxxxxxxxxxxxxxxx> wrote: > Dear Bjorn Helgaas, > > On Thu, 31 Jan 2013 09:30:07 -0700, Bjorn Helgaas wrote: > >> > Following you're recommendation, I've changed this, and left those >> > values initialized to 0 by default, in order to let Linux set correct >> > values. Yes, Linux does assign appropriate values in the Secondary Bus >> > Number Register. But before that Linux also complains loudly that the >> > bridge configuration is invalid: >> > >> > pci 0000:00:01.0: bridge configuration invalid ([bus 00-00]), reconfiguring >> > pci 0000:00:02.0: bridge configuration invalid ([bus 00-00]), reconfiguring >> > pci 0000:00:03.0: bridge configuration invalid ([bus 00-00]), reconfiguring >> > pci 0000:00:04.0: bridge configuration invalid ([bus 00-00]), reconfiguring >> > pci 0000:00:05.0: bridge configuration invalid ([bus 00-00]), reconfiguring >> > pci 0000:00:06.0: bridge configuration invalid ([bus 00-00]), reconfiguring >> >> Linux makes the unwarranted assumption that the PCI hierarchy has >> already been configured by firmware. If the only problem is the >> messages above, I think we could just rework the message so it doesn't >> look like an error. I would guess that we probably also see the same >> distressing message when we hot-add a card with a bridge on it, >> because firmware won't have initialized the bridge. >> >> My rule of thumb is that I like to note something in dmesg about the >> initial configuration of bus/mem/io apertures and BARs, as well as >> indications when we update them. That way, the dmesg log should >> contain enough information to debug most enumeration and configuration >> defects. pci_scan_bridge() is somewhat lacking in this regard. > > Ok. Would something like: > > "bridge configuration with unassigned bus numbers ([bus 00-00]), reconfiguring" > > be an acceptable to replace this one? Seems reasonable. -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
