linux-kernel - Re: [PATCHv7 06/15] remoteproc/omap: Initialize and assign reserved memory node

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: <20200304174210.GE8197@xps15>
Date:   Wed, 4 Mar 2020 10:42:10 -0700
From:   Mathieu Poirier <mathieu.poirier@...aro.org>
To:     Tero Kristo <t-kristo@...com>
Cc:     bjorn.andersson@...aro.org, ohad@...ery.com,
        linux-remoteproc@...r.kernel.org, afd@...com, s-anna@...com,
        linux-kernel@...r.kernel.org, linux-omap@...r.kernel.org
Subject: Re: [PATCHv7 06/15] remoteproc/omap: Initialize and assign reserved
 memory node

On Fri, Feb 21, 2020 at 12:19:27PM +0200, Tero Kristo wrote:
> From: Suman Anna <s-anna@...com>
> 
> The reserved memory nodes are not assigned to platform devices by
> default in the driver core to avoid the lookup for every platform
> device and incur a penalty as the real users are expected to be
> only a few devices.
> 
> OMAP remoteproc devices fall into the above category and the OMAP
> remoteproc driver _requires_ specific CMA pools to be assigned
> for each device at the moment to align on the location of the
> vrings and vring buffers in the RTOS-side firmware images. So,
> use the of_reserved_mem_device_init/release() API appropriately
> to assign the corresponding reserved memory region to the OMAP
> remoteproc device. Note that only one region per device is
> allowed by the framework.
> 
> Signed-off-by: Suman Anna <s-anna@...com>
> Signed-off-by: Tero Kristo <t-kristo@...com>
> Reviewed-by: Bjorn Andersson <bjorn.andersson@...aro.org>
> ---
>  drivers/remoteproc/omap_remoteproc.c | 13 ++++++++++++-
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/remoteproc/omap_remoteproc.c b/drivers/remoteproc/omap_remoteproc.c
> index 89084dd919ba..872cd0df342b 100644
> --- a/drivers/remoteproc/omap_remoteproc.c
> +++ b/drivers/remoteproc/omap_remoteproc.c
> @@ -17,6 +17,7 @@
>  #include <linux/module.h>
>  #include <linux/err.h>
>  #include <linux/of_device.h>
> +#include <linux/of_reserved_mem.h>
>  #include <linux/platform_device.h>
>  #include <linux/dma-mapping.h>
>  #include <linux/remoteproc.h>
> @@ -483,14 +484,23 @@ static int omap_rproc_probe(struct platform_device *pdev)
>  	if (ret)
>  		goto free_rproc;
>  
> +	ret = of_reserved_mem_device_init(&pdev->dev);
> +	if (ret) {
> +		dev_warn(&pdev->dev, "device does not have specific CMA pool.\n");
> +		dev_warn(&pdev->dev, "Typically this should be provided,\n");
> +		dev_warn(&pdev->dev, "only omit if you know what you are doing.\n");
> +	}


I suppose that if no reserved memory has been specified things will go south
pretty quickly.  I'm fine with the first line being a dev_warn() but would
devinitely move the next two to dev_info().  

Since Bjorn has already agreed to this, with or without the above:

Acked-by: Mathieu Poirier <mathieu.poirier@...aro.org>

> +
>  	platform_set_drvdata(pdev, rproc);
>  
>  	ret = rproc_add(rproc);
>  	if (ret)
> -		goto free_rproc;
> +		goto release_mem;
>  
>  	return 0;
>  
> +release_mem:
> +	of_reserved_mem_device_release(&pdev->dev);
>  free_rproc:
>  	rproc_free(rproc);
>  	return ret;
> @@ -502,6 +512,7 @@ static int omap_rproc_remove(struct platform_device *pdev)
>  
>  	rproc_del(rproc);
>  	rproc_free(rproc);
> +	of_reserved_mem_device_release(&pdev->dev);
>  
>  	return 0;
>  }
> -- 
> 2.17.1
> 
> --
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki