linux-kernel - Re: [PATCH] remoteproc: core: Honor device tree /alias entries when assigning IDs

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:   Tue, 22 Aug 2023 13:25:12 -0600
From:   Mathieu Poirier <mathieu.poirier@...aro.org>
To:     Nishanth Menon <nm@...com>
Cc:     Bjorn Andersson <andersson@...nel.org>,
        linux-kernel@...r.kernel.org, linux-remoteproc@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org,
        Robert Nelson <robertcnelson@...il.com>,
        Kevin Cahalan <kevinacahalan@...il.com>
Subject: Re: [PATCH] remoteproc: core: Honor device tree /alias entries when
 assigning IDs

Hi Nishanth,

On Mon, Aug 07, 2023 at 09:02:47AM -0500, Nishanth Menon wrote:
> On many platforms, such as Beaglebone-AI64 with many remote
> processors, firmware configurations provided by the distributions can
> vary substantially depending on the distribution build's functionality
> and the specific remote cores enabled in that variant. Ensuring
> consistent udev rules mapping remoteproc nodes to constant remote
> proc device indices across distributions (yocto, ubuntu, debian and
> it's variants, ...) on a board basis can be challenging due to the
> various functions of these distributions. Varied device node paths
> create challenges for applications that operate on remote processors,
> especially in minimal embedded systems(initrd like) that may not
> have udev-like capabilities and rely on a more straightforward bare
> filesystem. This challenge is similar to that faced by I2C, RTC or the
> GPIO subsystems.
>

I'm puzzled by this patch.  I can see how using an alias can help in boards with
various HW configuration.  That said, and as written above, FW files for remote
processors can vary based on the build's functionality.  As such "remoteproc3"
will reference the same HW device on all distributions but the functionality
enacted by the FW may be different.  As such I don't see how an alias can help
here.  Can you provide a concrete example that highlights the benefits?

Thanks,
Mathieu

> Assign remoteproc device IDs based on device tree /aliases entries if
> present, falling back to the existing numbering scheme if there is no
> /aliases entry (which includes when the system isn't booted using DT)
> or a numbering conflict. If the alias node is not present, the driver
> behaves as before.
> 
> Cc: Robert Nelson <robertcnelson@...il.com>
> Reported-by: Kevin Cahalan <kevinacahalan@...il.com>
> Signed-off-by: Nishanth Menon <nm@...com>
> ---
> Test log: Beaglebone-AI64
> https://gist.github.com/nmenon/365cf80d6c0685dd9be7c2cb18d7c937 (along
> with a test change to force the sequence of initialization)
> 
> The report occurred on Beagle discord channel - so I am not
> sure how to share the logs of the report.
> 
>  drivers/remoteproc/remoteproc_core.c | 22 +++++++++++++++++++++-
>  1 file changed, 21 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
> index 695cce218e8c..a12f3d37b8de 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -19,6 +19,7 @@
>  #include <linux/delay.h>
>  #include <linux/kernel.h>
>  #include <linux/module.h>
> +#include <linux/of.h>
>  #include <linux/device.h>
>  #include <linux/panic_notifier.h>
>  #include <linux/slab.h>
> @@ -2417,6 +2418,25 @@ static int rproc_alloc_ops(struct rproc *rproc, const struct rproc_ops *ops)
>  	return 0;
>  }
>  
> +static int rproc_device_get_id(struct device *dev)
> +{
> +	int of_id = -1, id = -1;
> +
> +	if (dev->of_node)
> +		of_id = of_alias_get_id(dev->of_node, "remoteproc");
> +
> +	if (of_id >= 0) {
> +		id = ida_simple_get(&rproc_dev_index, of_id, of_id + 1, GFP_KERNEL);
> +		if (id < 0)
> +			dev_warn(dev, "/aliases ID %d not available\n", of_id);
> +	}
> +
> +	if (id < 0)
> +		id = ida_alloc(&rproc_dev_index, GFP_KERNEL);
> +
> +	return id;
> +}
> +
>  /**
>   * rproc_alloc() - allocate a remote processor handle
>   * @dev: the underlying device
> @@ -2476,7 +2496,7 @@ struct rproc *rproc_alloc(struct device *dev, const char *name,
>  		goto put_device;
>  
>  	/* Assign a unique device index and name */
> -	rproc->index = ida_alloc(&rproc_dev_index, GFP_KERNEL);
> +	rproc->index = rproc_device_get_id(dev);
>  	if (rproc->index < 0) {
>  		dev_err(dev, "ida_alloc failed: %d\n", rproc->index);
>  		goto put_device;
> -- 
> 2.40.0
>