Received: by 10.223.176.46 with SMTP id f43csp375257wra; Thu, 25 Jan 2018 23:54:40 -0800 (PST) X-Google-Smtp-Source: AH8x226BAwhKlXqE7rPTXVX0tAa/rTGljT6QO6WLufsgbqx88lQyjriDDRaUl3bQr5kmwbeaECY4 X-Received: by 10.99.110.205 with SMTP id j196mr14816792pgc.54.1516953280202; Thu, 25 Jan 2018 23:54:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516953280; cv=none; d=google.com; s=arc-20160816; b=NihlciHEdSit8DhwIE+TiYTaLF9kghtw2MvCnkYK0IB0N1rv1ktGR63iuSitwYoxYq tA1bOA3ffN0oXNwHl5FUDFT6uN2569WpQasZZYPU9uMEaa2nlozdZSJf6OmkCnzlUANg 9Z7DFtWwkatLGAsY9AY5yXZ1Jej7YakKnQQ7T99QnCmqLNrrTId28UWq8Qiq7djEw4TC c+WJ3VtsWUUhb+4aKkg6vwyrE1Fl/+h2bzwMN7H6+zUNNau3D6ArpB0daOqWqdiD1Xkz PQXtcAFfPFzyxRNDIxtEfrYvcfX9N3Gk8LECr29RYoQC70eQJRNM3HKoKFk4qnUW8567 x+mw== 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=XAEX2kGvTW0oYgAdRyKoTfmW8Z2JhI7Kamgk52XbFJk=; b=kPJRT5gANhGirBQlhMIRSkFLvPIP/zZbo1/pJXovHwUla6fKyCuuj+AXrfodolrbBV o6afTjJ0OTk9MVoGL2Qrdbm9k47lheA53ds70rigpRB0ehvFTrlB3jqAW1/OvthrOu8I GdNtiM1rh1i7O7mH+YdNw5RaUtgyjepmWj2blcrQ+VbGJoUPa3EfBq3m2tB04FOhs310 0DCpNE2KLGDWY39kP8kQxrfKH4XTf5/XhGe/FJCwkWWWsWfj8s7SPACt+NPj2Iuv23NM y2Vtzry1KNRRZzw2zKbuox/MjIt2YrCumRLi+OE0M9PwhmqdZZ3l+YEx00+koV3lgHt5 HF9w== 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 f89-v6si3353287plb.344.2018.01.25.23.54.26; Thu, 25 Jan 2018 23:54:40 -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 S1752168AbeAZHxr (ORCPT + 99 others); Fri, 26 Jan 2018 02:53:47 -0500 Received: from verein.lst.de ([213.95.11.211]:41718 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751852AbeAZHxp (ORCPT ); Fri, 26 Jan 2018 02:53:45 -0500 Received: by newverein.lst.de (Postfix, from userid 2407) id DBAEC68D62; Fri, 26 Jan 2018 08:53:43 +0100 (CET) Date: Fri, 26 Jan 2018 08:53:43 +0100 From: Christoph Hellwig To: Florian Fainelli Cc: Christoph Hellwig , Rob Herring , Jim Quinlan , "linux-kernel@vger.kernel.org" , Bjorn Helgaas , Catalin Marinas , Will Deacon , Brian Norris , Russell King , Robin Murphy , Jonas Gorski , Lorenzo Pieralisi , Mark Rutland , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Linux-MIPS , linux-pci@vger.kernel.org, Kevin Cernekee , Ralf Baechle , bcm-kernel-feedback-list@broadcom.com, Gregory Fong , "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" Subject: Re: [PATCH v4 4/8] PCI: brcmstb: Add dma-range mapping for inbound traffic Message-ID: <20180126075343.GB2356@lst.de> References: <1516058925-46522-1-git-send-email-jim2101024@gmail.com> <1516058925-46522-5-git-send-email-jim2101024@gmail.com> <20180118073123.GA15766@lst.de> <20180118152331.GA24461@lst.de> <20180123132033.GA21438@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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, Jan 24, 2018 at 12:04:58PM -0800, Florian Fainelli wrote: > This looks nicer than the current shape, but this still requires to > register a PCI fixup to override phys_to_dma() and dma_to_phys(), and it > would appear that you have dodged my question about how this is supposed > to fit with an entirely modular PCIe root complex driver? Are you > suggesting that we split the module into a built-in part and a modular part? I don't think entirely modular PCI root bridges should be a focal point for the design. If we happen to support them by other design choices: fine, but they should not be a priority. That being said if we have core dma mapping or PCIe code that has a list of offsets and the root complex only populates them it should work just fine.