On Tuesday 08 July 2014 12:23:39 Bjorn Helgaas wrote: > On Tue, Jul 8, 2014 at 1:15 AM, Federico Vaga <federico.vaga@xxxxxxx> wrote: > >> > So, It looks like that some BIOS disable the bridge when there > >> > is > >> > nothing behind it. Why? Power save? :/ > >> > >> Could be power savings, or possibly to conserve bus numbers, > >> which > >> are a limited resource. > > > > what is the maximum number of buses? > > 256. Well, it is not a small number. I will ask directly to the company who sell this crate and ask them what is going on in the BIOS > > At this point I'm a little bit confused about the definition "slot > > numbers" :) You mean the 22, 25, ... > > Right. Bus numbers are under software control, to some degree (as a > general rule, an x86 BIOS assigns them and Linux leaves them alone, > but they *can* be changed so they aren't a good thing to rely on). > The bus number of a root bus is usually determined by hardware or > by an arch-specific host bridge driver. The bus number below a > PCI-PCI bridge is determined by the bridge's "secondary bus number" > register, which software can change. > > Slot numbers are based on the Physical Slot Number in the PCIe Slot > Capability register. This is set by some hardware mechanism such as > pin strapping or a serial EEPROM. Software can't change it, so you > can rely on it to be constant. (There's also a mechanism for > getting a slot number from ACPI, but that should also return a > constant value). The problem is that I don't think the Linux slot > number support is very good, so I'm sure there's plenty of stuff > that we *should* be able to do that we can't do *yet*. Mh, I understand. Let's say that I have time to spend on this problem (I do not know) and contributing to the PCI subsystem. How many differences are there between 3.2, 3.6, 3.16/next? We are using 3.2/3.6 at the moment, but probably you should expect that it will work on the last version :) -- Federico Vaga -- 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