lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Fri, 1 Jun 2012 11:04:40 +0300
From:	Ohad Ben-Cohen <ohad@...ery.com>
To:	sjur.brandeland@...ricsson.com
Cc:	Loic PALLARDY <loic.pallardy@...ricsson.com>,
	Ludovic BARRE <ludovic.barre@...ricsson.com>,
	linux-kernel@...r.kernel.org, Arnd Bergmann <arnd@...db.de>,
	Linus Walleij <linus.walleij@...aro.org>,
	Sjur Brændeland <sjurbren@...il.com>
Subject: Re: [RFC] remoteproc: Add custom STE-modem firmware loader.

Hi Sjur,

On Thu, May 31, 2012 at 5:12 PM,  <sjur.brandeland@...ricsson.com> wrote:
> OK, here is an early version of the STE-Modem firmware loader.
> Haven't done the Makefile and Kconfig updates yet though.

Thanks for posting this! I'll find the time to review this asap.

> But I have one issue, I need the firmware image to be allocated
> at the start of shared memory. But the vring gets allocated first.
> I could work around this by calling dma_mark_declared_memory_occupied(),
> from the driver and then call dma_release_from_coherent() before booting.
> But this feels like a hack. Any ideas on how to handle this properly?

One proper way to handle this is to allow platforms to provide
separate memory regions for separate purposes by binding each memory
region to a different per-purpose subdevices.

This way remoteproc could then use the right device whenever it
invokes the DMA API, and memory will then always be allocated from the
expected region, without being affected by different allocation
orders.

Ludovic was working on a patch that does exactly that, and the zynq
folks also need it, so the timing of your request looks perfect :)

Thanks,
Ohad.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ