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:   Mon, 9 Jan 2017 19:48:11 +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 Thu, Jan 05, 2017 at 09:26:17PM -0600, David Lechner wrote:

> This allows SPI devices specified in a device tree to use DMA when the
> master controller.

> Since device tree is supposed to only describe the hardware, adding such
> a configuration option to device tree would not be acceptable. So, this
> is the best we can do for now to get SPI devices working with DMA.

> 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?

> 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).

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