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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Sun, 1 Apr 2012 09:15:55 +0300
From:	Ohad Ben-Cohen <ohad@...ery.com>
To:	Sjur Brændeland <sjurbren@...il.com>
Cc:	Arnd Bergmann <arnd@...db.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Linus Walleij <linus.walleij@...aro.org>
Subject: Re: Using remoteproc with ST-Ericsson modem.

Hi Sjur,

On Sun, Apr 1, 2012 at 12:25 AM, Sjur Brændeland <sjurbren@...il.com> wrote:
> Good stuff. One question from top of my mind: Have you considered
> option of using rpmsg without the protocol, eg something like
> RPMSG_RAW, where I can take advantage of rpmsg transport features
> without needing the muxing feature. Then I could use CAIF muxing layer
> without the rpmsg protocol and naming services....?

I think you may already be able to do so: the naming services are only
enabled when VIRTIO_RPMSG_F_NS is present. About the rest of the rpmsg
protocol - I think you can largely ignore it. Rpmsg drivers shouldn't
really care about it, they just need to use the send/receive API and
everything would just work.

> Another option is using virtio_console, but I realise virtio_console is doing
> normal kmalloc so memory handling in virtio_console would have to change
> then. (I have a memory addressing issue, so modem cannot access all
> kernel memory).

What's the limitation you have? only a certain range of addresses is
visible to the modem?

OMAP4 has a related problem: the memory that virtio_console allocates
isn't immediately visible to the OMAP4's remote processors, because it
isn't mapped in the relevant IOMMU. To fix this, we may need
virtio_console to start allocating its memory with the DMA API (but
we'll only start discussing it when the IOMMU-based DMA API will be
merged). I guess that something along these lines would work out for
you too ?

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