On Thu, Jun 07, 2018 at 06:43:05PM +0200, Ard Biesheuvel wrote: > On 7 June 2018 at 18:33, Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> 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. > > > > 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. kmalloc should always return a DMAble buffer. If that is not true, we have a _LOT_ of broken drivers. What systems is this not true on, and how are you running USB on them? :) thanks, greg k-h _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
