On 7 June 2018 at 18:33, Greg Kroah-Hartman <gre...@linuxfoundation.org> wrote: > On Thu, Jun 07, 2018 at 06:23:01PM +0200, Ard Biesheuvel wrote: >> On 7 June 2018 at 18:18, Bjorn Andersson <bjorn.anders...@linaro.org> wrote: >> > On Wed 06 Jun 13:32 PDT 2018, Luis R. Rodriguez wrote: >> > >> >> On Fri, Jun 01, 2018 at 09:23:46PM +0200, Luis R. Rodriguez wrote: >> >> > On Tue, May 08, 2018 at 03:38:05PM +0000, Luis R. Rodriguez wrote: >> >> > > On Fri, May 04, 2018 at 12:44:37PM -0700, Martijn Coenen wrote: >> >> > > > >> >> > > > I think the Qualcomm folks owning this (Andy, David, Bjorn, already >> >> > > > cc'd here) are better suited to answer that question. >> >> > > >> >> > > Andy, David, Bjorn? >> >> > >> >> > Andy, David, Bjorn? >> >> >> >> A month now with no answer... >> >> >> > >> > The patch at the top of this thread doesn't interest me and you didn't >> > bother sending your question To me. >> > >> > As a matter of fact I'm confused to what the actual question is. >> > >> >> The actual question is whether it is really required that the firmware >> is loaded by the kernel into a buffer that is already mapped for DMA >> at that point, and thus accessible by the device. >> >> To me, it is not entirely clear what the nature is of the firmware >> that we are talking about, since it seems to be getting passed to the >> secure world as well? >> >> In any case, the preferred model in terms of validation/sig checking is >> >> 1) allocate a CPU accessible buffer >> >> 2) request the firmware into it (which may include a sig check under the >> hood) >> >> 3) map the buffer for DMA to the device so it can load the firmware. >> >> 4) kick off the DMA transfer. >> >> The use of dma_alloc_coherent() for this purpose seems unnecessary, >> given that the DMA transfer is not bidirectional. Would it be possible >> to replace it with something like the above sequence? > > Why not just use kmalloc, it will always return a DMAable buffer. >
On a PC maybe. But there are plenty of systems where bidirectional DMA mappings require uncached memory (i.e., if the device doesn't snoop the caches), in which case a kmalloc'ed buffer is useless. dma_alloc_coherent() hides the platform constraints from the driver, so it is a very useful abstraction for this use case. > Is the problem that vmalloc() might not? > > We need to drop the whole DMA zone crud, it confuses everyone who sees > it and was primarily for really really old systems. > _______________________________________________ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
