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, 03 Jan 2013 01:40:52 +0100
From:	"Rafael J. Wysocki" <>
To:	Bjorn Helgaas <>
Cc:	"" <>,
	ACPI Devel Maling List <>,
	Greg Kroah-Hartman <>,
	LKML <>,
	Tony Luck <>,
	"H. Peter Anvin" <>, Yinghai Lu <>,
	Jiang Liu <>,
	Myron Stowe <>
Subject: Re: [Alternative 2][PATCH] ACPI / PCI: Set root bridge ACPI handle in advance

On Wednesday, January 02, 2013 04:07:32 PM Bjorn Helgaas wrote:
> On Thu, Dec 27, 2012 at 10:32:13PM +0100, Rafael J. Wysocki wrote:
> > To that end, split pci_create_root_bus() into two functions,
> > pci_alloc_root() and pci_add_root(), that will allocate memory for
> > the new PCI bus and bridge representations and register them with
> > the driver core, respectively, and that may be called directly by
> > the architectures that need to set the root bridge's ACPI handle
> > before registering it.
> I'm trying to *reduce* the interfaces for creating and scanning PCI
> host bridges, and this is a step in the opposite direction.

Yes it is.

The alternative is to make the root bridge initialization code more complex.

> > Next, Make both x86 and ia64 (the only architectures using ACPI at
> > the moment) call pci_alloc_root(), set the root bridge's ACPI handle
> > and then call pci_add_root() in their pci_acpi_scan_root() routines
> > instead of calling pci_create_root_bus().  For the other code paths
> > adding PCI root bridges define a new pci_create_root_bus() as a
> > simple combination of pci_alloc_root() and pci_add_root().
> pci_create_root_bus() takes a "struct device *parent" argument.  That
> seems like a logical place to tell the PCI core about the host bridge
> device, but x86 and ia64 currently pass NULL there.

And there's a reason for that.  Namely, on these architectures PCI host
bridges have no physical parents (well, at least in current practice).

> The patch below shows what I'm thinking.  It does have the side-effect
> of changing the sysfs topology from this:
>     /sys/devices/pci0000:00
>     /sys/devices/pci0000:00/0000:00:00.0
> to this:
>     /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/pci0000:00
>     /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/pci0000:00/0000:00:00.0
> because it puts the PCI root bus (pci0000:00) under the PNP0A08 device
> rather than at the top level.

Which is wrong.

PNP0A08 is not a parent of the host bridge, but its ACPI "companion" (ie. ACPI
namespace node representing the host bridge itself).

> That seems like an improvement to me, but it *is* different.

Well, then we should make every ACPI device node corresponding to a PCI device
be a parent of that device's struct pci_dev and so on for other bus types.  It
doesn't sound like an attractive idea. :-)  Moreover, it is impossible, because
those things generally already have parents (struct pci_dev objects have them
at least).

That said the idea to pass something meaningful in the parent argument
of pci_create_root_bus() can be implemented if we create a "physical" device
object corresponding to "device:00" (which is an ACPI namespace node) in your

>From what I can tell, "device:00" always corresponds to the ACPI _SB scope
(which is mandatory), so in principle we can create an abstract "physical"
device object for it and call it something like "system_root".  Then, if we
use it as the parent of pci0000:00 (the host bridge), then we'll have



I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists