Do Qualcomm drivers use DMA buffers for request_firmware_into_buf()?

[Ard Biesheuvel]

On 6 June 2018 at 22:32, Luis R. Rodriguez <mcgrof at kernel.org> 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...
>
> Perhaps someone who has this hardware can find out empirically for us, as
> follows (mm folks is this right?):
>
> page = virt_to_page(address);
> if (!page)
>    fail closed...
> if (page_zone(page) == ZONE_DMA || page_zone(page) == ZONE_DMA32)
>         this is a DMA buffer
> else
>         not DMA!
>

As I replied in the other thread, this code makes no sense.

In general, any address covered by the kernel direct mapping can be
passed to the streaming DMA api and be mapped for device read xor
device write. Only DMA mappings that will be accessed randomly by the
device and the CPU at the same time require the use of
dma_alloc_coherent(), so it can take special precautions (e.g, create
an uncached mapping if DMA is non cache coherent)

The DMA zone thing is primarily about reserving low memory ranges for
DMA because some hardware may not have sufficient address lines wired
up to access all of DRAM.

> Note that when request_firmware_into_buf() was being reviewed Mimi had asked back
> in 2016 [0] that if a DMA buffer was going to be used READING_FIRMWARE_DMA should be
> used otherwise READING_FIRMWARE_PREALLOC_BUFFER was fine.
>
> If it is a DMA buffer *now*, why / how did this change?
>
> [0] https://patchwork.kernel.org/patch/9074611/
>
>   Luis