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? Thanks for your quick feedback, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- 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