Received: by 2002:a4a:3008:0:0:0:0:0 with SMTP id q8-v6csp861975oof; Wed, 19 Sep 2018 07:42:24 -0700 (PDT) X-Google-Smtp-Source: ANB0VdbFGnFjzwpVM1JXofHev+CHoMDaXms21+GZv+7amVv6oTijWKo0KeYmoMCfK7OPUZdQSFo2 X-Received: by 2002:a63:de4b:: with SMTP id y11-v6mr32802743pgi.435.1537368144569; Wed, 19 Sep 2018 07:42:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1537368144; cv=none; d=google.com; s=arc-20160816; b=vpO1wHcP8dmKbpsfIsMmwogEMAuXb2rwnIcPugpFdxPQAPQ6VcC8oks6X5rZlDNeJa I7lhc4iYqWqpGqneF0VVs4DFdCCEKW4kBVv34b5lV32depfBABHPY90wqwLfbrlv8Ss2 Uwln/MX1nqeGX35nWZT5Nxu/sPGGwcldDhFIAAZm5X8tvgpgw6giXDMRJ/+HnyBDTUI3 GumJkZYexvoekoH008lpnMVOVvd6hvHjP99kpAXh5kuyCZfAAtFk4q66aGKmFOw2AeLQ 9U33MrfnFUFrVsoteAXYNWZxuztGYvBunRykxBTR2iwh09vZXPaoO0tEcRYeZj1+QkFd H4FA== 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; bh=MHRReYiy7W5HQ3RVoAONkH3VF8J1YmGE/tSVvgjGRqE=; b=hmsnBswjtQt8TsEHmFfg48ONmI1Hgk5VILtLW0pJ1sXzc0i9Cb0Sdup8psSBRUbKUQ XlxF0/pHUb4AfFx4U8+w2/vKriR+DBzS4+J4o0m46sJ9ve7A11rBuOG8BsPHg58v/NqD zGRA4fz+44F02vFM2QNSPk8Xra4JGuK/bi1XwihglWJ6j5P3HbxICcoKyyBmIgrq9maM vegC04wEGIZZQV1sdBvHEr60Ooec8UjxYHIIB5FQTnh/98DHLIlg1SXXqJujh29LtLDn biO9iVHaK/qL6UWO/zVE5cRKFx2/Yx5/THExkFVi7l6LKdCdRYWm1u8vAYwjZ4CKp6PJ kUXw== 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 y11-v6si13795753pgj.171.2018.09.19.07.42.08; Wed, 19 Sep 2018 07:42: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 S1731978AbeISUTb (ORCPT + 99 others); Wed, 19 Sep 2018 16:19:31 -0400 Received: from verein.lst.de ([213.95.11.211]:53964 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731917AbeISUTb (ORCPT ); Wed, 19 Sep 2018 16:19:31 -0400 Received: by newverein.lst.de (Postfix, from userid 2407) id 22E1F68D83; Wed, 19 Sep 2018 16:41:19 +0200 (CEST) Date: Wed, 19 Sep 2018 16:41:19 +0200 From: Christoph Hellwig To: Jim Quinlan Cc: linux-kernel@vger.kernel.org, Lorenzo Pieralisi , Bjorn Helgaas , Brian Norris , Gregory Fong , Florian Fainelli , bcm-kernel-feedback-list@broadcom.com, linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Christoph Hellwig Subject: Re: [PATCH v5 11/12] ARM64: add dma remap for BrcmSTB PCIe Message-ID: <20180919144119.GB29096@lst.de> References: <1537367527-20773-1-git-send-email-jim2101024@gmail.com> <1537367527-20773-12-git-send-email-jim2101024@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1537367527-20773-12-git-send-email-jim2101024@gmail.com> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 19, 2018 at 10:32:06AM -0400, Jim Quinlan wrote: > +#if defined(CONFIG_ARM64) Please use plain #ifdef where possible. > +dma_addr_t __phys_to_dma(struct device *dev, phys_addr_t paddr) > +{ > + return brcm_phys_to_dma(dev, paddr); > +} > + > +phys_addr_t __dma_to_phys(struct device *dev, dma_addr_t dev_addr) > +{ > + return brcm_dma_to_phys(dev, dev_addr); > +} > +#endif How is this going to work for a kernel with BrcmSTB built in, but running on a more standard arm64 SOC? I suspect we really just want a set of ranges hanging off struct device (conditional on a config option). Each SoC can then fill it at boot time, and if it is non-NULL the DMA code will use it instead of calling __phys_to_dma and __dma_to_phys. In fact the single range version could probably just replace the existing dma_pfn_offset field.