Re: Do Qualcomm drivers use DMA buffers for request_firmware_into_buf()?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

> 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
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel



[Index of Archives]     [Linux Driver Backports]     [DMA Engine]     [Linux GPIO]     [Linux SPI]     [Video for Linux]     [Linux USB Devel]     [Linux Coverity]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux