linux-kernel - Re: [PATCH] remoteproc: move rproc_da_to

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: <YijeDirNSJ6bpRMj@x1>
Date:   Wed, 9 Mar 2022 18:04:14 +0100
From:   Drew Fustini <dfustini@...libre.com>
To:     Bjorn Andersson <bjorn.andersson@...aro.org>
Cc:     Mathieu Poirier <mathieu.poirier@...aro.org>,
        linux-remoteproc@...r.kernel.org, linux-kernel@...r.kernel.org,
        Suman Anna <s-anna@...com>, Dave Gerlach <d-gerlach@...com>
Subject: Re: [PATCH] remoteproc: move rproc_da_to_va declaration to
 remoteproc.h

On Tue, Mar 08, 2022 at 10:16:54AM -0800, Bjorn Andersson wrote:
> On Tue 08 Mar 09:25 PST 2022, Drew Fustini wrote:
> 
> > From: Suman Anna <s-anna@...com>
> > 
> > The rproc_da_to_va() API is an exported function, so move its
> > declaration from the remoteproc local remoteproc_internal.h
> > to the public remoteproc.h file.
> > 
> > This will allow drivers outside of the remoteproc folder to be
> > able to use this API.
> > 
> 
> Can you explain why drivers outside of the remoteproc folder should be
> able to poke straight into the memory of the remoteproc?
> 
> Your reasoning makes sense, but we've on purpose kept it out of
> remoteproc.h because no one has had a proper reason for it and I sense
> that we might open the door for some new creative solutions...

rproc_da_to_va() is used in a patch for drivers/soc/ti/wkup_m3_ipc.c
that adds support for i2c voltage scaling [1].

wkup_m3_copy_aux_data() will copy auxiliary data to special region of
the Cortex M3 memory. It calls rproc_da_to_va() to get aux_data_addr
which is then used as a memcpy destination.

Does that seem like a reasonable way to do it?

I was going to submit the i2c voltage scaling patches later. However,
I could combine them into a series with this remoteproc patch if that
helps to justify the remoteproc.h change.

Thanks,
Drew

[1] https://lore.kernel.org/linux-omap/20220219215328.485660-9-dfustini@baylibre.com/