linux-kernel - Re: [PATCH] remoteproc: imx_rproc: use imx specific hook for find_loaded_rsc

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:   Thu, 18 Nov 2021 11:29:05 -0700
From:   Mathieu Poirier <mathieu.poirier@...aro.org>
To:     "Peng Fan (OSS)" <peng.fan@....nxp.com>
Cc:     ohad@...ery.com, bjorn.andersson@...aro.org,
        o.rempel@...gutronix.de, shawnguo@...nel.org,
        s.hauer@...gutronix.de, kernel@...gutronix.de, festevam@...il.com,
        linux-imx@....com, linux-remoteproc@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        Peng Fan <peng.fan@....com>
Subject: Re: [PATCH] remoteproc: imx_rproc: use imx specific hook for
 find_loaded_rsc_table

Hi Peng,

On Fri, Nov 12, 2021 at 02:34:16PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan <peng.fan@....com>
> 
> When loading elf and kicking M core from Linux, previously we directly
> use the address of the resource table in elf file. After i.MX8MN/P
> RDC enabled to proect TCM, linux not able to access the TCM space

It would be nice to know what RDC is and what it stands for.  Moreover I assume
you mean "protect" here when writing "proect".

> when updating resource table status and cause kernel dump.

How was it possible to boot an i.MX8MN before this patch?  Why wasn't this part
of the patchset that introduced support for the i.MX8MN?

> 
> So let's check whether rsc_table is available, if available, we use this
> address.
> 
> Signed-off-by: Peng Fan <peng.fan@....com>
> ---
>  drivers/remoteproc/imx_rproc.c | 13 ++++++++++++-
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
> index ff8170dbbc3c..96a56ab39ccb 100644
> --- a/drivers/remoteproc/imx_rproc.c
> +++ b/drivers/remoteproc/imx_rproc.c
> @@ -497,6 +497,17 @@ static struct resource_table *imx_rproc_get_loaded_rsc_table(struct rproc *rproc
>  	return (struct resource_table *)priv->rsc_table;
>  }
>  
> +static struct resource_table *
> +imx_rproc_elf_find_loaded_rsc_table(struct rproc *rproc, const struct firmware *fw)
> +{
> +	struct imx_rproc *priv = rproc->priv;
> +

This is lacking proper documentation.  Please specify which remote processor
is supposed to find a resource table address in the device tree and which should
rely on the address in the resource table.  It would be much better to rely on
the remote processor model to decide where to get the resource table from, and
return an error if it is not where we expect it to be.

Thanks,
Mathieu

> +	if (priv->rsc_table)
> +		return (struct resource_table *)priv->rsc_table;
> +
> +	return rproc_elf_find_loaded_rsc_table(rproc, fw);
> +}
> +
>  static const struct rproc_ops imx_rproc_ops = {
>  	.prepare	= imx_rproc_prepare,
>  	.attach		= imx_rproc_attach,
> @@ -506,7 +517,7 @@ static const struct rproc_ops imx_rproc_ops = {
>  	.da_to_va       = imx_rproc_da_to_va,
>  	.load		= rproc_elf_load_segments,
>  	.parse_fw	= imx_rproc_parse_fw,
> -	.find_loaded_rsc_table = rproc_elf_find_loaded_rsc_table,
> +	.find_loaded_rsc_table = imx_rproc_elf_find_loaded_rsc_table,
>  	.get_loaded_rsc_table = imx_rproc_get_loaded_rsc_table,
>  	.sanity_check	= rproc_elf_sanity_check,
>  	.get_boot_addr	= rproc_elf_get_boot_addr,
> -- 
> 2.25.1
>