Re: PCIe bus enumeration

[Federico Vaga <federico.vaga@cern.ch>]

On Tuesday 08 July 2014 12:23:39 Bjorn Helgaas wrote:
> On Tue, Jul 8, 2014 at 1:15 AM, Federico Vaga 
<federico.vaga@cern.ch> 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