From patchwork Fri Apr 7 13:22:22 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ard Biesheuvel X-Patchwork-Id: 97022 Delivered-To: patch@linaro.org Received: by 10.140.89.233 with SMTP id v96csp282800qgd; Fri, 7 Apr 2017 06:22:40 -0700 (PDT) X-Received: by 10.99.167.74 with SMTP id w10mr42015465pgo.2.1491571360408; Fri, 07 Apr 2017 06:22:40 -0700 (PDT) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q2si5124706plh.271.2017.04.07.06.22.40; Fri, 07 Apr 2017 06:22:40 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-acpi-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) header.i=@linaro.org; spf=pass (google.com: best guess record for domain of linux-acpi-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-acpi-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755935AbdDGNWh (ORCPT + 8 others); Fri, 7 Apr 2017 09:22:37 -0400 Received: from mail-wr0-f179.google.com ([209.85.128.179]:35626 "EHLO mail-wr0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756127AbdDGNWh (ORCPT ); Fri, 7 Apr 2017 09:22:37 -0400 Received: by mail-wr0-f179.google.com with SMTP id o21so79438731wrb.2 for ; Fri, 07 Apr 2017 06:22:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id; bh=/xUJaSu6NpeiMAYSMQM9QvmVW7KIga5g+Nw65WshLs4=; b=hdjI3iass7IR4mvtQsMArys/nHnTEBVui3GjZRu37wPKVBxNjyda52jxfQBDnESAYY VEH8mfTfWfNevOMY7sCmh65dGGcTp/b/gC2Lg43i3DzikgyNkwlEBQduzukKicXjzXLU WoVg6eu26nW1iIsWpIm/cEfGyx2e7tXvPvHrc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=/xUJaSu6NpeiMAYSMQM9QvmVW7KIga5g+Nw65WshLs4=; b=sRPs50JQOtxtRnTO0phFSKWbXERZIeEiUcwHINr/RTWv/r80yqj1WXn2+X2GXCiAcv Xu/ZbxCBWc2OCpPSb+izyUqVp597cBAa66A0N9p7s9gyJcR2HXlfSo5doYMjBWF6Y2cU 2qlaEO5TxRN0szTcMvxzGeFB54e3tvm7P/6CZoCIMTLEo3trILKeWFilaYZjnYn9uRwC 6gCSb77QUKcQU374E8EbmAOfZYygVqkGSKHrZD7vGi3Bc7RMpAEBhlo1hXFJIxDv2qb4 Cgd6BPKTBpt/yMwqn/0w2DyHzo0fBBvm8iEXx8nHsWzaOeLkzZFwIcgjcARVYRTtbtnE 0smA== X-Gm-Message-State: AFeK/H3Zkmh41LdwSc7+ZY7VQswCZu5v7Ts5XYh1KCKiFA4mzTUohVtkdNdG/7EZLiGyBghK X-Received: by 10.223.160.168 with SMTP id m37mr37057603wrm.196.1491571355403; Fri, 07 Apr 2017 06:22:35 -0700 (PDT) Received: from localhost.localdomain ([196.81.139.226]) by smtp.gmail.com with ESMTPSA id k8sm6051226wrc.12.2017.04.07.06.22.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Apr 2017 06:22:34 -0700 (PDT) From: Ard Biesheuvel To: graeme.gregory@linaro.org, al.stone@linaro.org, bhelgaas@google.com Cc: leif.lindholm@linaro.org, linux-arm-kernel@lists.infradead.org, lorenzo.pieralisi@arm.com, rjw@rjwysocki.net, lenb@kernel.org, linux-acpi@vger.kernel.org, marc.zyngier@arm.com, mark.rutland@arm.com, Ard Biesheuvel Subject: [PATCH] acpi: pci: don't ignore function ID of bridge device in _PRT Date: Fri, 7 Apr 2017 14:22:22 +0100 Message-Id: <20170407132222.28300-1-ard.biesheuvel@linaro.org> X-Mailer: git-send-email 2.9.3 Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org We currently derive legacy interrupt routing by matching _PRT entries on the PCI device only, presumably under the assumption that PRT entries always have a value of 0xffff in the function field, meaning 'match all functions'. This no longer holds for modern PCIe topologies, where the legacy interrupts for different slots may be wired to different functions on the same bridge device. For instance, on AMD Seattle, we may have something like -[0000:00]-+-00.0 Advanced Micro Devices, Inc. [AMD] Device 1a00 +-02.0 Advanced Micro Devices, Inc. [AMD] Device 1a01 +-02.2-[01]----00.0 Renesas uPD720202 USB 3.0 Host Controller \-02.3-[02]----00.0 Realtek RTL8169 PCIe Gigabit Ethernet where the _PRT describes the legacy interrupt routing as Name (_PRT, Package () // _PRT: PCI Routing Table { // slot 1: dev 2 fn 1 Package () { 0x20001, 0x0, 0x0, 0x140 }, Package () { 0x20001, 0x1, 0x0, 0x141 }, Package () { 0x20001, 0x2, 0x0, 0x142 }, Package () { 0x20001, 0x3, 0x0, 0x143 }, // slot 1: dev 2 fn 2 Package () { 0x20002, 0x0, 0x0, 0x144 }, Package () { 0x20002, 0x1, 0x0, 0x145 }, Package () { 0x20002, 0x2, 0x0, 0x146 }, Package () { 0x20002, 0x3, 0x0, 0x147 }, // slot 1: dev 2 fn 3 Package () { 0x20003, 0x0, 0x0, 0x148 }, Package () { 0x20003, 0x1, 0x0, 0x149 }, Package () { 0x20003, 0x2, 0x0, 0x14a }, Package () { 0x20003, 0x3, 0x0, 0x14b } }) // _PRT The current code always matches on the first entry when trying to derive the legacy interrupt routing for the USB and Ethernet controllers behind bridges 02.2 and 02.3, which results in the wrong entry to be selected. So fix this by matching the function ID to the value in the _PRT entry if the _PRT entries are not using 0xffff in the lower word to match all functions. Signed-off-by: Ard Biesheuvel --- drivers/acpi/pci_irq.c | 2 ++ 1 file changed, 2 insertions(+) -- 2.9.3 -- 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/acpi/pci_irq.c b/drivers/acpi/pci_irq.c index c576a6fe4ebb..caac4ac94418 100644 --- a/drivers/acpi/pci_irq.c +++ b/drivers/acpi/pci_irq.c @@ -160,6 +160,8 @@ static int acpi_pci_irq_check_entry(acpi_handle handle, struct pci_dev *dev, struct acpi_prt_entry *entry; if (((prt->address >> 16) & 0xffff) != device || + ((prt->address & 0xffff) != 0xffff && + (prt->address & 0xffff) != PCI_FUNC(dev->devfn)) || prt->pin + 1 != pin) return -ENODEV;