Re: [PATCH] m32r: add simple dma

From: Sudip Mukherjee
Date: Tue Nov 08 2016 - 15:07:57 EST


On Thursday 03 November 2016 07:13 PM, Andrew Morton wrote:
On Sun, 30 Oct 2016 23:47:29 +0530 Sudip Mukherjee <sudipm.mukherjee@xxxxxxxxx> wrote:

On Friday 21 October 2016 08:59 AM, Andrew Morton wrote:
On Sat, 8 Oct 2016 23:23:18 +0530 Sudip Mukherjee <sudipm.mukherjee@xxxxxxxxx> wrote:

Some builds of m32r were failing as it tried to build few drivers which
needed dma but m32r is not having dma support. Objections were raised
when it was tried to make those drivers depend on HAS_DMA.

Huh. What were these objections? That sounds like the appropriate
fix. And I suggest that a summary of those objections be captured in
this patch's changelog.

Sorry for the delay in reply. Got busy in dayjob and relocation.

I was asked to provide dma stubs instead of adding HAS_DMA in the Kconfig.

http://www.spinics.net/lists/kernel/msg2277152.html

And an old thread-
http://www.spinics.net/lists/alsa-devel/msg50931.html

It appeared to me that instead of adding dma stubs and returning error
values from them it will be better to add dma_noop to m32r. Looking at
the simplicity of dma_noop it seems that it should work.
What will you suggest? Do i send v2 after adding the "dma stub" comment
and the link to the thread in the commit message or should I opt for dma
stub?

Disabling DMA in Kconfig is the most cautious approach. If someone
cares then they will be able to runtime test the thing, so those people
can implement dma_noop (or something else).

On the other hand, we could just go ahead and wire up dma_noop and if
someone later has problems with it, they will report or fix those
problems.

So, umm, I guess that wiring up dma_noop gets us further forward than
simply disabling everything, so how about we do that?


Again sorry for the delayed reply. But I am all set now. Relocating from one country to another is a tough one.
Do I send you v2 of the patch with the links in the commit message?

Regards
Sudip