Received: by 10.213.65.68 with SMTP id h4csp545754imn; Fri, 16 Mar 2018 11:03:24 -0700 (PDT) X-Google-Smtp-Source: AG47ELtvGFuonz1eQd9Wmr0DA5dPCglUxSe3KtekFeBBQtcLxhWbBCwguF5rrD7c7KYapmCa2YaF X-Received: by 10.99.138.202 with SMTP id y193mr2134928pgd.224.1521223404544; Fri, 16 Mar 2018 11:03:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521223404; cv=none; d=google.com; s=arc-20160816; b=DKVL/5SAbl85tj6s6dO95cKOiBVJZkMHj3i1SCQBLq2NRcKvIQyaP94SkDiSNpX4t2 1+oxqspvuzIO8DBs5FoCP0p4DzLr4T7SmTyxB8U7uJXNgyfoZbkz3LJZPokxdnQr2l1E ZDEhrkJUJHH0z9WmwQhJyM+Y0pdBSDCtfRqWeQXYAMzagogYgsOgjXBUQWof3Snb3FrK cXbhw6GZDIKY1ljPSQ4oov7jGI2KUSEjjgDvY4XiTanWWxiA1JGkYXRO9R4cRrbhc1/W UL3TNaijuR67WuHWd3wWdnws3qpQY2WITO7Vru4hf4WmuIKrw1sEZGiU5s8MlkKIcB3Z sA9g== 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=jG99Ec5iJrC0h1PRUVl0R3jLP5bsvv02wqvTOZxH1rg=; b=gR1FTNdFkvZqFQ9m6iPwpMnM2NiNapi428oS5ezwkmEEyj+90yQVOB1/aCHk7c1Pmn w/eyQSiU5kZDFZtDpIkuALef7gX1n3dVidpsSN5NTwvSqKcX8XOcXsGwgTxelQrecOw8 rK9cgi8hC1kXYxOKSqr1Eji/iGyZSZAA1SqoIW4KhbJzDMvBUR4Kx5BoOP0JXVVa0GLf uzDR8Te0Uxqwp7d61/UtnAJVlh5Fbz2RmSggdEstdsVWOqJfsJh+dmuDHZs2DHUOTwa2 4BMb0ZQcMb4dwNpvoMcKZaBgEr0BPbSilRtVyNOqqZMosdMdr/GiwVKZw7kViTjx60x7 duUw== 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 z13si5760093pfh.217.2018.03.16.11.03.08; Fri, 16 Mar 2018 11:03:24 -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; 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 S1751905AbeCPSBv (ORCPT + 99 others); Fri, 16 Mar 2018 14:01:51 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:34698 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750941AbeCPSBu (ORCPT ); Fri, 16 Mar 2018 14:01:50 -0400 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 ACCA880D; Fri, 16 Mar 2018 11:01:49 -0700 (PDT) Received: from red-moon (unknown [10.1.206.55]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id CD0EA3F24A; Fri, 16 Mar 2018 11:01:47 -0700 (PDT) Date: Fri, 16 Mar 2018 18:02:20 +0000 From: Lorenzo Pieralisi To: Niklas Cassel Cc: kishon@ti.com, Bjorn Helgaas , Sekhar Nori , John Keeping , Shawn Lin , Niklas Cassel , Cyrille Pitchen , linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4 1/5] PCI: endpoint: BAR width should not depend on sizeof dma_addr_t Message-ID: <20180316180220.GA13505@red-moon> References: <20180308133331.19464-1-niklas.cassel@axis.com> <20180308133331.19464-2-niklas.cassel@axis.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180308133331.19464-2-niklas.cassel@axis.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 08, 2018 at 02:33:26PM +0100, Niklas Cassel wrote: > If a BAR supports 64-bit width or not depends on the hardware, > and should thus not depend on sizeof(dma_addr_t). > > Since this driver is generic, default to always using BAR width > of 32-bits. 64-bit BARs can easily be tested by replacing > PCI_BASE_ADDRESS_MEM_TYPE_32 with PCI_BASE_ADDRESS_MEM_TYPE_64 > in bar_flags. > > Signed-off-by: Niklas Cassel > --- > Note to Lorenzo/Bjorn: > It is not trivial to convert the bar_size + bar_flags + > struct pci_epf->bar member array to an array of struct resources, > since we need to be able to store the addresses returned > by dma_alloc_coherent(), which is of type dma_addr_t. > struct resource uses resource_size_t, which is defined as phys_addr_t. > E.g. ARTPEC-7 uses 64-bit dma_addr_t, but only 32-bit phys_addr_t. > > drivers/pci/endpoint/functions/pci-epf-test.c | 15 +++++++++------ > 1 file changed, 9 insertions(+), 6 deletions(-) > > diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c b/drivers/pci/endpoint/functions/pci-epf-test.c > index 800da09d9005..7c70433b11a7 100644 > --- a/drivers/pci/endpoint/functions/pci-epf-test.c > +++ b/drivers/pci/endpoint/functions/pci-epf-test.c > @@ -71,6 +71,14 @@ struct pci_epf_test_data { > }; > > static int bar_size[] = { 512, 512, 1024, 16384, 131072, 1048576 }; > +static int bar_flags[] = { > + PCI_BASE_ADDRESS_SPACE_MEMORY | PCI_BASE_ADDRESS_MEM_TYPE_32, > + PCI_BASE_ADDRESS_SPACE_MEMORY | PCI_BASE_ADDRESS_MEM_TYPE_32, > + PCI_BASE_ADDRESS_SPACE_MEMORY | PCI_BASE_ADDRESS_MEM_TYPE_32, > + PCI_BASE_ADDRESS_SPACE_MEMORY | PCI_BASE_ADDRESS_MEM_TYPE_32, > + PCI_BASE_ADDRESS_SPACE_MEMORY | PCI_BASE_ADDRESS_MEM_TYPE_32, > + PCI_BASE_ADDRESS_SPACE_MEMORY | PCI_BASE_ADDRESS_MEM_TYPE_32 > +}; Niklas, I think you are almost there, I have one question though to address that can even simplify the patchset. If, according to your own commit logs (and my reading of the code), the Cadence driver makes a decision on the BAR size just by checking the corresponding region size (I would be happy to hear the reason underpinning that choice, BTW), why can't we do the same for DWC (ie to let the DWC driver decides whether a BAR should be 64 or 32 bits ?) This would mean that in this patch we would not bother about the BAR 32/64 size flag at all. Thoughts ? Lorenzo > > static int pci_epf_test_copy(struct pci_epf_test *epf_test) > { > @@ -358,7 +366,6 @@ static void pci_epf_test_unbind(struct pci_epf *epf) > > static int pci_epf_test_set_bar(struct pci_epf *epf) > { > - int flags; > int bar; > int ret; > struct pci_epf_bar *epf_bar; > @@ -367,15 +374,11 @@ static int pci_epf_test_set_bar(struct pci_epf *epf) > struct pci_epf_test *epf_test = epf_get_drvdata(epf); > enum pci_barno test_reg_bar = epf_test->test_reg_bar; > > - flags = PCI_BASE_ADDRESS_SPACE_MEMORY | PCI_BASE_ADDRESS_MEM_TYPE_32; > - if (sizeof(dma_addr_t) == 0x8) > - flags |= PCI_BASE_ADDRESS_MEM_TYPE_64; > - > for (bar = BAR_0; bar <= BAR_5; bar++) { > epf_bar = &epf->bar[bar]; > ret = pci_epc_set_bar(epc, epf->func_no, bar, > epf_bar->phys_addr, > - epf_bar->size, flags); > + epf_bar->size, bar_flags[bar]); > if (ret) { > pci_epf_free_space(epf, epf_test->reg[bar], bar); > dev_err(dev, "failed to set BAR%d\n", bar); > -- > 2.14.2 >