Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751980AbdGFOlx (ORCPT ); Thu, 6 Jul 2017 10:41:53 -0400 Received: from mail-yb0-f180.google.com ([209.85.213.180]:35272 "EHLO mail-yb0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751797AbdGFOlw (ORCPT ); Thu, 6 Jul 2017 10:41:52 -0400 MIME-Version: 1.0 In-Reply-To: References: <20170705071215.17603-1-tfiga@chromium.org> <20170705071215.17603-5-tfiga@chromium.org> <20170706141045.GA577@lst.de> From: Tomasz Figa Date: Thu, 6 Jul 2017 23:41:29 +0900 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH 4/5] iommu/dma: Export non-static functions to use in modules To: Arnd Bergmann Cc: Christoph Hellwig , Robin Murphy , "open list:IOMMU DRIVERS" , "linux-kernel@vger.kernel.org" , Marek Szyprowski , Greg Kroah-Hartman , Joerg Roedel , Will Deacon , Vineet Gupta , Hans-Christian Noren Egtvedt , Mitchel Humpherys , Krzysztof Kozlowski Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2696 Lines: 51 On Thu, Jul 6, 2017 at 11:35 PM, Arnd Bergmann wrote: > On Thu, Jul 6, 2017 at 4:24 PM, Tomasz Figa wrote: >> On Thu, Jul 6, 2017 at 11:17 PM, Tomasz Figa wrote: >>> On Thu, Jul 6, 2017 at 11:10 PM, Christoph Hellwig wrote: >>>> On Thu, Jul 06, 2017 at 12:09:45PM +0100, Robin Murphy wrote: >>>>> I suppose another option is to just make the IOMMU and DMA ops a >>>>> self-contained non-modular driver mirroring the VT-d/AMD-Vi IOMMUs - >>>>> AFAICS it shouldn't have to be all that tightly coupled to the IPU bus >>>>> code, the latter more or less just needs to create the appropriate IOMMU >>>>> device for the driver to find. >>>> >>>> I still haven't seen the driver code, but this seems to be best >>>> solution so far. Given that it's not a plug in device but part of >>>> an SOC that seems perfectly acceptable to me. >>> >>> I guess that's something that could work. With its caveats of not >>> being able to avoid including the very platform specific code in a >>> generic kernel image or do any quick testing of code changes without a >>> restart, but I guess that's something one could quickly hack in their >>> own downstream (i.e. export the symbols and turn the Kconfig entry >>> into tristate). >>> >>> On the other hand, I'm yet to see any real reasons why not to export >>> those symbols. Personally I don't see anything that one wouldn't be >>> able to do in their downstream without the symbols exported in >>> mainline (one can add the exports any time or if the kernel source >>> can't be modified can just load a wrapper module that exports its own >>> symbols...) >> >> Sorry, I just realized that last sentence might sound nonsense. By >> wrapper I meant reimplementing the missing functions using some >> already exported functions I mentioned in my post to another patch >> from this series, such as __get_vm_area() and map_vm_area(). > > We should look at the two aspects separately: one is how to drive > the IOMMU as part of a loadable driver, the other is how to handle > DMA to uncached memory on x86. You are in an unfortunate > position of needing both, but aside from that they seem unrelated. So generally I'm not in such a desperate need to have this code as a loadable module. I can just hack around it in my own working tree if I need it. However I'm trying to understand, why this is such a bad idea, if I already have it working. Uncached DMA memory on x86 is actually more complicated. We could still work around this by not relying on the memory being uncached (with caveats obviously). But here too I'd like to understand why having my own DMA ops is bad. Best regards, Tomasz