Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752057AbdGFOYw (ORCPT ); Thu, 6 Jul 2017 10:24:52 -0400 Received: from mail-yw0-f182.google.com ([209.85.161.182]:36749 "EHLO mail-yw0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751744AbdGFOYv (ORCPT ); Thu, 6 Jul 2017 10:24:51 -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:24:28 +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: Christoph Hellwig Cc: 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 , Arnd Bergmann 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: 1723 Lines: 31 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().