linux-kernel - Re: [PATCH v1 2/8] remoteproc: qcom: probe all child devices

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: <5db5dafd-3c1f-4844-b822-bbfe86b3eb4d@oss.qualcomm.com>
Date: Tue, 27 Jan 2026 21:42:10 +0530
From: Gaurav Kohli <gaurav.kohli@....qualcomm.com>
To: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
Cc: Bjorn Andersson <andersson@...nel.org>, 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/24/2026 12:33 AM, Dmitry Baryshkov wrote:
> On Fri, Jan 23, 2026 at 07:23:39PM +0530, Gaurav Kohli wrote:
>> 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.
> Bjorns question was different. It wasn't about pushing cooling device
> outside of the remoteproc node. It is about not registering the devices.
>
> Can we follow the approach outlined by qcom_add_smd_subdev() /
> qcom_add_glink_subdev()?


Hi Dmitry,

Thanks for the review. Since the remoteproc cooling is a QMI-based 
driver, it will receive the

subsystem up notification directly. Therefore, there’s no need to make 
it a subdev node or

tie it into the init/reset sequence of remoteproc subsytem.


>