From patchwork Wed Nov 5 21:57:13 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bjorn Helgaas X-Patchwork-Id: 5238321 Return-Path: X-Original-To: patchwork-linux-acpi@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 301EFC11AC for ; Wed, 5 Nov 2014 21:57:24 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 4C5202015E for ; Wed, 5 Nov 2014 21:57:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 83A1D200F0 for ; Wed, 5 Nov 2014 21:57:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751317AbaKEV5T (ORCPT ); Wed, 5 Nov 2014 16:57:19 -0500 Received: from mail-ie0-f170.google.com ([209.85.223.170]:58002 "EHLO mail-ie0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750951AbaKEV5S (ORCPT ); Wed, 5 Nov 2014 16:57:18 -0500 Received: by mail-ie0-f170.google.com with SMTP id tp5so1697108ieb.29 for ; Wed, 05 Nov 2014 13:57:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=eiWbHCvyrwGv4K63/Z/54L+N8reV8RxvFvU+YH7TlvE=; b=ecyJS18Ra6rY1N9bT/tnWVOzdYHvEyx5pxrk9SH0QgFAcEjXHnfE8+YhlXF/YndxHW uNN+GnsQ8tP96Cwn7hRxZZzEiY1ek3QQyNxJeAIN9c627ITgMubDiqejbLyyB9YiarwK 7sCFPWrQL2N0m8c2K0ONV24657gAFAzxB4nujLkMHRn9RI4QWP1hAtdsjaIYEaFpUlBD 7LXLSZ60UMKNcfWOm5KHEsBhsMjq0x3c2ovqYlf5s7HotQRY6oMx367opb0QedU/CjH5 +7AcEF+IdqkHnjI0shBYie0AhIfwDrcL8vscUx27CMpd3klreSZa8s6aElPycfcXgLyZ TXOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=eiWbHCvyrwGv4K63/Z/54L+N8reV8RxvFvU+YH7TlvE=; b=WitABvf6A5k3l/RLC11IBXp7akP+b6wkX9P1RQzNQa8oJ7X4uHsz9+jef2eKuro713 LCD2s33upeOSGmauD7IBN7Xlfqp2QKu3bbeN/YAX/HYplNF+3rs/AYMRVqy2d1mzECVf bDmh8szuu4JhrCJPK4GMkp3RYm5ut+9+UHBwVewdU6IrbciNHKiaidAwY/9aUXep6M40 Ok3T87W7rakDtHYmPwtxjMqhxjX4g41lSw73Y/rx0env6UYdl8PoVDiXn69rErU2xXYc PgXv415I05CHr0kgYH9Z4V0VjwPhDei4H3nl99XzWlfyM+8t2VELgJpLA27Gn3XOc2Go rL2A== X-Gm-Message-State: ALoCoQlipIiiqC18xhK5bg4vhc736qneZby3RokBpGGMwnxZ+Z06DKhXdt0wP4VRLSjYyrWxIc5O X-Received: by 10.51.16.99 with SMTP id fv3mr35460260igd.31.1415224637181; Wed, 05 Nov 2014 13:57:17 -0800 (PST) Received: from google.com ([172.16.48.42]) by mx.google.com with ESMTPSA id i1sm424964igg.21.2014.11.05.13.57.15 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Wed, 05 Nov 2014 13:57:15 -0800 (PST) Date: Wed, 5 Nov 2014 14:57:13 -0700 From: Bjorn Helgaas To: "Rafael J. Wysocki" Cc: Yinghai Lu , linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, "Rafael J. Wysocki" , linux-acpi@vger.kernel.org, Chao Zhou , Joerg Roedel Subject: Re: [PATCH] PCI: fix sriov enabling with virtual bus Message-ID: <20141105215713.GC6168@google.com> References: <1414621570-20777-1-git-send-email-yinghai@kernel.org> <20141030170913.GA6982@google.com> <20141105202252.GB6168@google.com> <1808324.GlBOqbYcPz@vostro.rjw.lan> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1808324.GlBOqbYcPz@vostro.rjw.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org X-Spam-Status: No, score=-7.4 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, T_DKIM_INVALID, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Wed, Nov 05, 2014 at 10:44:25PM +0100, Rafael J. Wysocki wrote: > On Wednesday, November 05, 2014 01:22:52 PM Bjorn Helgaas wrote: > > ... > > The acpi_pci_get_bridge_handle(struct pci_bus *) interface niggles at me a > > little because I don't think there's any concept of an ACPI device for a > > PCI *bus*, so it doesn't seem like a very good fit to say "find the handle > > for this bus". But that's for later. > > To me it does what it says: Get me the handle of the bridge leading to > this bus. Yeah, I know, it's a great name because it does *exactly* what the name says. I'm just wondering if there's a nicer way to express what the caller needs. Two of the three callers start with a pci_dev, look up a pci_bus to pass in, and get back a handle corresponding to a pci_host_bridge or a pci_dev (or a NULL). It seems a little cluttered because the pci_bus is only incidental and the caller doesn't care about it at all except for passing it to acpi_pci_get_bridge_handle(). It's relatively common to start with a pci_dev and look for an ACPI handle that corresponds to that device or the closest enclosing scope, so maybe there should be a way to do that directly. For pci_get_hp_params(), I think the current code is actually slightly buggy because we don't look for _HPP/_HPX on the device itself; we only look at the bridges upstream from it. What I had in mind was something like the following (untested and not for application). Bjorn --- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/drivers/pci/hotplug/acpi_pcihp.c b/drivers/pci/hotplug/acpi_pcihp.c index 876ccc620440..5e95df56b8ae 100644 --- a/drivers/pci/hotplug/acpi_pcihp.c +++ b/drivers/pci/hotplug/acpi_pcihp.c @@ -116,20 +116,11 @@ int acpi_get_hp_hw_control_from_firmware(struct pci_dev *pdev, u32 flags) string = (struct acpi_buffer){ ACPI_ALLOCATE_BUFFER, NULL }; } - handle = ACPI_HANDLE(&pdev->dev); - if (!handle) { - /* - * This hotplug controller was not listed in the ACPI name - * space at all. Try to get acpi handle of parent pci bus. - */ - struct pci_bus *pbus; - for (pbus = pdev->bus; pbus; pbus = pbus->parent) { - handle = acpi_pci_get_bridge_handle(pbus); - if (handle) - break; - } - } - + /* + * We did not find _OSC on the host bridge, so look for any + * enclosing device with an OSHP method. + */ + handle = pci_find_acpi_handle(pdev); while (handle) { acpi_get_name(handle, ACPI_FULL_PATHNAME, &string); dbg("Trying to get hotplug control for %s \n", diff --git a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c index 6ebf8edc5f3c..3b3f0720fff0 100644 --- a/drivers/pci/pci-acpi.c +++ b/drivers/pci/pci-acpi.c @@ -246,14 +246,8 @@ int pci_get_hp_params(struct pci_dev *dev, struct hotplug_params *hpp) { acpi_status status; acpi_handle handle, phandle; - struct pci_bus *pbus; - handle = NULL; - for (pbus = dev->bus; pbus; pbus = pbus->parent) { - handle = acpi_pci_get_bridge_handle(pbus); - if (handle) - break; - } + handle = pci_find_acpi_handle(dev); /* * _HPP settings apply to all child buses, until another _HPP is @@ -279,6 +273,33 @@ int pci_get_hp_params(struct pci_dev *dev, struct hotplug_params *hpp) } EXPORT_SYMBOL_GPL(pci_get_hp_params); +/* + * Search for an ACPI handle. The PCI device itself may have one, or an + * upstream device (either a PCI-to-PCI bridge or a PCI host bridge) may + * have one. + */ +acpi_handle pci_find_acpi_handle(struct pci_dev *pdev) +{ + struct device *dev; + acpi_handle handle; + struct pci_bus *bus; + + dev = &pdev->dev; + handle = ACPI_HANDLE(dev); + while (!handle) { + pdev = pci_physfn(pdev); + bus = pdev->bus; + if (pci_is_root_bus(bus)) + dev = bus->bridge; + else { + pdev = bus->self; + dev = &pdev->dev; + } + handle = ACPI_HANDLE(dev); + } + return handle; +} + /** * pci_acpi_wake_bus - Root bus wakeup notification fork function. * @work: Work item to handle.