Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp3848407ybb; Tue, 31 Mar 2020 13:14:38 -0700 (PDT) X-Google-Smtp-Source: APiQypJjISkkEsKyVluxAeKP6g3s0+iPzqer/l8TTWUd6r3Q7iLv/AfR0itmnJyFiXRpvI5NaLnp X-Received: by 2002:a54:4797:: with SMTP id o23mr469624oic.12.1585685677871; Tue, 31 Mar 2020 13:14:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585685677; cv=none; d=google.com; s=arc-20160816; b=BswVMu5M1pyhKLuYCdGgJBLs8wDuvgeRfhvmvsrgCjEo9ijBiqY2GMOEVJyQ6/NyLT M8gMtbk3sPL2kMOYA5oziFc+X48pF4z0SLFTPwj0FVM2vzYOBqrunCaN0WdWqW1xgVuL kBLmBqF4qqtmEDKfLGIJQya0HJOYvwEUwW6s81d9rdrEgpSyBk2ksosbOGNlLrOe6u86 gjJy6Vz6lkYVk3OfxryTNdJW+OOdoxFwcFTPwwy4O82vJAwj1RU5Csz/t87ODZ9/ioE7 StKt3P+irPGaZAc5v/EnRGf5Pg+cCaeOETcBrdZMnRTkSocCZhMxq6wf/EdFAYNTJ7cW raRw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:message-id:subject:cc:to:from:date :dkim-signature; bh=m7ANc9NZdd9eMDDLdy6p/bol80uK6kRIbOqH2/r7W5o=; b=GyLwiAOw9aq2TtNRUQksbsVAJ3G5iLV6NwFAYsyVUi39zDQ/BaLqsowlOFFlZZXRBH yXZTBvDcg3t2yFjzHKkbnOz7fQ4sYqYum3+6e3FbzB8Na/mQCGN3fY7Ah4e4e3/r65eo kwuh9eYvAxWw6aGl0PescjhA9mJ7pFHlW/yUpZSeuGA98Dxvs1BELjFEu+40DMqweqEs SzoLXW+LvK877IIbm8KzhgAZ+AxPh/SKSCqsWLzhTIYoTfs0kzn+BYP7i5qatRYEm/1M qVYgA4c9Fl5KOb/AbXUfqv6P5HKA0Pye3cOxYzl8H4C5eyDSnu17LBFNLz9PIZm1cj+0 5KDg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="wP/hrfAL"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o5si5482746otp.191.2020.03.31.13.14.25; Tue, 31 Mar 2020 13:14:37 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="wP/hrfAL"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730907AbgCaUM3 (ORCPT + 99 others); Tue, 31 Mar 2020 16:12:29 -0400 Received: from mail.kernel.org ([198.145.29.99]:51522 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727937AbgCaUM3 (ORCPT ); Tue, 31 Mar 2020 16:12:29 -0400 Received: from localhost (mobile-166-175-186-165.mycingular.net [166.175.186.165]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 51F43206EB; Tue, 31 Mar 2020 20:12:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1585685548; bh=7/omDWAID+5hcfz/WYWgmxUkv9xqXa5HemPJhM6NYEk=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=wP/hrfALbj0aKSLxvoh+umRqrfvSP7x6pVgVmI50E6tJyUMAeUU37qGcgya1LB6Ru T368mYhIQrlsqN5WtwBmigCm9rtmgcpfr3ohnRobzzQVy9tIlgBWJjVOeTicX3gAqE YtDfNtCgydegOJdLZ9KMGaZPu0ZSFXdMqtbCh7BM= Date: Tue, 31 Mar 2020 15:12:25 -0500 From: Bjorn Helgaas To: Alan Mikhak Cc: linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org, jingoohan1@gmail.com, gustavo.pimentel@synopsys.com, lorenzo.pieralisi@arm.com, amurray@thegoodpenguin.co.uk, kishon@ti.com, paul.walmsley@sifive.com Subject: Re: [PATCH] PCI: Warn about MEM resource size being too big Message-ID: <20200331201225.GA19649@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1585613987-8453-1-git-send-email-alan.mikhak@sifive.com> User-Agent: Mutt/1.12.2 (2019-09-21) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org $ git log --oneline drivers/pci/controller/dwc/pcie-designware-host.c 7fe71aa84b43 ("PCI: dwc: Use pci_parse_request_of_pci_ranges()") 1137e61dcb99 ("PCI: dwc: Fix find_next_bit() usage") 0b24134f7888 ("PCI: dwc: Add validation that PCIe core is set to correct mode") 3924bc2fd1b6 ("PCI: dwc: Group DBI registers writes requiring unlocking") ca98329d3b58 ("PCI: dwc: Export APIs to support .remove() implementation") 9d071cade30a ("PCI: dwc: Add API support to de-initialize host") fe23274f72f4 ("PCI: dwc: Save root bus for driver remove hooks") Please make yours match. Please mention something about the 32-bit limit instead of just "being too big". Wrap the commit log to 75 columns to be consistent with the rest of the history. On Mon, Mar 30, 2020 at 05:19:47PM -0700, Alan Mikhak wrote: > Output a warning for MEM resource size with > non-zero upper 32-bits. > > ATU programming functions limit the size of > the translated region to 4GB by using a u32 size > parameter. Function dw_pcie_prog_outbound_atu() > does not program the upper 32-bit ATU limit > register. This may result in undefined behavior > for resource sizes with non-zero upper 32-bits. > > For example, a 128GB address space starting at > physical CPU address of 0x2000000000 with size of > 0x2000000000 needs the following values programmed > into the lower and upper 32-bit limit registers: > 0x3fffffff in the upper 32-bit limit register > 0xffffffff in the lower 32-bit limit register > > Currently, only the lower 32-bit limit register is > programmed with a value of 0xffffffff but the upper > 32-bit limit register is not being programmed. > As a result, the upper 32-bit limit register remains > at its default value after reset of 0x0. This would > be a problem for a 128GB PCIe space because in > effect its size gets reduced to 4GB. > > ATU programming functions can be changed to > specify a u64 size parameter for the translated > region. Along with this change, the internal > calculation of the limit address, the address of > the last byte in the translated region, needs to > change such that both the lower 32-bit and upper > 32-bit limit registers can be programmed correctly. > > Changing the ATU programming functions is high > impact. Without change, this issue can go > unnoticed. A warning may prompt the user to > look into possible issues. So this is basically a warning, and we could actually *fix* the problem with more effort? I vote for the fix. > This limitation also means that multiple ATUs > would need to be used to map larger regions. > > Signed-off-by: Alan Mikhak > --- > drivers/pci/controller/dwc/pcie-designware-host.c | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c > index 395feb8ca051..37a8c71ef89a 100644 > --- a/drivers/pci/controller/dwc/pcie-designware-host.c > +++ b/drivers/pci/controller/dwc/pcie-designware-host.c > @@ -325,6 +325,7 @@ int dw_pcie_host_init(struct pcie_port *pp) > struct pci_bus *child; > struct pci_host_bridge *bridge; > struct resource *cfg_res; > + resource_size_t mem_size; > u32 hdr_type; > int ret; > > @@ -362,7 +363,10 @@ int dw_pcie_host_init(struct pcie_port *pp) > case IORESOURCE_MEM: > pp->mem = win->res; > pp->mem->name = "MEM"; > - pp->mem_size = resource_size(pp->mem); > + mem_size = resource_size(pp->mem); > + if (upper_32_bits(mem_size)) > + dev_warn(dev, "MEM resource size too big\n"); > + pp->mem_size = mem_size; > pp->mem_bus_addr = pp->mem->start - win->offset; > break; > case 0: > -- > 2.7.4 >