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:49, Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> 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?  :)
>

Non-cache coherent EHCI and XHCI work absolutely fine in Linux. The
driver stack is perfectly well behaved, in the sense that it uses
dma_alloc_coherent() for the data structures that are shared between
the CPUs and the host controller.

For the actual data that gets passed over USB, streaming DMA is used
rather than coherent aka consistent aka bidirectional DMA, and that
works fine with kmalloc'ed buffers, since you can use bounce buffering
if the memory is not accessible to the device directly.

That also means that you may prefer to allocate from a special DMA
zone to prevent his, i.e., to ensure that the memory passed into the
streaming DMA api does not require bounce buffering in the first
place.
_______________________________________________
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