From patchwork Fri Aug 9 17:48:23 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Marek Vasut X-Patchwork-Id: 1144873 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=) Authentication-Results: ozlabs.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="ODw1VWOk"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 464t5J6tVzz9sP3 for ; Sat, 10 Aug 2019 03:48:36 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2407576AbfHIRsf (ORCPT ); Fri, 9 Aug 2019 13:48:35 -0400 Received: from mail-wm1-f68.google.com ([209.85.128.68]:53506 "EHLO mail-wm1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726216AbfHIRsf (ORCPT ); Fri, 9 Aug 2019 13:48:35 -0400 Received: by mail-wm1-f68.google.com with SMTP id 10so6509326wmp.3; Fri, 09 Aug 2019 10:48:33 -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:mime-version :content-transfer-encoding; bh=i+ph51ddfAMHxsV4U4mVgIYNDFpq4leR2YkXuGPovKA=; b=ODw1VWOk2pY/Y6L8dxZAHgwAh++yC8hcFSobe4N3wZdVrLP43CjF+AhJMhA+9Q92qe vPi1ZAlhzw7vC9FvVCYC5fIKU1fLcKa3vNT2Dfns1fa20TIiY3bym/EPNm1KSJvckSp2 fIGLWIlcaiGZaxx/50Hpi/nF9lxhF19XIOIdbvee04UzJQiTx88011q1i+HWzJIpjk+O Zq+b11vyy/fOE7vLYz34tgVMquPKQeQrez+Gdhk/6lYCT2Eam2zN2vvQAEaeo5CmHDOI Cxgek5c+RoZpR8B0RpYiXHYFRKZQXwrk3cHaHr9Lk5arFXrshF1+0nGTQnzaYCj8oYB0 mOhg== 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:mime-version :content-transfer-encoding; bh=i+ph51ddfAMHxsV4U4mVgIYNDFpq4leR2YkXuGPovKA=; b=KGebr0AZ4dsfI8JvRhxE82tM+XnyH4/6acgwU1Wkkad3iTMu6FRNxmFbLZwXRw6X2b Ii2ghhlkLLbSShRNqb/lFcWzKUEFDm+nR31fjne9UM68qdkO9xNktd3YRzXmSHMwcqz1 dPl253ehWK3UliDSUsT9EesSX5CNeAoYT0hgxq753dVR+lBIRVOZWvEPbERpf4iJbrj8 0Mt1lz5uIavBfclEudypjjET+T3siIPOJCCI5xiXt8El95UrdNPptpqOuWPdM11VGrbO 3lQDVLMR55og/l7VE+PCzdw/poWDFvqUpnoCNj8w8MK7IE3PccoOhSDAaZI05Rmo4HFD SLBg== X-Gm-Message-State: APjAAAWoNqgkXIuB2oDZxi3kA2nVHiQpPnQyCgLIXDuGXTx63ILHS7E8 9d7pz9Hgi/dubE0YxxO5UFm07op5 X-Google-Smtp-Source: APXvYqxdwunAut7qarespasbnRFivAqSmVHNLCg51VEwmRSEUPncgby36lJVpN1cAWRpRDvZk7FKXQ== X-Received: by 2002:a1c:80d0:: with SMTP id b199mr11917626wmd.31.1565372912850; Fri, 09 Aug 2019 10:48:32 -0700 (PDT) Received: from chi.lan (ip-86-49-35-8.net.upcbroadband.cz. [86.49.35.8]) by smtp.gmail.com with ESMTPSA id z18sm3999182wml.10.2019.08.09.10.48.31 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Fri, 09 Aug 2019 10:48:31 -0700 (PDT) From: marek.vasut@gmail.com To: linux-pci@vger.kernel.org Cc: Marek Vasut , Geert Uytterhoeven , Lorenzo Pieralisi , Wolfram Sang , linux-renesas-soc@vger.kernel.org Subject: [PATCH V2 1/3] PCI: rcar: Move the inbound index check Date: Fri, 9 Aug 2019 19:48:23 +0200 Message-Id: <20190809174825.2572-1-marek.vasut@gmail.com> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org From: Marek Vasut Since the $idx variable value is stored across multiple calls to rcar_pcie_inbound_ranges() function, and the $idx value is used to index registers which are written, subsequent calls might cause the $idx value to be high enough to trigger writes into nonexistent registers. Fix this by moving the $idx value check to the beginning of the loop. Signed-off-by: Marek Vasut Cc: Geert Uytterhoeven Cc: Lorenzo Pieralisi Cc: Wolfram Sang Cc: linux-renesas-soc@vger.kernel.org To: linux-pci@vger.kernel.org --- V2: New patch --- drivers/pci/controller/pcie-rcar.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/drivers/pci/controller/pcie-rcar.c b/drivers/pci/controller/pcie-rcar.c index f6a669a9af41..0f501acbc3bb 100644 --- a/drivers/pci/controller/pcie-rcar.c +++ b/drivers/pci/controller/pcie-rcar.c @@ -1048,6 +1048,10 @@ static int rcar_pcie_inbound_ranges(struct rcar_pcie *pcie, mask &= ~0xf; while (cpu_addr < cpu_end) { + if (idx > MAX_NR_INBOUND_MAPS) { + dev_err(pcie->dev, "Failed to map inbound regions!\n"); + return -EINVAL; + } /* * Set up 64-bit inbound regions as the range parser doesn't * distinguish between 32 and 64-bit types. @@ -1067,11 +1071,6 @@ static int rcar_pcie_inbound_ranges(struct rcar_pcie *pcie, pci_addr += size; cpu_addr += size; idx += 2; - - if (idx > MAX_NR_INBOUND_MAPS) { - dev_err(pcie->dev, "Failed to map inbound regions!\n"); - return -EINVAL; - } } *index = idx; From patchwork Fri Aug 9 17:48:24 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Marek Vasut X-Patchwork-Id: 1144874 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=) Authentication-Results: ozlabs.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="OOVxdg+I"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 464t5K4CStz9sP7 for ; Sat, 10 Aug 2019 03:48:37 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2407579AbfHIRsg (ORCPT ); Fri, 9 Aug 2019 13:48:36 -0400 Received: from mail-wr1-f68.google.com ([209.85.221.68]:42414 "EHLO mail-wr1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2407544AbfHIRsg (ORCPT ); Fri, 9 Aug 2019 13:48:36 -0400 Received: by mail-wr1-f68.google.com with SMTP id b16so2287649wrq.9; Fri, 09 Aug 2019 10:48:34 -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=MxWxbYpuDLyPXJqWZEZbXyDs1NKMpHde29lzAKbggBk=; b=OOVxdg+Ib93B4i6HLZkuF3U5I7Nfa+4oXlZd1sTHg4efRRm4HpQCGfW3u1tXv2WnUb h89gmI+7eF7EUy1c7T7ZrQrYgcWWhXPhK+WtubcXLEG4iJlKYTFI9HdLoYdzbw6+MsTN +h+D7mkp/z0TaFcs6Nt44qqEYm9aIFFre3F7yw5WFFIivMkST67+3yI3gO4Cd+35K/U2 iJf0Kis92Sx1jt6CsrKC54pahdLBcDtvOsuCvxLSE05akq8pvhpZcmeKhr71lcFYb4RP 88jL9fje2+Qs52Vvnuij7bueFor34SoLDVXcjbyfaotcL/+fSSpw16BWj8cDQdiMJEBd S+lw== 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=MxWxbYpuDLyPXJqWZEZbXyDs1NKMpHde29lzAKbggBk=; b=A3TLqmFWscD0/AKzWEzY8ApHnPNn8bmqE6kTQtFxf7+B8daOlkhwNbAYMXicEPmC+F VkUKydz+MUFKDyZ/fLuzOQf64LyzU+UWtNgFEfnHgXuscr3nl/ruLAhWwzYEmmCRKxBG RPnU9xdsMhiEESIwzRfxCu7WSNUIYAPfxk5qhSOLz+JsVK2oly2lt6JirnHnnv6p/LCj svB3GZUz+eFNZpXi3C6+ZaQAFv9NfhW7wWtAd5C9FI13R5bqvSfcharxFapHiD2jCcje pQyGxdKDT/GobAJIoKHkiCt/VrftZeCyZxx+1eSfVKv+tOf72TjmtMAhsmjf2iRfpmDy 0t9g== X-Gm-Message-State: APjAAAV00V72pyS4Rb2BYLs0b7xtsGtnKddONemNvQbat4IWf5XrJ4Cr PVSz9tFiyci2MEAtoMqV/3N6iGOb X-Google-Smtp-Source: APXvYqxLmMILsJg7Nrrii86zP9ONrvZaK6dvnxrQ40Kwd4n94z+khQE7MzpijvusbGUgTAr+BX5A5Q== X-Received: by 2002:a5d:4108:: with SMTP id l8mr1237597wrp.113.1565372913877; Fri, 09 Aug 2019 10:48:33 -0700 (PDT) Received: from chi.lan (ip-86-49-35-8.net.upcbroadband.cz. [86.49.35.8]) by smtp.gmail.com with ESMTPSA id z18sm3999182wml.10.2019.08.09.10.48.32 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Fri, 09 Aug 2019 10:48:33 -0700 (PDT) From: marek.vasut@gmail.com To: linux-pci@vger.kernel.org Cc: Marek Vasut , Geert Uytterhoeven , Lorenzo Pieralisi , Wolfram Sang , linux-renesas-soc@vger.kernel.org Subject: [PATCH V2 2/3] PCI: rcar: Do not abort on too many inbound dma-ranges Date: Fri, 9 Aug 2019 19:48:24 +0200 Message-Id: <20190809174825.2572-2-marek.vasut@gmail.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190809174825.2572-1-marek.vasut@gmail.com> References: <20190809174825.2572-1-marek.vasut@gmail.com> MIME-Version: 1.0 Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org From: Marek Vasut In case the "dma-ranges" DT property contains either too many ranges or the range start address is unaligned in such a way that populating the range into the controller requires multiple entries, a situation may occur where all ranges cannot be loaded into the controller. Currently, the driver refuses to probe in such a situation. Relax this behavior, load as many ranges as possible and warn if some ranges do not fit anymore. Signed-off-by: Marek Vasut Cc: Geert Uytterhoeven Cc: Lorenzo Pieralisi Cc: Wolfram Sang Cc: linux-renesas-soc@vger.kernel.org To: linux-pci@vger.kernel.org --- V2: Update on top of 1/3 --- drivers/pci/controller/pcie-rcar.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/pci/controller/pcie-rcar.c b/drivers/pci/controller/pcie-rcar.c index 0f501acbc3bb..ee760bdc7786 100644 --- a/drivers/pci/controller/pcie-rcar.c +++ b/drivers/pci/controller/pcie-rcar.c @@ -1049,8 +1049,9 @@ static int rcar_pcie_inbound_ranges(struct rcar_pcie *pcie, while (cpu_addr < cpu_end) { if (idx > MAX_NR_INBOUND_MAPS) { - dev_err(pcie->dev, "Failed to map inbound regions!\n"); - return -EINVAL; + dev_warn(pcie->dev, + "Too many inbound regions, not all are mapped.\n"); + break; } /* * Set up 64-bit inbound regions as the range parser doesn't From patchwork Fri Aug 9 17:48:25 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Marek Vasut X-Patchwork-Id: 1144875 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=) Authentication-Results: ozlabs.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="HApaXr0M"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 464t5L3jvtz9sP3 for ; Sat, 10 Aug 2019 03:48:38 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2407580AbfHIRsi (ORCPT ); Fri, 9 Aug 2019 13:48:38 -0400 Received: from mail-wr1-f65.google.com ([209.85.221.65]:39806 "EHLO mail-wr1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726216AbfHIRsh (ORCPT ); Fri, 9 Aug 2019 13:48:37 -0400 Received: by mail-wr1-f65.google.com with SMTP id t16so8871046wra.6; Fri, 09 Aug 2019 10:48:36 -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=N8v/vsKYyFK0GSXJqNCKBYrpEsFmIGgnkcwBPmA9Px8=; b=HApaXr0M5NTA2CpdC56HOPjOzxweksKhrsgaZoNkFAvok7lzjlEqTwoKbMMzxxhOZW Hl8iOYfidKYwfJeWWXkpLqU7zkZVbk15k6AkoJZOLBccpBiCcukh9HpUAz6FXGgmW6M6 jkoKPoaGT+bZeJCTVRE8iVBLHxW2j43LaYHApusLkHiVjkcCe3UEin8e/FfiN3WJs7uK BLJuqnSrww/EStjbV+nSuuQLzYdAfd4fl83wfD1GU70hwzG6PYh1xsLykHpuR5UBE9b0 kpPjQLECAdOuTzCJI6eFpNjdiYV506xSwL8845+j6NlPfJ26QCO8ZpQdTNDeLdv5jf6m vOGw== 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=N8v/vsKYyFK0GSXJqNCKBYrpEsFmIGgnkcwBPmA9Px8=; b=Vrn9dUZIegabjcEShGKIXUOjXodpW72G2VVLiRfnpOTvYQALvU+O7b7EKRe10kbeRR /ztzFDrv3T022P+WFKcqHEfG3vywuBwaOcQ6jlAM8fwSRNhVxi0TmoKqFZ/k6bZFIDUo d9lcPCgWEQcISYbJjdChl5wXhmUf2G3RJnBSddDXgnHNJFhQvAS5BzUh5U1THz/EbCjR fp5PRT4pDlgdjE9DC1eP+6UM0ZErW44TErqqa31VgJsYEHX1IkKK+shx1SmACoIT/F0m 6pnpVCt14O5kI3nbn1i0aODIyaGjKV7NCX1xr3krVoiPZhu4RZn1aU+0zYWyCPoS/JSN nUgg== X-Gm-Message-State: APjAAAVBw0oXoRsFf7ZRUuXABkR3Dp8U9WP2HDaRYpfuy6fg4VraV9vx 4SYpVtRfL0skWatjhvcKC9eYrdt+ X-Google-Smtp-Source: APXvYqy06agShtnC/TUqiPscb+vnYZRqB/on6L/9kiqrRPA1PpjYm9vrQCEsbgngrLUBU65i3GwsDw== X-Received: by 2002:a5d:63d0:: with SMTP id c16mr20467423wrw.22.1565372915112; Fri, 09 Aug 2019 10:48:35 -0700 (PDT) Received: from chi.lan (ip-86-49-35-8.net.upcbroadband.cz. [86.49.35.8]) by smtp.gmail.com with ESMTPSA id z18sm3999182wml.10.2019.08.09.10.48.33 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Fri, 09 Aug 2019 10:48:34 -0700 (PDT) From: marek.vasut@gmail.com To: linux-pci@vger.kernel.org Cc: Marek Vasut , Geert Uytterhoeven , Lorenzo Pieralisi , Wolfram Sang , linux-renesas-soc@vger.kernel.org, Simon Horman Subject: [PATCH V2 3/3] PCI: rcar: Recalculate inbound range alignment for each controller entry Date: Fri, 9 Aug 2019 19:48:25 +0200 Message-Id: <20190809174825.2572-3-marek.vasut@gmail.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190809174825.2572-1-marek.vasut@gmail.com> References: <20190809174825.2572-1-marek.vasut@gmail.com> MIME-Version: 1.0 Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org From: Marek Vasut Due to hardware constraints, the size of each inbound range entry populated into the controller cannot be larger than the alignment of the entry's start address. Currently, the alignment for each "dma-ranges" inbound range is calculated only once for each range and the increment for programming the controller is also derived from it only once. Thus, a "dma-ranges" entry describing a memory at 0x48000000 and size 0x38000000 would lead to multiple controller entries, each 0x08000000 long. This is inefficient, especially considering that by adding the size to the start address, the alignment increases. This patch moves the alignment calculation into the loop populating the controller entries, thus updating the alignment for each controller entry. Signed-off-by: Marek Vasut Cc: Geert Uytterhoeven Cc: Lorenzo Pieralisi Cc: Wolfram Sang Cc: linux-renesas-soc@vger.kernel.org To: linux-pci@vger.kernel.org Reviewed-by: Simon Horman --- V2: Update on top of 1/3 --- drivers/pci/controller/pcie-rcar.c | 37 +++++++++++++++--------------- 1 file changed, 19 insertions(+), 18 deletions(-) diff --git a/drivers/pci/controller/pcie-rcar.c b/drivers/pci/controller/pcie-rcar.c index ee760bdc7786..dd8da6ef8323 100644 --- a/drivers/pci/controller/pcie-rcar.c +++ b/drivers/pci/controller/pcie-rcar.c @@ -1029,30 +1029,31 @@ static int rcar_pcie_inbound_ranges(struct rcar_pcie *pcie, if (restype & IORESOURCE_PREFETCH) flags |= LAM_PREFETCH; - /* - * If the size of the range is larger than the alignment of the start - * address, we have to use multiple entries to perform the mapping. - */ - if (cpu_addr > 0) { - unsigned long nr_zeros = __ffs64(cpu_addr); - u64 alignment = 1ULL << nr_zeros; - - size = min(range->size, alignment); - } else { - size = range->size; - } - /* Hardware supports max 4GiB inbound region */ - size = min(size, 1ULL << 32); - - mask = roundup_pow_of_two(size) - 1; - mask &= ~0xf; - while (cpu_addr < cpu_end) { if (idx > MAX_NR_INBOUND_MAPS) { dev_warn(pcie->dev, "Too many inbound regions, not all are mapped.\n"); break; } + /* + * If the size of the range is larger than the alignment of + * the start address, we have to use multiple entries to + * perform the mapping. + */ + if (cpu_addr > 0) { + unsigned long nr_zeros = __ffs64(cpu_addr); + u64 alignment = 1ULL << nr_zeros; + + size = min(range->size, alignment); + } else { + size = range->size; + } + /* Hardware supports max 4GiB inbound region */ + size = min(size, 1ULL << 32); + + mask = roundup_pow_of_two(size) - 1; + mask &= ~0xf; + /* * Set up 64-bit inbound regions as the range parser doesn't * distinguish between 32 and 64-bit types.