Re: [PATCH 1/2] dmadevices: dma_sync_wait undefined

[Dan Williams]

On Tue, Jun 18, 2013 at 5:46 PM, Jon Mason <jon.mason@xxxxxxxxx> wrote:
> dma_sync_wait is declared regardless of whether CONFIG_DMA_ENGINE is
> enabled, but calling the function without CONFIG_DMA_ENGINE enabled
> results in the following gcc error.
> ERROR: "dma_sync_wait" [drivers/ntb/ntb.ko] undefined!
>
> To get around this, declare dma_sync_wait as an inline function if
> CONFIG_DMA_ENGINE is undefined.
>
> Signed-off-by: Jon Mason <jon.mason@xxxxxxxxx>
> Acked-by: Dave Jiang <dave.jiang@xxxxxxxxx>
> ---
>  include/linux/dmaengine.h |    6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> index 96d3e4a..e3652ac 100644
> --- a/include/linux/dmaengine.h
> +++ b/include/linux/dmaengine.h
> @@ -963,8 +963,8 @@ dma_set_tx_state(struct dma_tx_state *st, dma_cookie_t last, dma_cookie_t used,
>         }
>  }
>
> -enum dma_status dma_sync_wait(struct dma_chan *chan, dma_cookie_t cookie);
>  #ifdef CONFIG_DMA_ENGINE
> +enum dma_status dma_sync_wait(struct dma_chan *chan, dma_cookie_t cookie);
>  enum dma_status dma_wait_for_async_tx(struct dma_async_tx_descriptor *tx);
>  void dma_issue_pending_all(void);
>  struct dma_chan *__dma_request_channel(const dma_cap_mask_t *mask,
> @@ -972,6 +972,10 @@ struct dma_chan *__dma_request_channel(const dma_cap_mask_t *mask,
>  struct dma_chan *dma_request_slave_channel(struct device *dev, const char *name);
>  void dma_release_channel(struct dma_chan *chan);
>  #else
> +static inline enum dma_status dma_sync_wait(struct dma_chan *chan, dma_cookie_t cookie)
> +{
> +       return DMA_SUCCESS;
> +}

Seems like something we should fix, but why is this not an indication
that the code calling this is missing a "depends on DMA_ENGINE".

On second look dma_sync_wait is a use as last resort hack that
probably should not escape its internal use in dmaengine.c.  The other
escape in drivers/media/platform/timblogiw.c already looks problematic
by having a live cpu spin immediately following a sleeping wait,
obviously something event based was wanted.  What's the use case in
NTB?

--
Dan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/