On 06/07/2018 06:33 PM, Greg Kroah-Hartman wrote: > On Thu, Jun 07, 2018 at 06:23:01PM +0200, Ard Biesheuvel wrote: >> On 7 June 2018 at 18:18, Bjorn Andersson <bjorn.andersson@xxxxxxxxxx> 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. DMAble in what sense? For devices that can't handle physical addresses above 16M you need to pass __GFP_DMA to get those, from ZONE_DMA. Otherwise it can return anything from lowmem. That's for x86_64, some other arches have different DMA zone. > Is the problem that vmalloc() might not? vmalloc() could only be used as an alternative if you used kvmalloc(), otherwise kmalloc() won't give you anything from vmalloc > We need to drop the whole DMA zone crud, it confuses everyone who sees > it and was primarily for really really old systems. Yeah that would be nice. > greg k-h >
