linux-kernel - Re: Using remoteproc with ST-Ericsson modem.

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] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 27 Mar 2012 15:56:59 +0200
From:	Ohad Ben-Cohen <ohad@...ery.com>
To:	Sjur BRENDELAND <sjur.brandeland@...ricsson.com>
Cc:	Arnd Bergmann <arnd@...db.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Linus Walleij <linus.walleij@...aro.org>,
	"sjurbren@...il.com" <sjurbren@...il.com>,
	Loic PALLARDY <loic.pallardy@...ricsson.com>,
	Ludovic BARRE <ludovic.barre@...ricsson.com>
Subject: Re: Using remoteproc with ST-Ericsson modem.

Hi Sjur,

On Tue, Mar 27, 2012 at 3:15 PM, Sjur BRENDELAND
<sjur.brandeland@...ricsson.com> wrote:
> However, we have a couple of requirements that are different.
> - We don't use a ELF binary for resource definition. We have resource
>  definitions in a binary format outside the binary. (I'm afraid I'm
>  not able to change this).

That's ok:

We coupled the resource table with the firmware binary in order to
reflect the strong ties it has with the firmware's software and to
prevent issues of loading the wrong table with a given firmware, but
supporting an external resource table will help others as well so it's
definitely in the plans (feel free to take a stab at it if you want).

> In order to use remoteproc, I think it could be a good idea to make the
> firmware, resource and possible Virtio handling pluggable. E.g:
>
> static struct rproc_ops rproc_ops = {
>      ...
>       .fw_sanity_check = fw_sanity_check,
>       .fw_resource_handler = fw_resource_handler,
>       .fw_load = fw_load,
>       .fw_config_virtio = fw_config_virtio,
> };

Can you please elaborate why would you want that ? Let's go
requirement by requirement.

I strongly prefer to extend the generic code to support additional
requirements rather than to allow platform-specific implementations to
override it (the motivation is to prevent code duplication).

> I think we need to be able to launch other Virtio device types than
> VIRTIO_ID_RPMSG as well.

Sure. Please note that we already support that today: a firmware can
indicate any type of (and number of) virito devices it supports, and
remoteproc will create those device as needed.

> Most likely, I need to make a CAIF specific
> VIRTIO type

Have you considered making this an rpmsg driver ? it might make your
implementation simpler.

> due to the fact that I need RX direction to be reversed
> (modem must be able to post it's payload buffer to Virtio ring).

It sounds like something that Loic and Ludovic (cc'ed) have been
dealing with recently too. To solve it, they have created a symmetric
variation of vrings - you might want to take a look at their
implementation.

> We also define stream channels. As mentioned, I'm considering the possibility
> of reusing Virtio console.

Sounds nice. We tried virtio console with a remote processor and it
worked quite nicely (there're still a few details that need some work
in that front, mainly if your rproc is behind an IOMMU, but otherwise
it should be quite smooth).

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/