Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp512948iob; Wed, 4 May 2022 01:43:02 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyP6ugPz5XoH3zU4vk1y45D5MQREj4tcYZHYlPBQ34iue7nmZEsIcPohhko6esV5udglOyO X-Received: by 2002:a63:7457:0:b0:3ab:224c:fef4 with SMTP id e23-20020a637457000000b003ab224cfef4mr17292121pgn.149.1651653781915; Wed, 04 May 2022 01:43:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1651653781; cv=none; d=google.com; s=arc-20160816; b=C58bcpxUx9tn4B6Tbnt5QfbXBZYr2jC9sixo/ICmR0gIH3OVqrEqt2fHYe+aVYB8Uc JKIBBGcTFjsB9nVDTRWi19HHUrNCpuFExDgaJhOvzgfK1NxSY0qCs6jAzUg27G6Eh7Ax cg85sFhERLMOMcGD4tj44hbg+yIb8Zdc7kOd8l9bW1NIDX9ca9vIu+/qii4WAdxvG+bf TkzwS6L45CgPTMQaW7QC0079PC5oH9ujZKCaKEksiMoHVh/J7aTysHPPfDe38oDXBT5d l1plbb92XyzQMw2hIxQ6D5Oy3+steteRseoDJbnI6qt/Xi5/ByccvQkkhaSBXc/JmoQx Vmsg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature:dkim-filter; bh=D8s4kkAaMIVtZOOq7LxKW6V3CsdUxny+ktG1+sp0I80=; b=ERmfEFG+CyXsbElA7kE6LLimENjtfqgKOev6yvwQGlYPhUYFVxEWphMVwj7mwmCPKX 3fy6EFDKU+E1VcXBjybeDa0Gx21kRiXvXueza22zcfL+yHNUzWhnUWdFG//4ncemkGkj jz9K25+FSyjP7nt6kZTOSnFfxWLK4ItfW1ybqE2zxxp5UDR1Fb8UDYXK3+3eDdVakImv NRKTbENWh5QZzVo0jC2QSdq6mBPRUkuCrP3hfevyD3X8zKO488Yc+p9zFxMkx0qAcGXZ hCPukpp+tW4zIJ+8sxmhuvEd8yJNaPVv8w+uDwZnf8ZO52eM9lI0zVhB2RD1a+N/BL97 paoQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@baikalelectronics.ru header.s=mail header.b=a5fr0Paw; 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 j64-20020a638043000000b003ab5d468636si3005922pgd.548.2022.05.04.01.42.47; Wed, 04 May 2022 01:43:01 -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; dkim=pass header.i=@baikalelectronics.ru header.s=mail header.b=a5fr0Paw; 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 S242859AbiECV1U (ORCPT + 99 others); Tue, 3 May 2022 17:27:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41146 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242799AbiECV1F (ORCPT ); Tue, 3 May 2022 17:27:05 -0400 Received: from mail.baikalelectronics.ru (mail.baikalelectronics.com [87.245.175.226]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 6279541620; Tue, 3 May 2022 14:23:31 -0700 (PDT) Received: from mail.baikalelectronics.ru (unknown [192.168.51.25]) by mail.baikalelectronics.ru (Postfix) with ESMTP id 2AE8216DA; Wed, 4 May 2022 00:24:04 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 mail.baikalelectronics.ru 2AE8216DA DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baikalelectronics.ru; s=mail; t=1651613044; bh=D8s4kkAaMIVtZOOq7LxKW6V3CsdUxny+ktG1+sp0I80=; h=From:To:CC:Subject:Date:In-Reply-To:References:From; b=a5fr0Paw9piakX2d30BiZCXR/w2GqYURaiGLQhXKIMumZnDzOIz8YNWYiGFhIa/Cz tppZf5QfT54pCNTSqWqVWA7CzVm38xkEECgro5GWot9zCVP0VN3fvWLsqH9f5gSZeO pYaShBC4OVuKqAlZ0tdIoXWcSSG3DTkU2cjdWBv0= Received: from localhost (192.168.53.207) by mail (192.168.51.25) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 4 May 2022 00:23:30 +0300 From: Serge Semin To: Jingoo Han , Gustavo Pimentel , Bjorn Helgaas , Lorenzo Pieralisi , Rob Herring , =?UTF-8?q?Krzysztof=20Wilczy=C5=84ski?= , Pankaj Dubey , Shradha Todi CC: Serge Semin , Serge Semin , Alexey Malahov , Pavel Parkhomenko , Frank Li , Manivannan Sadhasivam , , Subject: [PATCH v2 05/13] PCI: dwc: Set INCREASE_REGION_SIZE flag based on limit address Date: Wed, 4 May 2022 00:22:52 +0300 Message-ID: <20220503212300.30105-6-Sergey.Semin@baikalelectronics.ru> In-Reply-To: <20220503212300.30105-1-Sergey.Semin@baikalelectronics.ru> References: <20220503212300.30105-1-Sergey.Semin@baikalelectronics.ru> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: MAIL.baikal.int (192.168.51.25) To mail (192.168.51.25) X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS, T_FILL_THIS_FORM_SHORT,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 It was wrong to use the region size parameter in order to determine whether the INCREASE_REGION_SIZE flag needs to be set for the outbound iATU entry because in general there are cases when combining a region base address and size together produces the out of bounds upper range limit while upper_32_bits(size) still returns zero. So having a region size within the permitted values doesn't mean the region limit address will fit to the corresponding CSR. Here is the way iATU calculates the in- and outbound untranslated regions if the INCREASE_REGION_SIZE flag is cleared [1]: Start address: End address: 63 31 0 63 31 0 +---------------+---------------+ +---------------+---------------+ | | | 0s | | | | Fs | +---------------+---------------+ +---------------+---------------+ upper base | lower base !upper! base | limit address address address address So the region start address is determined by the iATU lower and upper base address registers, while the region upper boundary is calculated based on the 32-bits limit address register and the upper part of the base address. In accordance with that logic for instance the range 0xf0000000 @ 0x20000000 does have the size smaller than 4GB, but the actual limit address turns to be invalid forming the untranslated address map as [0xf0000000; 0x1000FFFF], which isn't what the original range was. In order to fix that we need to check whether the size after being added to the lower part of the base address causes the 4GB range overflow. If it does then we need to set the INCREASE_REGION_SIZE flag thus activating the extended limit address by means of an additional iATU CSR (upper limit address register) [2]: Start address: End address: 63 31 0 63 x 31 0 +---------------+---------------+ +---------------+---------------+ | | | 0s | | | | | Fs | +---------------+---------------+ +---------------+---------------+ upper base | lower base upper | upper | limit address address address base | limit | address|address| Otherwise there is enough room in the 32-bits wide limit address register, and the flag can be left unset. Note the case when the size-based flag setting approach is correct implies requiring to have the size-aligned base addresses only. But that constraint isn't relevant to the PCIe ranges accepted by the kernel. There is also no point in implementing it either seeing the problem can be easily fixed by checking the whole limit address instead of the region size. [1] DesignWare Cores PCI Express Controller Databook - DWC PCIe Root Port, v5.40a, March 2019, fig.3-36, p.175 [2] DesignWare Cores PCI Express Controller Databook - DWC PCIe Root Port, v5.40a, March 2019, fig.3-37, p.176 Fixes: 5b4cf0f65324 ("PCI: dwc: Add upper limit address for outbound iATU") Signed-off-by: Serge Semin Reviewed-by: Manivannan Sadhasivam --- Changelog v2: - Fix the end address in the example of the patch log. It should be 0x1000FFFF and not 0x0000FFFF (@Manivannan). --- drivers/pci/controller/dwc/pcie-designware.c | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/drivers/pci/controller/dwc/pcie-designware.c b/drivers/pci/controller/dwc/pcie-designware.c index 7dc8c360a0d4..d737af058903 100644 --- a/drivers/pci/controller/dwc/pcie-designware.c +++ b/drivers/pci/controller/dwc/pcie-designware.c @@ -287,8 +287,8 @@ static void dw_pcie_prog_outbound_atu_unroll(struct dw_pcie *pci, u8 func_no, dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_UPPER_TARGET, upper_32_bits(pci_addr)); val = type | PCIE_ATU_FUNC_NUM(func_no); - val = upper_32_bits(size - 1) ? - val | PCIE_ATU_INCREASE_REGION_SIZE : val; + if (upper_32_bits(limit_addr) > upper_32_bits(cpu_addr)) + val |= PCIE_ATU_INCREASE_REGION_SIZE; if (pci->version == 0x490A) val = dw_pcie_enable_ecrc(val); dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_REGION_CTRL1, val); @@ -315,6 +315,7 @@ static void __dw_pcie_prog_outbound_atu(struct dw_pcie *pci, u8 func_no, u64 pci_addr, u64 size) { u32 retries, val; + u64 limit_addr; if (pci->ops && pci->ops->cpu_addr_fixup) cpu_addr = pci->ops->cpu_addr_fixup(pci, cpu_addr); @@ -325,6 +326,8 @@ static void __dw_pcie_prog_outbound_atu(struct dw_pcie *pci, u8 func_no, return; } + limit_addr = cpu_addr + size - 1; + dw_pcie_writel_dbi(pci, PCIE_ATU_VIEWPORT, PCIE_ATU_REGION_OUTBOUND | index); dw_pcie_writel_dbi(pci, PCIE_ATU_LOWER_BASE, @@ -332,17 +335,18 @@ static void __dw_pcie_prog_outbound_atu(struct dw_pcie *pci, u8 func_no, dw_pcie_writel_dbi(pci, PCIE_ATU_UPPER_BASE, upper_32_bits(cpu_addr)); dw_pcie_writel_dbi(pci, PCIE_ATU_LIMIT, - lower_32_bits(cpu_addr + size - 1)); + lower_32_bits(limit_addr)); if (pci->version >= 0x460A) dw_pcie_writel_dbi(pci, PCIE_ATU_UPPER_LIMIT, - upper_32_bits(cpu_addr + size - 1)); + upper_32_bits(limit_addr)); dw_pcie_writel_dbi(pci, PCIE_ATU_LOWER_TARGET, lower_32_bits(pci_addr)); dw_pcie_writel_dbi(pci, PCIE_ATU_UPPER_TARGET, upper_32_bits(pci_addr)); val = type | PCIE_ATU_FUNC_NUM(func_no); - val = ((upper_32_bits(size - 1)) && (pci->version >= 0x460A)) ? - val | PCIE_ATU_INCREASE_REGION_SIZE : val; + if (upper_32_bits(limit_addr) > upper_32_bits(cpu_addr) && + pci->version >= 0x460A) + val |= PCIE_ATU_INCREASE_REGION_SIZE; if (pci->version == 0x490A) val = dw_pcie_enable_ecrc(val); dw_pcie_writel_dbi(pci, PCIE_ATU_CR1, val); -- 2.35.1