From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 16ECD33ADBD for ; Wed, 28 Jan 2026 09:39:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.180.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769593156; cv=none; b=kwaTT1izNZJ8PYuevIA54WTF2qNOhDrFWEQERgB0IDiAKTnvPqK/wJ7r+JyAIzm1k/Iz8ZEsF4dKFlwiRbSXfO4J4RTnmy+tKcbYvWehYR3fAyN3B2CcXeYcObdR/sbc3DiNguend/IGmUcWtVdYgZFR1WpbCtQDOLfV/kTx2r4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769593156; c=relaxed/simple; bh=K5ZEN/duoiXPG9bzPnaDmslMimyxgixMi1nt9Q3UDOI=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=sH9lQzv5bArDGU6SdHb2pAaleNiW+LFTffX5CCnjmM/wkHYcGHMOcV7RXT7TNtts/GfA2dcFUS+J3FN/zd2hgzFBWUKAcZUnAD0xCEfNd8lEKmtcM2gdtdibEEVvzP3T26/FrDO60aFT4TNYxLjU28E9uDC/LxJirFiRwuGqf6E= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com; spf=pass smtp.mailfrom=oss.qualcomm.com; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b=SAqH+zfX; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=ENMpB49o; arc=none smtp.client-ip=205.220.180.131 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b="SAqH+zfX"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="ENMpB49o" Received: from pps.filterd (m0279872.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 60S91oC13879032 for ; Wed, 28 Jan 2026 09:39:13 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=qcppdkim1; bh= Nm5vNdqRfLEBF55FPQ1/gDCsJCzH9FYWFBL/2AtZOhg=; b=SAqH+zfXwKuoA27Q u//MjSCjUME9pePPqosMKO2u/QcUUQfXvimi7Tf8PYIwdRfVGaRK6WGlW7SWShFY xIi1XDmGJ9NUz6pjL0SMbyqcHivCMFB00WbFm1Set/cK1LqpTNlRxAa6TgNA8vLh Fmewby0sf5vorVd+9OfYLWs522rvh/a8aX1Cza0srJBQOECqzwC4UEbufjaEDXG3 5kT/4shwmv9BzrauhekkpdWz/qKAxGaP0kWspuONws2QiLzbtZRwbPmoW3NbplJz j3BEMpDRuhOnMHgobeudlFerCirZG6zPXEePnq5nuoi0i1gqwQjPdEb7v7LNFvE5 vydPag== Received: from mail-pj1-f69.google.com (mail-pj1-f69.google.com [209.85.216.69]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4bybyv0v06-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Wed, 28 Jan 2026 09:39:12 +0000 (GMT) Received: by mail-pj1-f69.google.com with SMTP id 98e67ed59e1d1-34c6e05af6fso5898363a91.1 for ; Wed, 28 Jan 2026 01:39:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1769593151; x=1770197951; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=Nm5vNdqRfLEBF55FPQ1/gDCsJCzH9FYWFBL/2AtZOhg=; b=ENMpB49oEzzWXQToLrqVYkon3wEs5qCUtkkR4gqldVy61w2atTmaXzNmxPB1axaqjL 3Aivv23raJ7GiQsSUESHNxthem7DmYk4cXB43MkswYKboC3eSLqBazHNd8KrFkpnY2hN GtpXqUnoICorWu30IaV2UrZb07xeMcLV4Guw+lwN0vLW7lefMsmDniqn9NPwMXQvBDJ5 RTW6fA1lj+h2YN3xotWKYz6C/XALmGJNr9q7V3jML81VhoHLgzR1YjHXrvzkOOGL2W4a T308z34t5I8k1QeVnoWODeyyuHhRY4TGJc0Ucjps2KkiBBguiowXk8hejJzPls1uccCw 0JqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769593151; x=1770197951; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Nm5vNdqRfLEBF55FPQ1/gDCsJCzH9FYWFBL/2AtZOhg=; b=lUMZavN2dT/RMinmOU/RGvd93THieGdRoedwqQgrH+WcL5xMbzUGBy8UhRNvpnvY2D gAAw6+2iAWLsK0sy5NVj5C9p2BZHusGDr+Ltw/sBC7+0GNghB4A+HUiLRkOi0HbOo+la EHKd/NgI51mLu41NKQ60o78yk6+hivM6RzQ87+mHVe5IQjfh4Bh1d0F0InvTfo4rTPPe VuJQZvOx2UNa/Fsd7ayRFpWbs0eKRNHdZt4Orq7FHKI2thlcg1K/gYOZVFX/be5B1/81 IQp370qqLcNmj97bQ3gAPYC9d4ghPErXLbXGPNJchBMdISosJdclT12CbAMPSwsPdt+O ho/g== X-Forwarded-Encrypted: i=1; AJvYcCWXMDNiV08zMAg7n8r7xxZG+g184j1CzTIXZnPq1uwkS4N7XjSy9eYxIlcL2i6uTubcqUaz+mHQoTmrv0U=@vger.kernel.org X-Gm-Message-State: AOJu0Yy7ZKc0Uqj+a25Q5wTeOlje+6L98rHygVTAjetewWG1Wc8Ie+xz uFYc3qpJaQZuSsOaJpYIh4wONPcxoUC1EnsUS9Fso5V3yOVXiOtTVRgQdYdJMHblpZL2CkRn6EB YqDcsFB3KNledm9I2j6YDZwgOpQ2lfYuJBK1NJURAszVHLMdkkbITxVSRiP7hNJJwnG2rzuL5CR 8= X-Gm-Gg: AZuq6aKqQItORCcxUTAl3ZaZL9O6w7GZnoo9/b1IIrNlMDpJ5EOpi7/eWcO6WiAgf2N zRtGT/mHVz5AWS6/PvXn8wvvCC3SiLpLN2plguVVip+taaTRJJknPHiEA/rx3n0clmkTzj752u0 IJAelW9KmKXj8RT1IZreRVigLt78QLQy3GjULUJG47ze/6PDSKp/qU0aaLwQM0SZGS6o0RVS2RQ AP/4fBVr/0DCGhq/pgWeVvxNc3QPLGEYewOcGjsDhNe9mZNw+20wMIDc8rzwWGE90Nk1xYU5/lz PNnPdlELlzAUR3pIITCdJXqYEmfTeg2QbsaR11zdvCQ9GID93q0sb3OXMkqfbKcqT0Zml+YcvyQ V2GTAvphyuPMgGuLxe4lOiDqNRKHFky+s9so2Yuc= X-Received: by 2002:a17:90a:dfc4:b0:341:88d5:a74e with SMTP id 98e67ed59e1d1-353fed87bf8mr4407365a91.29.1769593151457; Wed, 28 Jan 2026 01:39:11 -0800 (PST) X-Received: by 2002:a17:90a:dfc4:b0:341:88d5:a74e with SMTP id 98e67ed59e1d1-353fed87bf8mr4407331a91.29.1769593150691; Wed, 28 Jan 2026 01:39:10 -0800 (PST) Received: from [10.218.12.237] ([202.46.22.19]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-353f61e0007sm5012246a91.12.2026.01.28.01.39.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Jan 2026 01:39:10 -0800 (PST) Message-ID: Date: Wed, 28 Jan 2026 15:09:02 +0530 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 2/8] remoteproc: qcom: probe all child devices To: Dmitry Baryshkov Cc: Bjorn Andersson , mathieu.poirier@linaro.org, robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org, rafael@kernel.org, daniel.lezcano@linaro.org, rui.zhang@intel.com, lukasz.luba@arm.com, konradybcio@kernel.org, amitk@kernel.org, mani@kernel.org, casey.connolly@linaro.org, linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org References: <20251223123227.1317244-1-gaurav.kohli@oss.qualcomm.com> <20251223123227.1317244-3-gaurav.kohli@oss.qualcomm.com> <57493aef-fb35-4377-8cf3-1df7f53470c9@oss.qualcomm.com> <74h7r3vsig3csejax3eu3uk53mdiimg2hjx7ntmmfrwdai6s3j@eiztghclfcvt> <5db5dafd-3c1f-4844-b822-bbfe86b3eb4d@oss.qualcomm.com> Content-Language: en-US From: Gaurav Kohli In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Proofpoint-GUID: VRmq-1gv9abEqLEDfZRRwIhrDP45OL6N X-Authority-Analysis: v=2.4 cv=ZZ4Q98VA c=1 sm=1 tr=0 ts=6979d940 cx=c_pps a=vVfyC5vLCtgYJKYeQD43oA==:117 a=fChuTYTh2wq5r3m49p7fHw==:17 a=IkcTkHD0fZMA:10 a=vUbySO9Y5rIA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=KKAkSRfTAAAA:8 a=PKciL30m5ai67S71p9gA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=rl5im9kqc5Lf4LNbBjHf:22 a=cvBusfyB2V15izCimMoJ:22 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMTI4MDA3NyBTYWx0ZWRfX907nCmXquQ7U d5d+GAEhqZbZ62qjnEcefEpiTLFz7KATr6rsw07jOQL8RVsdDhsaA5Uf7SW1mRbapFwxdsS+ktY Q1KllSVwr94zfuB1ZkGb0LyD/7b1W5kYFQfMq69/3yWXYDMOArLvaUGu2/KFgopvjEpIPOzEiAp pzrdCXr3yA8RS3/2eao6SN0QaLnH2csPeDT+NyoPhfoiNVR/c9U30947Wsv1Kh+WHm6kz9tInir 5eEB71zI2tLFZUbKAZNmYsf0scDICobBUgViuenjiBuSXd7LLtJbDZC6kiRkeh0QNeUKhZxlE+k csM0SYCqnt3RMkFHf3DdxbGw/mMLY55y9pxe/tAAmVVerQOrBsVU4k6VQiIPbIBaSJPMGa3aAKX yy754UAWn2R7oPmZCN+sHTS2ir44tx/t0/E4UarYRl/krpDtQD4z0uwgIyNOHl6cDut2inUHsXN s/fFyeytTaRfcqTKDXA== X-Proofpoint-ORIG-GUID: VRmq-1gv9abEqLEDfZRRwIhrDP45OL6N X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1121,Hydra:6.1.51,FMLib:17.12.100.49 definitions=2026-01-28_02,2026-01-27_03,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 bulkscore=0 adultscore=0 lowpriorityscore=0 malwarescore=0 clxscore=1015 impostorscore=0 suspectscore=0 priorityscore=1501 phishscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2601150000 definitions=main-2601280077 On 1/27/2026 10:11 PM, Dmitry Baryshkov wrote: > On Tue, Jan 27, 2026 at 09:42:10PM +0530, Gaurav Kohli wrote: >> 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 >>>>>>> >>>>>>> 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 >>>>>> 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 >>>>>>>   #include >>>>>>>   #include >>>>>>>   #include >>>>>>> @@ -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. > But you've added a subnode for it (and we are discussing exactly > of_platform_populate()) call. So, you are tying it to the remoteproc > device lifecycle instead of the remoteproc subsys, which seems strange > to me. There is no cooling device if the DSP is not running. For the cooling feature, we don’t need to define it as a subnode. The cooling subsystem becomes relevant only after the remote subsystem is up, at which point it will receive add/delete notifications from the QMI server. If child nodes must be modeled as subnodes for rproc, we can move the CDSP TMD out of the remoteproc and add in soc. Is there currently a way for the remoteproc core layer to call of_platform_populate() without requiring a subnode?