[lkml]   [2018]   [Feb]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH/RFC 0/6] Allow compile-testing NO_DMA
On Tue, Feb 6, 2018 at 11:14 AM, Geert Uytterhoeven
<> wrote:
> Hi all,
> If NO_DMA=y, get_dma_ops() returns a reference to the non-existing
> symbol bad_dma_ops, thus causing a link failure if it is ever used.
> The intention of this is twofold:
> 1. To catch users of the DMA API on systems that do no support the DMA
> mapping API,
> 2. To avoid building drivers that cannot work on such systems anyway.
> However, the disadvantage is that we have to keep on adding dependencies
> on HAS_DMA all over the place.
> Thanks to the COMPILE_TEST symbol, lots of drivers now depend on one or
> more platform dependencies (that imply HAS_DMA) || COMPILE_TEST, thus
> already covering intention #2. Having to add an explicit dependency on
> HAS_DMA here is cumbersome, and hinders compile-testing.
> Hence I think the time is ripe to reconsider the link failure.
> This patch series:
> - Changes get_dma_ops() to return NULL instead,
> - Adds a few more dummies to enable compile-testing,
> - Removes dependencies on HAS_DMA for symbols that already have
> platform dependencies implying HAS_DMA.
> Note that adding more platform dependencies and/or dependencies on
> COMPILE_TEST is encouraged!
> This may make life harder for UML, though, as UML usually satisfies all
> other platform dependencies for HAS_DMA. Similarly, HAS_IOMEM is even
> more complicated. Can/do we want to do something similar for
> This series is against my current local tree, which has a few more
> "depends on HAS_DMA" than upstream. Of course I will rebase, and split
> the last patch per subsystem, if this RFC is welcomed positively.
> Compile-tested with allmodconfig and allyesconfig for m68k/sun3.

David Woodhouse has been looking at some other structures with indirect
pointers (kvm_x86_ops) to reduce the overhead that was added for
avoiding speculative execution of those pointers. I wonder if there are
any dma_map_ops operations that are in a fastpath that needs a similar
optimization. If yes, we might want to think about how to do that part
first to avoid rewriting the same code more than once.

Otherwise, your approach seems fine.


 \ /
  Last update: 2018-02-06 16:17    [W:0.096 / U:4.448 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site