From: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org, fengguang.wu@intel.com
Subject: Re: [PATCH] m32r: add simple dma
Date: Tue, 08 Nov 2016 20:07:38 +0000 [thread overview]
Message-ID: <5822308A.5040507@gmail.com> (raw)
In-Reply-To: <20161103121318.895edcc2e09eebd5316d4064@linux-foundation.org>
On Thursday 03 November 2016 07:13 PM, Andrew Morton wrote:
> On Sun, 30 Oct 2016 23:47:29 +0530 Sudip Mukherjee <sudipm.mukherjee@gmail.com> 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@gmail.com> 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
prev parent reply other threads:[~2016-11-08 20:07 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-08 17:53 [PATCH] m32r: add simple dma Sudip Mukherjee
2016-10-21 3:29 ` Andrew Morton
2016-10-30 18:17 ` Sudip Mukherjee
2016-11-03 19:13 ` Andrew Morton
2016-11-08 20:07 ` Sudip Mukherjee [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5822308A.5040507@gmail.com \
--to=sudipm.mukherjee@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=fengguang.wu@intel.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.