From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758639AbcKCTNV (ORCPT ); Thu, 3 Nov 2016 15:13:21 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:52120 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757964AbcKCTNU (ORCPT ); Thu, 3 Nov 2016 15:13:20 -0400 Date: Thu, 3 Nov 2016 12:13:18 -0700 From: Andrew Morton To: Sudip Mukherjee Cc: linux-kernel@vger.kernel.org, fengguang.wu@intel.com Subject: Re: [PATCH] m32r: add simple dma Message-Id: <20161103121318.895edcc2e09eebd5316d4064@linux-foundation.org> In-Reply-To: <58163939.40404@gmail.com> References: <1475949198-31623-1-git-send-email-sudipm.mukherjee@gmail.com> <20161020202918.b7cb3fe24058addddabb7534@linux-foundation.org> <58163939.40404@gmail.com> X-Mailer: Sylpheed 3.4.1 (GTK+ 2.24.23; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 30 Oct 2016 23:47:29 +0530 Sudip Mukherjee wrote: > On Friday 21 October 2016 08:59 AM, Andrew Morton wrote: > > On Sat, 8 Oct 2016 23:23:18 +0530 Sudip Mukherjee 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?