lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 3 Jul 2014 13:43:14 -0600
From:	Bjorn Helgaas <bhelgaas@...gle.com>
To:	Federico Vaga <federico.vaga@...il.com>
Cc:	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Michel Arruat <michel.arruat@...il.com>
Subject: Re: PCIe bus enumeration

On Thu, Jul 3, 2014 at 10:45 AM, Federico Vaga <federico.vaga@...il.com> wrote:
> 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?

The /sys/bus/pci/slots/*/address files might help.  On my system, I have:

  $ grep . /sys/bus/pci/slots/*/address /dev/null
  /sys/bus/pci/slots/5/address:0000:03:00

"lspci -v" also shows:

  03:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd.
Device 5227 (rev 01)
        Physical Slot: 5

If you want to start with a physical slot number and figure out the
bb.dd associated with it, the /sys/bus/pci/slots files are probably
the most straightforward way.

> 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)

Yes.  I think you're talking about the bridge "secondary bus number".
In this case the 04:0c.0 bridge has secondary bus 05, and there are no
devices on bus 05.

> 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 don't think the behavior should be different on PCIe, but maybe if
you have an example, it will help me figure out why it is different.
My current machine has three Root Ports (which are treated as
PCI-to-PCI bridges), and they all have secondary bus numbers assigned,
even though only two have devices below them:

           +-1c.0-[01]--
           +-1c.3-[02]----00.0
           +-1c.5-[03]----00.0

We have to assign a secondary bus number in order to enumerate below
the bridge.  We can't even tell whether the bus is empty until we
enumerate it.  We should assign a secondary bus number, then enumerate
the secondary bus (possibly finding nothing).  If we don't find
anything, I think we currently leave the secondary bus number assigned
even though the bus is empty.

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

Powered by blists - more mailing lists