From patchwork Thu Feb 8 12:33:44 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Niklas Cassel X-Patchwork-Id: 870865 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=linux-pci-owner@vger.kernel.org; receiver=) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 3zcd204qRRz9sNx for ; Thu, 8 Feb 2018 23:35:04 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752189AbeBHMeA (ORCPT ); Thu, 8 Feb 2018 07:34:00 -0500 Received: from bastet.se.axis.com ([195.60.68.11]:49065 "EHLO bastet.se.axis.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750961AbeBHMd4 (ORCPT ); Thu, 8 Feb 2018 07:33:56 -0500 Received: from localhost (localhost [127.0.0.1]) by bastet.se.axis.com (Postfix) with ESMTP id DEB921889D; Thu, 8 Feb 2018 13:33:54 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at bastet.se.axis.com Received: from bastet.se.axis.com ([IPv6:::ffff:127.0.0.1]) by localhost (bastet.se.axis.com [::ffff:127.0.0.1]) (amavisd-new, port 10024) with LMTP id HNLvpIAUMTdg; Thu, 8 Feb 2018 13:33:53 +0100 (CET) Received: from boulder02.se.axis.com (boulder02.se.axis.com [10.0.8.16]) by bastet.se.axis.com (Postfix) with ESMTPS id A1A061889F; Thu, 8 Feb 2018 13:33:53 +0100 (CET) Received: from boulder02.se.axis.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6B1E91A069; Thu, 8 Feb 2018 13:33:53 +0100 (CET) Received: from boulder02.se.axis.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5EAD81A063; Thu, 8 Feb 2018 13:33:53 +0100 (CET) Received: from seth.se.axis.com (unknown [10.0.2.172]) by boulder02.se.axis.com (Postfix) with ESMTP; Thu, 8 Feb 2018 13:33:53 +0100 (CET) Received: from lnxartpec1.se.axis.com (lnxartpec1.se.axis.com [10.88.4.10]) by seth.se.axis.com (Postfix) with ESMTP id 515772D60; Thu, 8 Feb 2018 13:33:53 +0100 (CET) Received: by lnxartpec1.se.axis.com (Postfix, from userid 20283) id 4CF86401B8; Thu, 8 Feb 2018 13:33:53 +0100 (CET) From: Niklas Cassel To: kishon@ti.com, Lorenzo Pieralisi , Bjorn Helgaas , Sekhar Nori , Cyrille Pitchen , Niklas Cassel , Shawn Lin , John Keeping Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v2 1/3] PCI: endpoint: Handle 64-bit BARs properly Date: Thu, 8 Feb 2018 13:33:44 +0100 Message-Id: <20180208123346.20784-2-niklas.cassel@axis.com> X-Mailer: git-send-email 2.14.2 In-Reply-To: <20180208123346.20784-1-niklas.cassel@axis.com> References: <20180208123346.20784-1-niklas.cassel@axis.com> X-TM-AS-GCONF: 00 Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org A 64-bit BAR uses the succeeding BAR for the upper bits, therefore we cannot call pci_epc_set_bar() on a BAR that follows a 64-bit BAR. If pci_epc_set_bar() is called with flag PCI_BASE_ADDRESS_MEM_TYPE_64, it has to be up to the controller driver to write both BAR[x] and BAR[x+1] (and BAR_mask[x] and BAR_mask[x+1]). Signed-off-by: Niklas Cassel --- drivers/pci/endpoint/functions/pci-epf-test.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c b/drivers/pci/endpoint/functions/pci-epf-test.c index 800da09d9005..eef85820f59e 100644 --- a/drivers/pci/endpoint/functions/pci-epf-test.c +++ b/drivers/pci/endpoint/functions/pci-epf-test.c @@ -382,6 +382,8 @@ static int pci_epf_test_set_bar(struct pci_epf *epf) if (bar == test_reg_bar) return ret; } + if (flags & PCI_BASE_ADDRESS_MEM_TYPE_64) + bar++; } return 0; From patchwork Thu Feb 8 12:33:45 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Niklas Cassel X-Patchwork-Id: 870866 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=linux-pci-owner@vger.kernel.org; receiver=) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 3zcd2H0N5Kz9sRW for ; Thu, 8 Feb 2018 23:35:19 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751317AbeBHMd6 (ORCPT ); Thu, 8 Feb 2018 07:33:58 -0500 Received: from bastet.se.axis.com ([195.60.68.11]:49076 "EHLO bastet.se.axis.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751066AbeBHMd4 (ORCPT ); Thu, 8 Feb 2018 07:33:56 -0500 Received: from localhost (localhost [127.0.0.1]) by bastet.se.axis.com (Postfix) with ESMTP id 89A8A1889E; Thu, 8 Feb 2018 13:33:55 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at bastet.se.axis.com Received: from bastet.se.axis.com ([IPv6:::ffff:127.0.0.1]) by localhost (bastet.se.axis.com [::ffff:127.0.0.1]) (amavisd-new, port 10024) with LMTP id FjRTrxDPCMka; Thu, 8 Feb 2018 13:33:53 +0100 (CET) Received: from boulder03.se.axis.com (boulder03.se.axis.com [10.0.8.17]) by bastet.se.axis.com (Postfix) with ESMTPS id AFE46188A1; Thu, 8 Feb 2018 13:33:53 +0100 (CET) Received: from boulder03.se.axis.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 9C4361E077; Thu, 8 Feb 2018 13:33:53 +0100 (CET) Received: from boulder03.se.axis.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 910031E076; Thu, 8 Feb 2018 13:33:53 +0100 (CET) Received: from thoth.se.axis.com (unknown [10.0.2.173]) by boulder03.se.axis.com (Postfix) with ESMTP; Thu, 8 Feb 2018 13:33:53 +0100 (CET) Received: from lnxartpec1.se.axis.com (lnxartpec1.se.axis.com [10.88.4.10]) by thoth.se.axis.com (Postfix) with ESMTP id 848482D8B; Thu, 8 Feb 2018 13:33:53 +0100 (CET) Received: by lnxartpec1.se.axis.com (Postfix, from userid 20283) id 804D7401B8; Thu, 8 Feb 2018 13:33:53 +0100 (CET) From: Niklas Cassel To: kishon@ti.com, Arnd Bergmann , Greg Kroah-Hartman , Lorenzo Pieralisi Cc: Niklas Cassel , linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v2 2/3] misc: pci_endpoint_test: Handle 64-bit BARs properly Date: Thu, 8 Feb 2018 13:33:45 +0100 Message-Id: <20180208123346.20784-3-niklas.cassel@axis.com> X-Mailer: git-send-email 2.14.2 In-Reply-To: <20180208123346.20784-1-niklas.cassel@axis.com> References: <20180208123346.20784-1-niklas.cassel@axis.com> X-TM-AS-GCONF: 00 Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org A 64-bit BAR uses the succeeding BAR for the upper bits, so we cannot simply call pci_ioremap_bar() on every single BAR. Ignore BARs that does not have a valid resource length. pci 0000:01:00.0: BAR 4: assigned [mem 0xc0300000-0xc031ffff 64bit] pci 0000:01:00.0: BAR 2: assigned [mem 0xc0320000-0xc03203ff 64bit] pci 0000:01:00.0: BAR 0: assigned [mem 0xc0320400-0xc03204ff 64bit] pci-endpoint-test 0000:01:00.0: can't ioremap BAR 1: [??? 0x00000000 flags 0x0] pci-endpoint-test 0000:01:00.0: failed to read BAR1 pci-endpoint-test 0000:01:00.0: can't ioremap BAR 3: [??? 0x00000000 flags 0x0] pci-endpoint-test 0000:01:00.0: failed to read BAR3 pci-endpoint-test 0000:01:00.0: can't ioremap BAR 5: [??? 0x00000000 flags 0x0] pci-endpoint-test 0000:01:00.0: failed to read BAR5 Signed-off-by: Niklas Cassel --- Lorenzo/Bjorn: pci_resource_len() seems to fix my problem, but is it the correct function to use here? If BAR[x] is a 64-bit BAR, I'm assuming that pci_resource_len() on BAR[x+1] will always return 0 (since BAR[x+1] cannot have any prefetchable/type bits when BAR[x] is 64-bit). drivers/misc/pci_endpoint_test.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/misc/pci_endpoint_test.c b/drivers/misc/pci_endpoint_test.c index 320276f42653..3af31bfdcfdd 100644 --- a/drivers/misc/pci_endpoint_test.c +++ b/drivers/misc/pci_endpoint_test.c @@ -534,6 +534,8 @@ static int pci_endpoint_test_probe(struct pci_dev *pdev, } for (bar = BAR_0; bar <= BAR_5; bar++) { + if (pci_resource_len(pdev, bar) == 0) + continue; base = pci_ioremap_bar(pdev, bar); if (!base) { dev_err(dev, "failed to read BAR%d\n", bar); From patchwork Thu Feb 8 12:33:46 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Niklas Cassel X-Patchwork-Id: 870864 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=linux-pci-owner@vger.kernel.org; receiver=) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 3zcd1c4M4Hz9sP9 for ; Thu, 8 Feb 2018 23:34:44 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752267AbeBHMeM (ORCPT ); Thu, 8 Feb 2018 07:34:12 -0500 Received: from bastet.se.axis.com ([195.60.68.11]:49137 "EHLO bastet.se.axis.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752255AbeBHMeK (ORCPT ); Thu, 8 Feb 2018 07:34:10 -0500 Received: from localhost (localhost [127.0.0.1]) by bastet.se.axis.com (Postfix) with ESMTP id 17A651889F; Thu, 8 Feb 2018 13:34:09 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at bastet.se.axis.com Received: from bastet.se.axis.com ([IPv6:::ffff:127.0.0.1]) by localhost (bastet.se.axis.com [::ffff:127.0.0.1]) (amavisd-new, port 10024) with LMTP id 6BoJ0Tla33n7; Thu, 8 Feb 2018 13:34:08 +0100 (CET) Received: from boulder02.se.axis.com (boulder02.se.axis.com [10.0.8.16]) by bastet.se.axis.com (Postfix) with ESMTPS id 7152B188A5; Thu, 8 Feb 2018 13:34:08 +0100 (CET) Received: from boulder02.se.axis.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 3465F1A06F; Thu, 8 Feb 2018 13:34:08 +0100 (CET) Received: from boulder02.se.axis.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 291F71A073; Thu, 8 Feb 2018 13:34:08 +0100 (CET) Received: from seth.se.axis.com (unknown [10.0.2.172]) by boulder02.se.axis.com (Postfix) with ESMTP; Thu, 8 Feb 2018 13:34:08 +0100 (CET) Received: from lnxartpec1.se.axis.com (lnxartpec1.se.axis.com [10.88.4.10]) by seth.se.axis.com (Postfix) with ESMTP id 1D06A2D60; Thu, 8 Feb 2018 13:34:08 +0100 (CET) Received: by lnxartpec1.se.axis.com (Postfix, from userid 20283) id 185DD401B8; Thu, 8 Feb 2018 13:34:07 +0100 (CET) From: Niklas Cassel To: kishon@ti.com, Jingoo Han , Joao Pinto , Lorenzo Pieralisi , Bjorn Helgaas Cc: Niklas Cassel , linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v2 3/3] PCI: designware-ep: Return an error when requesting a too large BAR size Date: Thu, 8 Feb 2018 13:33:46 +0100 Message-Id: <20180208123346.20784-4-niklas.cassel@axis.com> X-Mailer: git-send-email 2.14.2 In-Reply-To: <20180208123346.20784-1-niklas.cassel@axis.com> References: <20180208123346.20784-1-niklas.cassel@axis.com> X-TM-AS-GCONF: 00 Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org pci_epc_set_bar() can be called with flag PCI_BASE_ADDRESS_MEM_TYPE_64, and can thus request a BAR size larger than 4 GB. However, the pcie-designware-ep.c driver currently doesn't handle BAR sizes larger than 4 GB. (Since we are only writing the BAR_mask[x] register and not the BAR_mask[x+1] register.) For now, return an error when requesting a BAR size larger than 4 GB. Signed-off-by: Niklas Cassel --- Changes since v1: Use upper_32_bits() to avoid build warning on systems with 32-bit size_t. drivers/pci/dwc/pcie-designware-ep.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/pci/dwc/pcie-designware-ep.c b/drivers/pci/dwc/pcie-designware-ep.c index 3a6feeff5f5b..efb65a7c06b8 100644 --- a/drivers/pci/dwc/pcie-designware-ep.c +++ b/drivers/pci/dwc/pcie-designware-ep.c @@ -126,6 +126,11 @@ static int dw_pcie_ep_set_bar(struct pci_epc *epc, u8 func_no, enum dw_pcie_as_type as_type; u32 reg = PCI_BASE_ADDRESS_0 + (4 * bar); + if (upper_32_bits(size)) { + dev_err(pci->dev, "can't handle BAR larger than 4GB\n"); + return -EINVAL; + } + if (!(flags & PCI_BASE_ADDRESS_SPACE)) as_type = DW_PCIE_AS_MEM; else