On Thu, Jun 07, 2018 at 11:06:11AM -0700, Bjorn Andersson wrote: > On Thu 07 Jun 09:23 PDT 2018, Ard Biesheuvel wrote: > > > On 7 June 2018 at 18:18, Bjorn Andersson <bjorn.anders...@linaro.org> 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... > > So it's this memremap() region that we pass to > request_firmware_into_buf() currently, the previously mentioned > dma_alloc_coherent() region is used as we invoke the secure world > operation to set up the firmware authentication.
memremap() is for IO memory, and in that sense it is also not much different from DMA memory in terms of the concerns Mimi has for LSMs and what guarantees LSMs can make to users. Regardless of the device, once you write certain data to the IO memory we cannot be sure the device will wait for all IO to be written, this will be device specific. As such I would suggest READING_IOMEM for this case have request_firmware_into_buf() use it. With that said, since we have only one user of this caller, a future rename to reflect its current actual use would be good. The rename can wait though. Luis _______________________________________________ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
