From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756303AbeASTsR (ORCPT ); Fri, 19 Jan 2018 14:48:17 -0500 Received: from mail-wr0-f195.google.com ([209.85.128.195]:40575 "EHLO mail-wr0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756214AbeASTsH (ORCPT ); Fri, 19 Jan 2018 14:48:07 -0500 X-Google-Smtp-Source: ACJfBouINVWasR0rCxygJ/4x4vpIDKqLHdA+gbrp4E/8KALFCzHQYQJJG4VWGc6u953PmEAuedQzQw== Subject: Re: [PATCH v4 4/8] PCI: brcmstb: Add dma-range mapping for inbound traffic To: Christoph Hellwig , Florian Fainelli Cc: 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" 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> From: Florian Fainelli Message-ID: Date: Fri, 19 Jan 2018 11:47:54 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20180118152331.GA24461@lst.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/18/2018 07:23 AM, Christoph Hellwig wrote: > On Thu, Jan 18, 2018 at 07:09:23AM -0800, Florian Fainelli wrote: >>> 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? > > Override phys_to_dma and dma_to_phys as mips and x86 do for similar > situations. How can this work well in the context of a loadable module for instance? For MIPS, this would mean that we have to override phys_to_dma() and dma_to_phys() in the platform that is *susceptible* to use this PCIe controller (arch/mips/bmips) which is fine, but there, we essentially need to find a way to make this dynamic based on whether the PCIe controller is loaded or not. As you might have seen from this patch, what needs to be done is highly dependent on the processor architecture and its memory controller physical memory map, so I don't see how we are in any better situation if we need to replicate 3 times across MIPS, ARM and ARM64 how the addresses need to be mangled. Are you suggesting we somehow decouple the memory mangling part into a portion that can be built into the kernel image (so phys_to_dma() and dma_to_phys() is resolved at vmlinux link time) and can be selected by different architectures that need it? If so, yikes. > > Bonous points of finding some generic way of doing it instead of > hiding it in arch code. > I can see value in having a generic mechanism, ala X86_DMA_REMAP allowing architectures to have the ability to override phys_to_dma() and dma_to_phys() but right now, especially if we look at arch/x86/pci/sta2x11-fixup.c this really appears to be quite messy and equally ugly than stacking operations... What is the actual problem you want to avoid with the stacking of DMA operations, is it because it becomes harder to audit, or are there are other reasons? -- Florian From mboxrd@z Thu Jan 1 00:00:00 1970 From: Florian Fainelli Subject: Re: [PATCH v4 4/8] PCI: brcmstb: Add dma-range mapping for inbound traffic Date: Fri, 19 Jan 2018 11:47:54 -0800 Message-ID: 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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20180118152331.GA24461@lst.de> Content-Language: en-US Sender: linux-pci-owner@vger.kernel.org To: Christoph Hellwig , Florian Fainelli Cc: 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 List-Id: devicetree@vger.kernel.org On 01/18/2018 07:23 AM, Christoph Hellwig wrote: > On Thu, Jan 18, 2018 at 07:09:23AM -0800, Florian Fainelli wrote: >>> 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? > > Override phys_to_dma and dma_to_phys as mips and x86 do for similar > situations. How can this work well in the context of a loadable module for instance? For MIPS, this would mean that we have to override phys_to_dma() and dma_to_phys() in the platform that is *susceptible* to use this PCIe controller (arch/mips/bmips) which is fine, but there, we essentially need to find a way to make this dynamic based on whether the PCIe controller is loaded or not. As you might have seen from this patch, what needs to be done is highly dependent on the processor architecture and its memory controller physical memory map, so I don't see how we are in any better situation if we need to replicate 3 times across MIPS, ARM and ARM64 how the addresses need to be mangled. Are you suggesting we somehow decouple the memory mangling part into a portion that can be built into the kernel image (so phys_to_dma() and dma_to_phys() is resolved at vmlinux link time) and can be selected by different architectures that need it? If so, yikes. > > Bonous points of finding some generic way of doing it instead of > hiding it in arch code. > I can see value in having a generic mechanism, ala X86_DMA_REMAP allowing architectures to have the ability to override phys_to_dma() and dma_to_phys() but right now, especially if we look at arch/x86/pci/sta2x11-fixup.c this really appears to be quite messy and equally ugly than stacking operations... What is the actual problem you want to avoid with the stacking of DMA operations, is it because it becomes harder to audit, or are there are other reasons? -- Florian From mboxrd@z Thu Jan 1 00:00:00 1970 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 19 Jan 2018 20:48:18 +0100 (CET) Received: from mail-wr0-x243.google.com ([IPv6:2a00:1450:400c:c0c::243]:44932 "EHLO mail-wr0-x243.google.com" rhost-flags-OK-OK-OK-OK) by eddie.linux-mips.org with ESMTP id S23992079AbeASTsL4GUW7 (ORCPT ); Fri, 19 Jan 2018 20:48:11 +0100 Received: by mail-wr0-x243.google.com with SMTP id w50so2541103wrc.11 for ; Fri, 19 Jan 2018 11:48:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=J9VOwdLJXDn6CV0b/YRUP485OMQx0P+DPCv3soxh36Q=; b=TplHvHH173ezZL+TbOLNSdkos1TDtBVVP+Ve3XnqjkZ+kvbieQbjTEGqSkYOKn+ZPh FSWEGjm8uOpyEEQFuuSNL6miwx9PkziFvUj690N82rC6D69aKJnKh4S5+yuUorSjNFU4 Go6+GVO/aSyDItWjunv6LYYZKORZqbDESbzoI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=J9VOwdLJXDn6CV0b/YRUP485OMQx0P+DPCv3soxh36Q=; b=Qj8Zv4h1sdJjLjjrav96uiFXWTQT5qfZGtJi+aMC+1OHetCuFhIXRlQFCVzidqfjhp gXNd2PFiLC6Yrma6xPRdhAFLVLxGV/dny0pwmsADr0rIYYVG9ndcS9n+VOknjncqwJ2P 0B1BLysidNSOZs19dh935qVM0wdPIULK79K06E6MsVe+Jh9wOV6uvWwbdWBTvukcwviD m/4tnBb1jdvbqWb2MMJfRr+TS6eN3D0rElAj7rGabVuwBFeTkHXPUtOA1jI9RH6x3Qae D1WUfhkJlw681gIO279brxR1zRgLm8xJKuzatnyl21i4wxDjdpyIYCeliJiwv0/9SaZ4 6Tbg== X-Gm-Message-State: AKwxyteEhJBkzfxk+NJg/RV8/pA31wVHBVt0MwJYlhKvR3Tm87DEeYfe qOLosboDomY2Ke/CBCWKmV7/MQ== X-Google-Smtp-Source: ACJfBouINVWasR0rCxygJ/4x4vpIDKqLHdA+gbrp4E/8KALFCzHQYQJJG4VWGc6u953PmEAuedQzQw== X-Received: by 10.223.187.13 with SMTP id r13mr8332864wrg.62.1516391285524; Fri, 19 Jan 2018 11:48:05 -0800 (PST) Received: from [10.69.41.93] ([192.19.223.250]) by smtp.gmail.com with ESMTPSA id a73sm17685885wrc.53.2018.01.19.11.47.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Jan 2018 11:48:04 -0800 (PST) Subject: Re: [PATCH v4 4/8] PCI: brcmstb: Add dma-range mapping for inbound traffic To: Christoph Hellwig , Florian Fainelli Cc: 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" 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> From: Florian Fainelli Message-ID: Date: Fri, 19 Jan 2018 11:47:54 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20180118152331.GA24461@lst.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 62254 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: florian.fainelli@broadcom.com Precedence: bulk List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: linux-mips X-List-ID: linux-mips List-subscribe: List-owner: List-post: List-archive: X-list: linux-mips On 01/18/2018 07:23 AM, Christoph Hellwig wrote: > On Thu, Jan 18, 2018 at 07:09:23AM -0800, Florian Fainelli wrote: >>> 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? > > Override phys_to_dma and dma_to_phys as mips and x86 do for similar > situations. How can this work well in the context of a loadable module for instance? For MIPS, this would mean that we have to override phys_to_dma() and dma_to_phys() in the platform that is *susceptible* to use this PCIe controller (arch/mips/bmips) which is fine, but there, we essentially need to find a way to make this dynamic based on whether the PCIe controller is loaded or not. As you might have seen from this patch, what needs to be done is highly dependent on the processor architecture and its memory controller physical memory map, so I don't see how we are in any better situation if we need to replicate 3 times across MIPS, ARM and ARM64 how the addresses need to be mangled. Are you suggesting we somehow decouple the memory mangling part into a portion that can be built into the kernel image (so phys_to_dma() and dma_to_phys() is resolved at vmlinux link time) and can be selected by different architectures that need it? If so, yikes. > > Bonous points of finding some generic way of doing it instead of > hiding it in arch code. > I can see value in having a generic mechanism, ala X86_DMA_REMAP allowing architectures to have the ability to override phys_to_dma() and dma_to_phys() but right now, especially if we look at arch/x86/pci/sta2x11-fixup.c this really appears to be quite messy and equally ugly than stacking operations... What is the actual problem you want to avoid with the stacking of DMA operations, is it because it becomes harder to audit, or are there are other reasons? -- Florian From mboxrd@z Thu Jan 1 00:00:00 1970 From: florian.fainelli@broadcom.com (Florian Fainelli) Date: Fri, 19 Jan 2018 11:47:54 -0800 Subject: [PATCH v4 4/8] PCI: brcmstb: Add dma-range mapping for inbound traffic In-Reply-To: <20180118152331.GA24461@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> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 01/18/2018 07:23 AM, Christoph Hellwig wrote: > On Thu, Jan 18, 2018 at 07:09:23AM -0800, Florian Fainelli wrote: >>> 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? > > Override phys_to_dma and dma_to_phys as mips and x86 do for similar > situations. How can this work well in the context of a loadable module for instance? For MIPS, this would mean that we have to override phys_to_dma() and dma_to_phys() in the platform that is *susceptible* to use this PCIe controller (arch/mips/bmips) which is fine, but there, we essentially need to find a way to make this dynamic based on whether the PCIe controller is loaded or not. As you might have seen from this patch, what needs to be done is highly dependent on the processor architecture and its memory controller physical memory map, so I don't see how we are in any better situation if we need to replicate 3 times across MIPS, ARM and ARM64 how the addresses need to be mangled. Are you suggesting we somehow decouple the memory mangling part into a portion that can be built into the kernel image (so phys_to_dma() and dma_to_phys() is resolved at vmlinux link time) and can be selected by different architectures that need it? If so, yikes. > > Bonous points of finding some generic way of doing it instead of > hiding it in arch code. > I can see value in having a generic mechanism, ala X86_DMA_REMAP allowing architectures to have the ability to override phys_to_dma() and dma_to_phys() but right now, especially if we look at arch/x86/pci/sta2x11-fixup.c this really appears to be quite messy and equally ugly than stacking operations... What is the actual problem you want to avoid with the stacking of DMA operations, is it because it becomes harder to audit, or are there are other reasons? -- Florian