On Sun, 30 Oct 2016 23:47:29 +0530 Sudip Mukherjee <[email protected]> wrote:
> On Friday 21 October 2016 08:59 AM, Andrew Morton wrote: > > On Sat, 8 Oct 2016 23:23:18 +0530 Sudip Mukherjee > > <[email protected]> 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?
