linux-kernel - Re: [PATCHv4 06/14] 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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 7 Jan 2020 08:37:52 -0500
From:   "Andrew F. Davis" <afd@...com>
To:     Tero Kristo <t-kristo@...com>, <bjorn.andersson@...aro.org>,
        <ohad@...ery.com>, <linux-remoteproc@...r.kernel.org>
CC:     <linux-kernel@...r.kernel.org>, <mathieu.poirier@...aro.org>,
        <linux-omap@...r.kernel.org>, <s-anna@...com>
Subject: Re: [PATCHv4 06/14] remoteproc/omap: Initialize and assign reserved
 memory node

On 1/2/20 8:18 AM, 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,


Requires only at the moment due to firmware..

This sounds like some firmware images hard-coded their vring addresses
instead of getting them dynamically as they should and we are hacking
around that on the kernel side by giving them the addresses they use as
carveouts.

Should we rather make use of the IOMMU attached to the DSP to map any
kernel address to the DSP where the firmware expects it? Or better yet
fixup the firmwares.

DRAM carveouts should be a last resort used only for when hardware
really requires it.

Andrew


> 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 | 12 +++++++++++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/remoteproc/omap_remoteproc.c b/drivers/remoteproc/omap_remoteproc.c
> index 9ca337f18ac2..8a6dd742a8b1 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>
> @@ -480,14 +481,22 @@ 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_err(&pdev->dev, "device does not have specific CMA pool\n");
> +		goto free_rproc;
> +	}
> +
>  	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;
> @@ -499,6 +508,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;
>  }
>