| 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
| ||
|
Message-ID: <aFly61yCMttkp12e@p14s>
Date: Mon, 23 Jun 2025 09:29:47 -0600
From: Mathieu Poirier <mathieu.poirier@...aro.org>
To: Hiago De Franco <hiagofranco@...il.com>
Cc: Ulf Hansson <ulf.hansson@...aro.org>, linux-pm@...r.kernel.org,
linux-remoteproc@...r.kernel.org, Shawn Guo <shawnguo@...nel.org>,
Sascha Hauer <s.hauer@...gutronix.de>,
Bjorn Andersson <andersson@...nel.org>,
Hiago De Franco <hiago.franco@...adex.com>, imx@...ts.linux.dev,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
Peng Fan <peng.fan@....nxp.com>, daniel.baluta@....com,
iuliana.prodan@....nxp.com,
"Rafael J . Wysocki" <rafael@...nel.org>
Subject: Re: [PATCH v5 3/3] remoteproc: imx_rproc: detect and attach to
pre-booted remote cores
On Tue, Jun 17, 2025 at 04:34:50PM -0300, Hiago De Franco wrote:
> From: Hiago De Franco <hiago.franco@...adex.com>
>
> When the remote core is started before Linux boots (e.g., by the
> bootloader), the driver currently is not able to attach because it only
> checks for cores running in different partitions. If the core was kicked
Again, we have a nomenclature issue here with "If the core was kicked by the
bootloader". What does "kicked" mean here? Is it just powered and held in
reset or is it executing. And are you referring to the A core or the M core?
> by the bootloader, it is in the same partition as Linux and it is
> already up and running.
>
> This adds power mode verification through dev_pm_genpd_is_on(), enabling
> the driver to detect when the remote core is already running and
> properly attach to it if all the power domain devices are on.
>
> To accomplish this, we need to avoid passing any attach_data or flags to
> dev_pm_domain_attach_list(), letting the platform device become a
> consumer of the power domain provider. With that the current power state
> of the genpds will not change, allowing the detection of the remote core
> power state.
>
> We enable and sync the device runtime PM during probe to make sure the
> power domains are correctly managed when the core is controlled by the
> kernel.
>
> Suggested-by: Ulf Hansson <ulf.hansson@...aro.org>
> Signed-off-by: Hiago De Franco <hiago.franco@...adex.com>
> ---
> v4 -> v5:
> - pm_runtime_get_sync() removed in favor of
> pm_runtime_resume_and_get(). Now it also checks the return value of
> this function.
> - Added pm_runtime_disable() and pm_runtime_put() to imx_rproc_remove()
> function.
> v3 -> v4:
> - Changed to use the new dev_pm_genpd_is_on() function instead, as
> suggested by Ulf. This will now get the power status of the two
> remote cores power domains to decided if imx_rpoc needs to attach or
> not. In order to do that, pm_runtime_enable() and
> pm_runtime_get_sync() were introduced and pd_data was removed.
> v2 -> v3:
> - Unchanged.
> v1 -> v2:
> - Dropped unecessary include. Removed the imx_rproc_is_on function, as
> suggested.
> ---
> drivers/remoteproc/imx_rproc.c | 37 +++++++++++++++++++++++++++++-----
> 1 file changed, 32 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
> index 627e57a88db2..b53083f2553e 100644
> --- a/drivers/remoteproc/imx_rproc.c
> +++ b/drivers/remoteproc/imx_rproc.c
> @@ -18,6 +18,7 @@
> #include <linux/of_reserved_mem.h>
> #include <linux/platform_device.h>
> #include <linux/pm_domain.h>
> +#include <linux/pm_runtime.h>
> #include <linux/reboot.h>
> #include <linux/regmap.h>
> #include <linux/remoteproc.h>
> @@ -890,10 +891,8 @@ static int imx_rproc_partition_notify(struct notifier_block *nb,
> static int imx_rproc_attach_pd(struct imx_rproc *priv)
> {
> struct device *dev = priv->dev;
> - int ret;
> - struct dev_pm_domain_attach_data pd_data = {
> - .pd_flags = PD_FLAG_DEV_LINK_ON,
> - };
> + int ret, i;
> + bool detached = true;
>
> /*
> * If there is only one power-domain entry, the platform driver framework
> @@ -902,7 +901,22 @@ static int imx_rproc_attach_pd(struct imx_rproc *priv)
> if (dev->pm_domain)
> return 0;
>
> - ret = dev_pm_domain_attach_list(dev, &pd_data, &priv->pd_list);
> + ret = dev_pm_domain_attach_list(dev, NULL, &priv->pd_list);
> + /*
> + * If all the power domain devices are already turned on, the remote
> + * core is already up when the kernel booted (e.g. kicked by the
> + * bootloader). In this case attach to it.
Same comment as above. What got kicked? A core or M core. And what does
"kicked" mean? I can guess what is happening but guessing rarely leads to
anything positive.
In the next revision, please use other words than "kicked".
> + */
> + for (i = 0; i < ret; i++) {
> + if (!dev_pm_genpd_is_on(priv->pd_list->pd_devs[i])) {
> + detached = false;
> + break;
> + }
> + }
> +
> + if (detached)
> + priv->rproc->state = RPROC_DETACHED;
> +
Ok for the above.
> return ret < 0 ? ret : 0;
> }
>
> @@ -1146,6 +1160,15 @@ static int imx_rproc_probe(struct platform_device *pdev)
> }
> }
>
> + if (dcfg->method == IMX_RPROC_SCU_API) {
> + pm_runtime_enable(dev);
> + ret = pm_runtime_resume_and_get(dev);
> + if (ret) {
> + dev_err(dev, "pm_runtime get failed: %d\n", ret);
> + goto err_put_clk;
> + }
> + }
> +
> ret = rproc_add(rproc);
> if (ret) {
> dev_err(dev, "rproc_add failed\n");
> @@ -1171,6 +1194,10 @@ static void imx_rproc_remove(struct platform_device *pdev)
> struct rproc *rproc = platform_get_drvdata(pdev);
> struct imx_rproc *priv = rproc->priv;
>
> + if (priv->dcfg->method == IMX_RPROC_SCU_API) {
> + pm_runtime_disable(priv->dev);
> + pm_runtime_put(priv->dev);
> + }
> clk_disable_unprepare(priv->clk);
> rproc_del(rproc);
> imx_rproc_put_scu(rproc);
> --
> 2.39.5
>
Powered by blists - more mailing lists