From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932425AbeARPMR (ORCPT ); Thu, 18 Jan 2018 10:12:17 -0500 Received: from mail-oi0-f67.google.com ([209.85.218.67]:43704 "EHLO mail-oi0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932716AbeARPJ3 (ORCPT ); Thu, 18 Jan 2018 10:09:29 -0500 X-Google-Smtp-Source: ACJfBotiISvTtlZciKFHR57d8W3hbFTWOA/P6K+QFktlwQBa3lzkbqq/rw1zeTqtCNnifhmGv+UCYQ== Date: Thu, 18 Jan 2018 07:09:23 -0800 User-Agent: K-9 Mail for Android In-Reply-To: <20180118073123.GA15766@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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Subject: Re: [PATCH v4 4/8] PCI: brcmstb: Add dma-range mapping for inbound traffic To: Christoph Hellwig , Rob Herring CC: 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" From: Florian Fainelli Message-ID: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id w0IFCSXI007714 On January 17, 2018 11:31:23 PM PST, Christoph Hellwig wrote: >On Wed, Jan 17, 2018 at 08:15:33PM -0600, Rob Herring wrote: >> > (a) overriding/redefining the dma_to_phys() and phys_to_dma() calls >> > that are used by the dma_ops routines. This is the approach of >> > >> > arch/mips/cavium-octeon/dma-octeon.c >> >> MIPS is rarely an example to follow. :) > >But in this case it actually is the example to follow as told >previously. > >NAK again for these chained dma ops that only create problems. Care to explain what should be done instead? -- Florian