linux-kernel - Re: [RESEND] spi: davinci: Allow device tree devices to use 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] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 10 Jan 2017 16:51:46 +0000
From:   Mark Brown <broonie@...nel.org>
To:     David Lechner <david@...hnology.com>
Cc:     nsekhar@...com, khilman@...nel.org, linux-spi@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [RESEND] spi: davinci: Allow device tree devices to use DMA

On Mon, Jan 09, 2017 at 02:40:50PM -0600, David Lechner wrote:
> On 01/09/2017 01:48 PM, Mark Brown wrote:
> > On Thu, Jan 05, 2017 at 09:26:17PM -0600, David Lechner wrote:

> > > Unfortunately, this excludes the possibility of using one SPI device with
> > > DMA and one without on the same master.

> > Why would you ever want to do that?  What would ever make sense about
> > not using DMA if it's available and the transfer is suitably large, or
> > conversely why would one want to force DMA even if PIO would be more
> > performant?

> I don't particularly want to do that, but that is the way the spi-davinci
> driver currently works. The choice between DMA or PIO is specified in the
> platform data on a per-device basis.

> What I get from your remarks is that this is wrong and it needs to be fixed.
> If that is so, could someone please point out a driver that does it the
> right way and I will try to fix it.

Pretty much any driver doing DMA...  off the top of my head the i.MX and
Samsung drivers ought to be reasonable examples.  If you've got time to
look at fixing the driver the other thing that jumps out with it is the
use of a threaded interrupt handler with no actual handling in the
thread, that looks like some magic timing based hack which seems risky
(or completely unneeded which would be better).

> > > When I originally submitted this patch, there was some discussion as to whether
> > > dspi->dma_rx should be changed to return an error rather than being null.
> > 
> > > However, I prefer it the way it is and don't see a compelling reason to change
> > > it.

> > I don't know what the above comment means, sorry (and don't recall
> > having seen any earlier versions of this).

> FWIW, you can find the previous conversation at
> https://patchwork.kernel.org/patch/9437901/

What Sekhar is saying there is right, it is better style to use an error
pointer rather than NULL as someone could potentially come up with a way
to make NULL a valid pointer in the API.  But it doesn't matter greatly.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)