| 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: <57493aef-fb35-4377-8cf3-1df7f53470c9@oss.qualcomm.com>
Date: Fri, 23 Jan 2026 19:23:39 +0530
From: Gaurav Kohli <gaurav.kohli@....qualcomm.com>
To: Bjorn Andersson <andersson@...nel.org>
Cc: mathieu.poirier@...aro.org, robh@...nel.org, krzk+dt@...nel.org,
conor+dt@...nel.org, rafael@...nel.org, daniel.lezcano@...aro.org,
rui.zhang@...el.com, lukasz.luba@....com, konradybcio@...nel.org,
amitk@...nel.org, mani@...nel.org, casey.connolly@...aro.org,
linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org
Subject: Re: [PATCH v1 2/8] remoteproc: qcom: probe all child devices
On 1/8/2026 12:37 PM, Gaurav Kohli wrote:
>
> On 1/3/2026 8:26 PM, Bjorn Andersson wrote:
>> On Tue, Dec 23, 2025 at 06:02:21PM +0530, Gaurav Kohli wrote:
>>> From: Casey Connolly <casey.connolly@...aro.org>
>>>
>>> Generalise the qcom,bam-dmux child node support by probing all
>>> remoteproc children with of_platform_populate(). This will be used to
>>> enable support for devices which are best represented as subnodes of
>>> the
>>> remoteproc, such as those representing QMI clients.
>> Please flip this around, start with the description of the problem
>> you're trying to solve.
>>
>>> Signed-off-by: Casey Connolly <casey.connolly@...aro.org>
>> This must have your signed-off-by, where you certifies the origin of
>> this patch.
>>
>>> ---
>>> drivers/remoteproc/qcom_q6v5.c | 4 ++++
>>> drivers/remoteproc/qcom_q6v5_mss.c | 8 --------
>>> 2 files changed, 4 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/drivers/remoteproc/qcom_q6v5.c
>>> b/drivers/remoteproc/qcom_q6v5.c
>>> index 58d5b85e58cd..a02839c7ed8c 100644
>>> --- a/drivers/remoteproc/qcom_q6v5.c
>>> +++ b/drivers/remoteproc/qcom_q6v5.c
>>> @@ -6,6 +6,7 @@
>>> * Copyright (C) 2014 Sony Mobile Communications AB
>>> * Copyright (c) 2012-2013, The Linux Foundation. All rights
>>> reserved.
>>> */
>>> +#include <linux/of_platform.h>
>>> #include <linux/kernel.h>
>>> #include <linux/platform_device.h>
>>> #include <linux/interconnect.h>
>>> @@ -351,6 +352,8 @@ int qcom_q6v5_init(struct qcom_q6v5 *q6v5,
>>> struct platform_device *pdev,
>>> return dev_err_probe(&pdev->dev, PTR_ERR(q6v5->path),
>>> "failed to acquire interconnect path\n");
>>> + of_platform_populate(q6v5->dev->of_node, NULL, NULL, q6v5->dev);
>> There are other child nodes here, in particular the GLINK and SMD edges.
>> Do we really want platform_devices registered for them?
>>
>> Regards,
>> Bjorn
>
>
> thanks for pointing this, can you please suggest the right approach.
>
> This should not impact glink, as that is registering as rproc sub
> node, And we need rproc cooling as child node
>
> of remote proc subsytem to create probe dependency only.
>
>
> Can we do platform populate for specific child, would that be right
> approach. or we should create rproc cooling as independent of parent ?
>
HI Bjorn,
I’d like to highlight the impact and details of placement of remoteproc
cooling dt node:
->As a child of the remote proc subsystem node:
In this configuration, the cooling device will only be probed once
the corresponding remote proc subsystem itself is probed.
->Outside the remote proc subsystem, may be part of soc node:
In this setup, the cooling device will be probed independently. It
will wait until the remoteproc subsystem is brought up
before completing cooling registration.
The drawback here is that if the parent remoteproc subsystem is
disabled, the cooling device will still undergo an
unnecessary probe, even though it cannot be registered.
>
>>> +
>>> return 0;
>>> }
>>> EXPORT_SYMBOL_GPL(qcom_q6v5_init);
>>> @@ -361,6 +364,7 @@ EXPORT_SYMBOL_GPL(qcom_q6v5_init);
>>> */
>>> void qcom_q6v5_deinit(struct qcom_q6v5 *q6v5)
>>> {
>>> + of_platform_depopulate(q6v5->dev);
>>> qmp_put(q6v5->qmp);
>>> }
>>> EXPORT_SYMBOL_GPL(qcom_q6v5_deinit);
>>> diff --git a/drivers/remoteproc/qcom_q6v5_mss.c
>>> b/drivers/remoteproc/qcom_q6v5_mss.c
>>> index 91940977ca89..d40565c1cc62 100644
>>> --- a/drivers/remoteproc/qcom_q6v5_mss.c
>>> +++ b/drivers/remoteproc/qcom_q6v5_mss.c
>>> @@ -238,7 +238,6 @@ struct q6v5 {
>>> struct qcom_rproc_pdm pdm_subdev;
>>> struct qcom_rproc_ssr ssr_subdev;
>>> struct qcom_sysmon *sysmon;
>>> - struct platform_device *bam_dmux;
>>> bool need_mem_protection;
>>> bool has_alt_reset;
>>> bool has_mba_logs;
>>> @@ -2029,7 +2028,6 @@ static int q6v5_alloc_memory_region(struct
>>> q6v5 *qproc)
>>> static int q6v5_probe(struct platform_device *pdev)
>>> {
>>> const struct rproc_hexagon_res *desc;
>>> - struct device_node *node;
>>> struct q6v5 *qproc;
>>> struct rproc *rproc;
>>> const char *mba_image;
>>> @@ -2163,10 +2161,6 @@ static int q6v5_probe(struct platform_device
>>> *pdev)
>>> if (ret)
>>> goto remove_sysmon_subdev;
>>> - node = of_get_compatible_child(pdev->dev.of_node,
>>> "qcom,bam-dmux");
>>> - qproc->bam_dmux = of_platform_device_create(node, NULL,
>>> &pdev->dev);
>>> - of_node_put(node);
>>> -
>>> return 0;
>>> remove_sysmon_subdev:
>>> @@ -2186,8 +2180,6 @@ static void q6v5_remove(struct platform_device
>>> *pdev)
>>> struct q6v5 *qproc = platform_get_drvdata(pdev);
>>> struct rproc *rproc = qproc->rproc;
>>> - if (qproc->bam_dmux)
>>> - of_platform_device_destroy(&qproc->bam_dmux->dev, NULL);
>>> rproc_del(rproc);
>>> qcom_q6v5_deinit(&qproc->q6v5);
>>> --
>>> 2.34.1
>>>
Powered by blists - more mailing lists