lkml.org 
[lkml]   [2014]   [Jul]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectPCIe bus enumeration
Date
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


\
 
 \ /
  Last update: 2014-07-03 19:21    [W:0.053 / U:0.616 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site