From patchwork Fri Jul 19 09:38:20 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Oliver O'Halloran X-Patchwork-Id: 1133970 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 45qmD76xm8z9s4Y for ; Fri, 19 Jul 2019 19:39:03 +1000 (AEST) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="DflOV76B"; dkim-atps=neutral Received: from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 45qmD74RZBzDqvw for ; Fri, 19 Jul 2019 19:39:03 +1000 (AEST) X-Original-To: skiboot@lists.ozlabs.org Delivered-To: skiboot@lists.ozlabs.org Authentication-Results: lists.ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=gmail.com (client-ip=2607:f8b0:4864:20::643; helo=mail-pl1-x643.google.com; envelope-from=oohall@gmail.com; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="DflOV76B"; dkim-atps=neutral Received: from mail-pl1-x643.google.com (mail-pl1-x643.google.com [IPv6:2607:f8b0:4864:20::643]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 45qmCh47G9zDqQP for ; Fri, 19 Jul 2019 19:38:40 +1000 (AEST) Received: by mail-pl1-x643.google.com with SMTP id t14so15327228plr.11 for ; Fri, 19 Jul 2019 02:38:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=4OGE20tvQcarM2WDOB74e6f8cRX9zRF+gmJ/IPBYfIc=; b=DflOV76BWnZaCTXrqHoU2CwZMtSd409TLE5s+NoETapTptuZcvLrzorzTzZfgr+0Bu bXjJRJYtYrVLJ2M3qJmqQiPOHck9j5SL636XMSB3UaiaBKFf0sxdI59Kr29C/+TVgRvW 9iUpyuJpWrv71a4iGaeMAf/9dAE499ts9e1Wt/UVEube0uHomwbstBhx9WAW6Q13SaZo f0HPtAQnlj+XG/EgWmuzO0CCp8lpJ11ztB53TlBdM38YFOV38Ed98SWcnmIC1j4Z/Kpk h8VVJ93tEmOvWCxfqBAmPl/yZjARIkqd+edh2IR4ZTrtZxO5ObiEPOI0ZOqlx0huItPq FsfA== 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:in-reply-to :references:mime-version:content-transfer-encoding; bh=4OGE20tvQcarM2WDOB74e6f8cRX9zRF+gmJ/IPBYfIc=; b=t/To9hOwl2BbXWCA5CqRcd9Ic/Wswz4LtnhXZlaQpv2VMaKksVD/oTchi5OsKj8QVh O9NC+bL9tj2dZaBA4yOaU8AWDYmHpylSStUx58EgATi2KApkK1OgSl5kBoYWpkh4hBrU E5K/IBzoR5C5fT+PBQ+mg8Lsy4OdtgDfz8x3duxq9eRx9jEVf4/L1b/lWj7mvCFsoIFV qXcGJATkX9cxf+WvGewlMqpUADihbkAab+yzNXnAtn/R62cupCYTZnlmffx/OUCA5Fe3 95jim9zYLnMmUCYIiTi+Rn3wi4Rpu4X3GI2NHMOjn9dwyk8DTRm/EeKEKRNNkk05HFWO gM4g== X-Gm-Message-State: APjAAAXwgmuDgMh9xhWFHQYLAl+3hvDMU+SWm+gBgRcTC6iPd7YQLft/ K05nQ0cEA++SjbMgDxLU4Sc1g8Fgoy0= X-Google-Smtp-Source: APXvYqwJTC5XD0nmDChZIMZmrrDpudK/Cymz5usZddbq6rzfIqx7jyNgWONFgg7nao2vUEf60Gem+A== X-Received: by 2002:a17:902:27a8:: with SMTP id d37mr55862726plb.150.1563529117058; Fri, 19 Jul 2019 02:38:37 -0700 (PDT) Received: from wafer.ozlabs.ibm.com.ozlabs.ibm.com ([122.99.82.10]) by smtp.gmail.com with ESMTPSA id j15sm44558141pfn.150.2019.07.19.02.38.35 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Fri, 19 Jul 2019 02:38:36 -0700 (PDT) From: Oliver O'Halloran To: skiboot@lists.ozlabs.org Date: Fri, 19 Jul 2019 19:38:20 +1000 Message-Id: <20190719093821.14278-2-oohall@gmail.com> X-Mailer: git-send-email 2.21.0 In-Reply-To: <20190719093821.14278-1-oohall@gmail.com> References: <20190719093821.14278-1-oohall@gmail.com> MIME-Version: 1.0 Subject: [Skiboot] [PATCH 2/3] pci-quirk: Microsemi switch UR workaround X-BeenThere: skiboot@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mailing list for skiboot development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: skiboot-bounces+incoming=patchwork.ozlabs.org@lists.ozlabs.org Sender: "Skiboot" Some Microsemi switches have a bug where they send URs if you perform a config read outside of a PCI Capability register block. Linux allows users to read the whole of config space and some tools (like lspci) will do this. On POWER chips this UR triggers a spurious EEH which causes all manner of hell. This patch adds a pci-quirk for the relevant switch that blocks config space read and writes to the switch to prevent the issue. Signed-off-by: Oliver O'Halloran --- core/pci-quirk.c | 58 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 58 insertions(+) diff --git a/core/pci-quirk.c b/core/pci-quirk.c index 0862e8dc4072..371ff62b4b72 100644 --- a/core/pci-quirk.c +++ b/core/pci-quirk.c @@ -18,10 +18,67 @@ #include #include +#include #include #include #include +static int64_t cfg_block_filter(void *dev __unused, + struct pci_cfg_reg_filter *pcrf __unused, + uint32_t offset __unused, uint32_t len, + uint32_t *data, bool write) +{ + if (write) + return OPAL_SUCCESS; + + switch (len) { + case 4: + *data = 0xF0F0F0F0; + return OPAL_SUCCESS; + case 2: + *((uint16_t *)data) = 0xF0F0; + return OPAL_SUCCESS; + case 1: + *((uint8_t *)data) = 0xF0; + return OPAL_SUCCESS; + } + + return OPAL_PARAMETER; /* should never happen */ +} + +/* blocks config accesses to registers in the range: [start, end] */ +#define BLOCK_CFG_RANGE(pd, start, end) \ + pci_add_cfg_reg_filter(pd, start, end - start + 1, \ + PCI_REG_FLAG_WRITE | PCI_REG_FLAG_READ, \ + cfg_block_filter); + +static void quirk_microsemi_gen4_sw(struct phb *phb, struct pci_device *pd) +{ + /* + * The gen4 pcie switch used on some ZZ systems has a bug where it'll + * throw URs in response to a cfg read to a range that's "reserved" + * work around it by blackholing. + */ + if (pd->dev_type == PCIE_TYPE_ENDPOINT && pd->class == 0x058000) { + /* + * we match on the class code too since the switch might + * support an NTB endpoint. + */ + BLOCK_CFG_RANGE(pd, 0xa0, 0xff); + BLOCK_CFG_RANGE(pd, 0x17c, 0xfff); + } else if (pd->dev_type == PCIE_TYPE_SWITCH_UPPORT) { + BLOCK_CFG_RANGE(pd, 0x09c, 0xff); + BLOCK_CFG_RANGE(pd, 0x284, 0x7f7); + } else if (pd->dev_type == PCIE_TYPE_SWITCH_DNPORT) { + BLOCK_CFG_RANGE(pd, 0x09c, 0xff); + BLOCK_CFG_RANGE(pd, 0x288, 0x7f7); + } else { + return; + } + + PCINOTICE(phb, pd->bdfn, "Applied Microsemi Gen4 UR workaround\n"); +} + static void quirk_astbmc_vga(struct phb *phb __unused, struct pci_device *pd) { @@ -53,6 +110,7 @@ static void quirk_astbmc_vga(struct phb *phb __unused, static const struct pci_quirk quirk_table[] = { /* ASPEED 2400 VGA device */ { 0x1a03, 0x2000, &quirk_astbmc_vga }, + { 0x11f8, 0x4052, &quirk_microsemi_gen4_sw }, { 0, 0, NULL } };