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

[Gaurav Kohli]

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@xxxxxxxxxx>
> > > > >
> > > > > 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@xxxxxxxxxx>
> > > > 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.


>