Received: by 10.223.185.116 with SMTP id b49csp6246476wrg; Wed, 28 Feb 2018 06:24:08 -0800 (PST) X-Google-Smtp-Source: AH8x2278vzNjWEP3YmVGuARZxJVRKtURalYNO4yAzZH20QgkCvceOkD5OqCvWJ9wXvgFP2OpXS1/ X-Received: by 10.98.219.129 with SMTP id f123mr18107993pfg.195.1519827848626; Wed, 28 Feb 2018 06:24:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519827848; cv=none; d=google.com; s=arc-20160816; b=G9SEOhjl5Qpalsnb4FAfBW0QVKyGONW46Bb9EVidanhmnXlxPiDLl/7BwIceO2Dy4a KwaNDz0QPBPWzuhbnvOVCVOA2EnlYkK5Djp+cYSJSAuSS0Trnbz0/RIU1QVHnGWfMXj3 vzIlb0BGhIkZm+mhKzlOwAkt/VReXT0BdWP7g+pJqTSG7qkChruITGQQvaUhLd0HKZcz fcFxx2dlce0oCCjIBBnh/axiSFoDFKzzgSnH/ZqX1LFfoBzja2GuOi8WxQf6kD55zc8M wqAWbxcbprsOyNtSiTyNheN3UbjrjRPtdDfnsfT5lDNpVKCW/dmUiQFXAxSMkGY6xQMC f4zQ== 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:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=1Nxe3edL4PnhJf7BbXXbejxraUAjKaoxkveJOaq0Co4=; b=QPlmWCiOXs0zFvV+BILUJmRjNYWa+YolhHajOsgkSle8OE0hIL2TLdYCAqGx/UPizn n/nLZNab9G8yCNxBLOTr0M8Xv/I+G8OyFpBffbwMBZ3Ikb3Z+VU9e0Ey7HL6v5/2y5fw /qUR/79bfand/pT3L86Pg++65zt1s/0p+NeYrS6tePVdZlDg4GBgtMi6ZwspE+EI3bmB CHapTu4yovGuLD/x2deJY8xcwMXHE/ocUaWNISBzC4vSK9Z+cdQOj88xcluurr/qaZMz gGyF2c/xg9oCj3brV5W0IlgbwSpb1pKw7qN2yoqd+WnxkfNCWRwxY9xvvDA6VUvoFyO8 4vQg== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x10-v6si1350129pln.30.2018.02.28.06.23.53; Wed, 28 Feb 2018 06:24:08 -0800 (PST) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752604AbeB1OVy (ORCPT + 99 others); Wed, 28 Feb 2018 09:21:54 -0500 Received: from foss.arm.com ([217.140.101.70]:50266 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752157AbeB1OVx (ORCPT ); Wed, 28 Feb 2018 09:21:53 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D4F9E15AD; Wed, 28 Feb 2018 06:21:52 -0800 (PST) Received: from e107981-ln.cambridge.arm.com (e107981-ln.cambridge.arm.com [10.1.207.54]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 1445F3F487; Wed, 28 Feb 2018 06:21:50 -0800 (PST) Date: Wed, 28 Feb 2018 14:21:48 +0000 From: Lorenzo Pieralisi To: Niklas Cassel Cc: kishon@ti.com, Bjorn Helgaas , Sekhar Nori , Shawn Lin , Cyrille Pitchen , Niklas Cassel , John Keeping , linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 1/3] PCI: endpoint: Handle 64-bit BARs properly Message-ID: <20180228142148.GD21854@e107981-ln.cambridge.arm.com> References: <20180227115908.14593-1-niklas.cassel@axis.com> <20180227115908.14593-2-niklas.cassel@axis.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180227115908.14593-2-niklas.cassel@axis.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 27, 2018 at 12:59:05PM +0100, Niklas Cassel wrote: > 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, PCI_BASE_ADDRESS_MEM_TYPE_64 is detected through a sizeof(dma_addr_t). I thought we decided to describe the BARs not as dma_addr_t + size but as resources, which would allow you to have flags describing their actual size. Current code has a fixed BAR size defined by the dma_addr_t type size and I do not think that's what we really want. How is (in HW I mean) actually the BAR size configured in a given EPF ? Thanks, Lorenzo > 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 64d8a17f8094..ecbf6a7750dc 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; > -- > 2.14.2 >