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: 9669503 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id D9490602A0 for ; Fri, 7 Apr 2017 13:22:41 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id CAAC727C0B for ; Fri, 7 Apr 2017 13:22:41 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id BE79628604; Fri, 7 Apr 2017 13:22:41 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.3 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI, RCVD_IN_SORBS_SPAM, T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 319EC28600 for ; Fri, 7 Apr 2017 13:22:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755935AbdDGNWh (ORCPT ); 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 X-Virus-Scanned: ClamAV using ClamSMTP 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(+) 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;