On Thu, Jul 6, 2017 at 11:17 PM, Tomasz Figa <tf...@chromium.org> wrote: > On Thu, Jul 6, 2017 at 11:10 PM, Christoph Hellwig <h...@lst.de> 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().
