Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp176806pxb; Thu, 31 Mar 2022 02:39:11 -0700 (PDT) X-Google-Smtp-Source: ABdhPJymQpEI/BEPzFZd0H7CY5+Yk5dqsdjMRLwoYyTeSf9bDw+MmJKIE2T/diphvBSm2Q+J0RP2 X-Received: by 2002:a50:ff02:0:b0:419:2d32:44fe with SMTP id a2-20020a50ff02000000b004192d3244femr15376732edu.49.1648719550719; Thu, 31 Mar 2022 02:39:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1648719550; cv=none; d=google.com; s=arc-20160816; b=Tk/1P/eaOVExFCnLVhoyyVratTnKArngZrwErm3ohSRBlXwq52IX8wY8rThV6Cf741 qBNssVr2aa3cU0qPP1rSkD4Pwluf2SiDtGirCc6SdBiLBvCkT3X6LAJEgHeb/FLKAGQX RoAiTypDOjg/I1Bmil4aUqBZBscqcZCh3zkrdS4mMekP7K8NK5aMM/QEUl/rb8mb49DC gziNp7J8ckuBBfqUyPngZWewES4w+4zN2S4sQgg0NymKe2rpyWY21MIia+BI2FDdve9v ztG+QCrckq60MeouCjn8F2SO/cVfzWCh3FlHBzKulFl+/PIBzMqra8rNaluznbrYzZ0B EDLQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:references:message-id :in-reply-to:subject:cc:to:from:date; bh=3i4hboJTWED8RClIao+kalLr9WnmyWScBMLDrBofyK8=; b=H5XJXd73pzJaF6BjS+JUscbb193qh4W16ZXTn9oFOefXBCF9xGNyzj0goLor6ULtS9 YFCk9lnOYkHfjGvqFTLO9yHgc85Qs+bjT6tVNNYNNRmx0GuW1AzrH/PgiDiUq+9DSw1a ydIZzOyIjjJBDnOgL8drH3s4aKLZymV8UxjB4h2aZDEkUnhoau7XbcUrd7f1JLN5Ww56 swFpgoLo8eX9jBePwwLjqsJX7nnolU6N+pT3DfQze1iJPKFDrVYdWIEoGZsTW/PZIBOB UtzcZb05J+8Jw44QOT6IQO+9AAJ7WM0Q2VojEVGQyzgKFj78gNMxtxR4ofWGu6QIzySB wpPQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id b11-20020aa7d48b000000b0041901f9db85si21196303edr.368.2022.03.31.02.38.44; Thu, 31 Mar 2022 02:39:10 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231731AbiCaHMV (ORCPT + 99 others); Thu, 31 Mar 2022 03:12:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39028 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231757AbiCaHMR (ORCPT ); Thu, 31 Mar 2022 03:12:17 -0400 Received: from angie.orcam.me.uk (angie.orcam.me.uk [78.133.224.34]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 776686A048; Thu, 31 Mar 2022 00:10:22 -0700 (PDT) Received: by angie.orcam.me.uk (Postfix, from userid 500) id C2EA992009D; Thu, 31 Mar 2022 09:10:21 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by angie.orcam.me.uk (Postfix) with ESMTP id BCDA692009B; Thu, 31 Mar 2022 08:10:21 +0100 (BST) Date: Thu, 31 Mar 2022 08:10:21 +0100 (BST) From: "Maciej W. Rozycki" To: Bjorn Helgaas , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" cc: x86@kernel.org, linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [RESEND][PATCH v2 3/4] x86/PCI: Also match function number in $PIR table In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Contrary to the PCI BIOS specification[1] some systems include the PCI function number for onboard devices in their $PIR table. Consequently the wrong entry can be matched leading to interrupt routing failures. For example the Tyan Tomcat IV S1564D board has: 00:07.1 slot=00 0:00/deb8 1:00/deb8 2:00/deb8 3:00/deb8 00:07.2 slot=00 0:00/deb8 1:00/deb8 2:00/deb8 3:63/deb8 for its IDE interface and USB controller functions of the 82371SB PIIX3 southbridge. Consequently the first entry matches causing the inability to route the USB interrupt in the `noapic' mode, in which case we need to rely on the interrupt line set by the BIOS: uhci_hcd 0000:00:07.2: runtime IRQ mapping not provided by arch uhci_hcd 0000:00:07.2: PCI INT D not routed uhci_hcd 0000:00:07.2: enabling bus mastering uhci_hcd 0000:00:07.2: UHCI Host Controller uhci_hcd 0000:00:07.2: new USB bus registered, assigned bus number 1 uhci_hcd 0000:00:07.2: irq 11, io base 0x00006000 Try to match the PCI device and function combined then and if that fails move on to PCI device matching only. Compliant systems will only have a single $PIR table entry per PCI device, so this update does not change the semantics with them, while systems that have several entries for individual functions of a single PCI device each will match the correct entry: uhci_hcd 0000:00:07.2: runtime IRQ mapping not provided by arch uhci_hcd 0000:00:07.2: PCI INT D -> PIRQ 63, mask deb8, excl 0c20 uhci_hcd 0000:00:07.2: PCI INT D -> newirq 11 uhci_hcd 0000:00:07.2: found PCI INT D -> IRQ 11 uhci_hcd 0000:00:07.2: sharing IRQ 11 with 0000:00:11.0 uhci_hcd 0000:00:07.2: enabling bus mastering uhci_hcd 0000:00:07.2: UHCI Host Controller uhci_hcd 0000:00:07.2: new USB bus registered, assigned bus number 1 uhci_hcd 0000:00:07.2: irq 11, io base 0x00006000 [1] "PCI BIOS Specification", Revision 2.1, PCI Special Interest Group, August 26, 1994, Table 4-1 "Layout of IRQ routing table entry.", p. 12 Signed-off-by: Maciej W. Rozycki --- No change from v1. --- arch/x86/pci/irq.c | 19 +++++++++++++++---- 1 file changed, 15 insertions(+), 4 deletions(-) linux-x86-pirq-fn.diff Index: linux-macro/arch/x86/pci/irq.c =================================================================== --- linux-macro.orig/arch/x86/pci/irq.c +++ linux-macro/arch/x86/pci/irq.c @@ -1132,18 +1132,29 @@ static void __init pirq_find_router(stru /* The device remains referenced for the kernel lifetime */ } +/* + * We're supposed to match on the PCI device only and not the function, + * but some BIOSes build their tables with the PCI function included + * for motherboard devices, so if a complete match is found, then give + * it precedence over a slot match. + */ static struct irq_info *pirq_get_info(struct pci_dev *dev) { struct irq_routing_table *rt = pirq_table; int entries = (rt->size - sizeof(struct irq_routing_table)) / sizeof(struct irq_info); + struct irq_info *slotinfo = NULL; struct irq_info *info; for (info = rt->slots; entries--; info++) - if (info->bus == dev->bus->number && - PCI_SLOT(info->devfn) == PCI_SLOT(dev->devfn)) - return info; - return NULL; + if (info->bus == dev->bus->number) { + if (info->devfn == dev->devfn) + return info; + if (!slotinfo && + PCI_SLOT(info->devfn) == PCI_SLOT(dev->devfn)) + slotinfo = info; + } + return slotinfo; } static int pcibios_lookup_irq(struct pci_dev *dev, int assign)