linux-kernel - Re: [PATCH] rpmsg_ns: Work around TI non-standard message

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]

Message-ID: <901d75f1-76ad-4c32-920b-1e9b10270236@ti.com>
Date: Tue, 3 Dec 2024 09:19:31 -0600
From: Andrew Davis <afd@...com>
To: Richard Weinberger <richard@...ma-star.at>,
        Mathieu Poirier
	<mathieu.poirier@...aro.org>
CC: Richard Weinberger <richard@....at>, <upstream@...ma-star.at>,
        <linux-remoteproc@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <andersson@...nel.org>, <upstream+rproc@...ma-star.at>,
        <ohad@...ery.com>, <s-anna@...com>, <t-kristo@...com>
Subject: Re: [PATCH] rpmsg_ns: Work around TI non-standard message

On 10/15/24 1:00 PM, Richard Weinberger wrote:
> Am Dienstag, 15. Oktober 2024, 19:56:08 CEST schrieb Mathieu Poirier:
>>>> In my opinion the real fix here is to get TI to use the standard message
>>>> announcement structure.  The ->desc field doesn't seem to be that useful since
>>>> it gets discarted.
>>>
>>> This is for the future, the goal of my patch is helping people to
>>> get existing DSP programs work with mainline.
>>> Not everyone can or want to rebuild theirs DSP programs when moving to a mainline
>>> kernel.
>>
>> That's an even better argument to adopt the standard structure as soon as
>> possible.  Modifying the mainline kernel to adapt to vendors' quirks doesn't
>> scale.
> 
> Well, I can't speak for TI.
> But I have little hope.
> 

RPMSG_NS_2_0 is a compile time option, you can turn that off and rebuild
the firmware to go back to the standard message structure. Our new firmware
doesn't use that anyway (and it was only introduced to support some OpenMA
firmware that had multiple channels. It was left on by default in some old
firmware SDKs which is why NS_2.0 is in more firmware than it really needed
to have been). Is there some specific firmware you a working with that cannot
be rebuilt?

Andrew

> Thanks,
> //richard
>