PCIe bus enumeration

[Federico Vaga]

Hello,

(I haven't a deep knowledge of the PCIe specification, maybe I'm just 
missing something)

is there a way to force the PCI subsystem to assign a bus-number to 
every PCIe bridge, even if there is nothing connected?


My aim is to have a bus enumeration constant and independent from what 
I plugged on the system. So, I can associate a physical slot to linux 
device address bb:dd.f. Is it possible?

I can do the mapping with a simple shell script by discovering the 
"new" bus number, but I'm wondering if there is a way to have a 
constant bus enumeration.



My Humble Observation
---------------------
It seems (to me) that for PCI the kernel assigns a bus-number to every 
PCI bridges and sub-bridges even if there is nothing connected:


e.g. from lspci -t

      [...]
      +-1e.0-[04-05]----0c.0-[05]--

00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 92)
04:0c.0 PCI bridge: Texas Instruments PCI2050 PCI-to-PCI Bridge (rev 
02)


The behavior on PCIe seems different. When there is nothing plugged on 
a bus, then the kernel doesn't assign any bus-number and it doesn't 
detect any PCI-Bridge at all. So, when I reboot the system with a new 
PCIe card the bus enumeration may change.


I tried to use the following pci kernel parameters:

assign-busses : because I want to force the kernel to re-enumerate the 
busses, hopefully _all_ buses even if they are empty.

pcie_scan_all : not clear the explanation, but it sounds like it tells 
to the kernel to inspect everything.

bfsort : because, maybe, for a bfsort it must assign a number to each 
bridge at the same level before inspect the next one.

noacpi : in order to scan independently from BIOS information


The result is always the same (empty buses are not enumerated). 



Thank you :)

-- 
Federico Vaga
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/