From patchwork Fri May 31 04:21:30 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jiang Liu X-Patchwork-Id: 2640311 X-Patchwork-Delegate: bhelgaas@google.com Return-Path: X-Original-To: patchwork-linux-pci@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork1.kernel.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by patchwork1.kernel.org (Postfix) with ESMTP id E9B813FD4E for ; Fri, 31 May 2013 04:22:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750879Ab3EaEWL (ORCPT ); Fri, 31 May 2013 00:22:11 -0400 Received: from mail-pb0-f42.google.com ([209.85.160.42]:43370 "EHLO mail-pb0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750873Ab3EaEWK (ORCPT ); Fri, 31 May 2013 00:22:10 -0400 Received: by mail-pb0-f42.google.com with SMTP id uo1so1544181pbc.1 for ; Thu, 30 May 2013 21:22:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:x-mailer:in-reply-to:references; bh=4qMLa6CjZKB+uLJC/oH3xR5wMQj0U0lBasIyXaLwlX8=; b=czLRi8ysbZndx0tywmXM1uyn1ckNpuExhexApTHhGedKhXhFb2gpe5GAGqMSPzTwwB iHCfoijPPcsDEVqcUSCmDuxqVHZRKMyfuFesn60TjUTF1ByxJQMIPUh8K3pAcxlWA3DN 9a2MeCHcvZut0CftTu/AINsjIRzP4fWWmhNt5Omb587EJqGAwKC9U6r3es4cIqJAeLuV a3cMQDq7+pZysy+IwFmI+3FzQF1/lw1z4AYRHH/LW71XCp2eUf7/D0WnXIFgisuBY6KO jpqC+U4OymEWgaeCQf9ap4cgOBhbFoFPy+0CFhL7NV3n3HPvZA1W/Y2D9C2hGC49aoKK OeNA== X-Received: by 10.68.189.105 with SMTP id gh9mr11094969pbc.77.1369974129772; Thu, 30 May 2013 21:22:09 -0700 (PDT) Received: from localhost.localdomain (p2155-ipngn4501marunouchi.tokyo.ocn.ne.jp. [153.135.240.155]) by mx.google.com with ESMTPSA id b7sm44778215pba.39.2013.05.30.21.21.53 for (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 30 May 2013 21:22:08 -0700 (PDT) From: Jiang Liu To: Bjorn Helgaas , Yinghai Lu , Xudong Hao Cc: Yijing Wang , linux-pci@vger.kernel.org, Jiang Liu Subject: [PATCH 2/3] PCI, ACPI: Don't glue ACPI dev with pci VFs Date: Fri, 31 May 2013 12:21:30 +0800 Message-Id: <1369974092-11450-2-git-send-email-jiang.liu@huawei.com> X-Mailer: git-send-email 1.8.1.2 In-Reply-To: <1369974092-11450-1-git-send-email-jiang.liu@huawei.com> References: <1369974092-11450-1-git-send-email-jiang.liu@huawei.com> Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org From: Yinghai Lu When sriov is enabled, VF could just start after PF in pci tree. like c1:00.0 will be PF, and c1:00.1 and after will be VF. acpi do have dev with same ADR. that will make them get glued wrongly. Skip that if it is virtfn. Signed-off-by: Yinghai Lu Signed-off-by: Jiang Liu --- drivers/pci/pci-acpi.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c index e4b1fb2..720f3a2 100644 --- a/drivers/pci/pci-acpi.c +++ b/drivers/pci/pci-acpi.c @@ -321,6 +321,10 @@ static int acpi_pci_find_device(struct device *dev, acpi_handle *handle) u64 addr; pci_dev = to_pci_dev(dev); + /* don't mix vf with real pci device */ + if (pci_dev->is_virtfn) + return -ENODEV; + /* Please ref to ACPI spec for the syntax of _ADR */ addr = (PCI_SLOT(pci_dev->devfn) << 16) | PCI_FUNC(pci_dev->devfn); *handle = acpi_get_child(DEVICE_ACPI_HANDLE(dev->parent), addr);