From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753110Ab3ACAfW (ORCPT ); Wed, 2 Jan 2013 19:35:22 -0500 Received: from hydra.sisk.pl ([212.160.235.94]:57570 "EHLO hydra.sisk.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753074Ab3ACAfS (ORCPT ); Wed, 2 Jan 2013 19:35:18 -0500 From: "Rafael J. Wysocki" To: Bjorn Helgaas Cc: "linux-pci@vger.kernel.org" , 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 Date: Thu, 03 Jan 2013 01:40:52 +0100 Message-ID: <1626213.gpPY5etSgn@vostro.rjw.lan> User-Agent: KMail/4.9.4 (Linux/3.8.0-rc1+; KDE/4.9.4; x86_64; ; ) In-Reply-To: <20130102230732.GB31813@google.com> References: <1558789.gX8cmBgyDV@vostro.rjw.lan> <2816571.07LqOj3EJg@vostro.rjw.lan> <20130102230732.GB31813@google.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 example. >>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 /sys/devices/system_root/pci0000:00 /sys/devices/system_root/pci0000:00/0000:00:00.0 Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center.