linux-kernel - Re: [PATCH] m32r: add simple dma

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <5822308A.5040507@gmail.com>
Date:   Tue, 08 Nov 2016 20:07:38 +0000
From:   Sudip Mukherjee <sudipm.mukherjee@...il.com>
To:     Andrew Morton <akpm@...ux-foundation.org>
CC:     linux-kernel@...r.kernel.org, fengguang.wu@...el.com
Subject: Re: [PATCH] m32r: add simple dma

On Thursday 03 November 2016 07:13 PM, Andrew Morton wrote:
> On Sun, 30 Oct 2016 23:47:29 +0530 Sudip Mukherjee <sudipm.mukherjee@...il.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@...il.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