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:	Tue, 8 Jul 2014 21:20:59 +0200
From:	Federico Vaga <federico.vaga@...n.ch>
To:	Bjorn Helgaas <bhelgaas@...gle.com>
CC:	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	<michel.arruat@...n.ch>
Subject: Re: PCIe bus enumeration

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ