From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.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 962BA34FF4C for ; Fri, 30 Jan 2026 09:13:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.168.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769764395; cv=none; b=U3a0H08vFsq3LQ11/i87WJZFwJXMSi9H1c4ecdx6+Hy5Zu9cDgndjEpYScw9MP3RJJFz/vDrCa1Px3OWk1gdW2gP6tYMqgZIHrB+c0ia3B8x6y9coMKjLOARKnyId5sx7PT26fodnwn1pGn7rUBeCUpDdV3FBu1jrclOUJdmK00= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769764395; c=relaxed/simple; bh=cybiddfexAMODy+RV/4e1gDVrXJymUA0ZsRQi1o3S6w=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=bWfxfFf0BVekWxP8MjgHtKaOI1U4yxlMDSQj8+rY/f6M18AtdYkae7IeVd8mKsOcbpwHrEv5hbuDJt2Unfwo+UmWChxtCYamEafxINiWKXQjey7H7IksiIZ2u1m0gz2j4q3Q/JR+M0bexpa/nK7VuFvVWwZfvgWYOEvcWQdoqKY= 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=Ko3fo1Ej; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=gLptABWJ; arc=none smtp.client-ip=205.220.168.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="Ko3fo1Ej"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="gLptABWJ" Received: from pps.filterd (m0279867.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 60U3VmFd1488312 for ; Fri, 30 Jan 2026 09:13: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= fgHGfl8ahEmJiGrnzyZY0E//HZAOMDJ3Jpbm0XXwVyc=; b=Ko3fo1EjJ96BMnDC PC8X3BaThKsdZ1hdMhE+WMIg43FfAwL+yMO2bJOUcU0MYXquXd+Y+XZPvKebL4I7 H9ra7U58rAomEW/2ViLOv0znvVbx4YpVdbLW7FhWgpIc5jImuQy6F6ZIrSmsmXNy xNR+mwHKpSw3KoXT6fWIGx7E5Jpnas017NWoiuONu4iryoAqMSnz5SMJ3yLAMQ3m y8pxkMpTEm4CNGFoT7ciwFtaEwIbEV9AXHNKSnSIhaWAYSNV2DpTJBpqryA8Nb7Q z6gtU8PdoGHk/LttdagE/ywYnQYcWlCIu3qYAibnFfplOZlHPhINEDZ6RN8tLKGt xgDD3g== Received: from mail-qv1-f71.google.com (mail-qv1-f71.google.com [209.85.219.71]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4c0bp3tjje-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Fri, 30 Jan 2026 09:13:12 +0000 (GMT) Received: by mail-qv1-f71.google.com with SMTP id 6a1803df08f44-894662cba4fso1256086d6.2 for ; Fri, 30 Jan 2026 01:13:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1769764392; x=1770369192; 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=fgHGfl8ahEmJiGrnzyZY0E//HZAOMDJ3Jpbm0XXwVyc=; b=gLptABWJ6H2Xrdu6GFB+cCLYezkMayQLRUcf3tasFuFvKbMmeMQTute02V9O/imEpw W1EYxcfvo03sUPFa15eHnudSiLcX9/AxQ0uF6LC21KdS0EcOcIQKc2qC77Pxba0qnIuZ bL7nR9EQfstTL9YKOxudqaxwlnBgfJuTBZfW1L9p5Szc9od24UlJKZuXZXSRQ6deAK8b ekDLE4KCzkq1OnOtCVl7lRMLPtqhJYwxaR0uju/k5F+bL+rI3WUbcfp8RnS0BcT89hIl ifNEcBGxP62g8vlB8OIcco8r6S294z8mv4/BGas9gmaREh7UhQjEOciirWstAbGo8j0l lLEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769764392; x=1770369192; 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=fgHGfl8ahEmJiGrnzyZY0E//HZAOMDJ3Jpbm0XXwVyc=; b=mzbB71fEY4qIH+OcycjOXbqc8lBVK/Ak2M3axTzrLXwKeD+8m/hzzudKPtmMgXpXz1 sRIaRzkn9HaRhq23SYBjy2Q+DhT04fwYMfTnepYMQaT2oQzDCmLwKko3x+SU5M+TX44E jHRyFuYVkNDFOWk/SgCbGtPf0K4Uhedj8wgtjMJjzQr2AikjoN2wvlzrRsefayvjhwEJ BpM1QVZube7JX3UiyGKvmNtx/FtHkfJ8IFgT2ztnqbj0W6qDJMl8E791ocEI7CrNxenR AbtVi0eXCcMH7yi0qAvrVaMO8LsT1yk6jc7ssx4V+Whu1Uh8hoG1bSD8ZvhllAZmQZiH 8IcQ== X-Forwarded-Encrypted: i=1; AJvYcCURm+YZrmdru1yLe6fhqJ/t7uY5T9sgbGvuNFYWXv7+F+YSsus5JJD+DRbADnnanesblYI4h+p5Dd+A6Fs=@vger.kernel.org X-Gm-Message-State: AOJu0YzECE7N6x+bTHbd9GLazhktjGnYbjNBAP9R15z3d5IOAJhR28R7 IKfPDRLe+xp/KATD6uoRFOmc++NjZi1FBAgi1MfhXpINz+vlEH4ureNW/8nWkRz7ev5urIpynr7 diho+Jto6GT1rVqDl1xz8+oBi2z62UenisyxBcOsdjOWpBvpCmKoOxqdLU2vlp/6ABPI= X-Gm-Gg: AZuq6aLjU9mEDO0At6fxn1Yywz+VrLFqKnYMDpbTGUT7kQERK+wP7gUMbcIriX4sItw QwBkssUFSChvsNn1xLGeC0k+LZmsccPAQdYCXykPCwxPuw9CX1ImRsOUXeZ2ajwnEjLEL+y81c9 qmOkmtj4rYmtDNpblNNLQESZV+jF+E7cXO9hbaKxbQOhKQehEoDqGRfWiuEwCb+CDg/zu+73WK4 XHf8rpCgfGOkzItvBUEsj06VzHUgoVoANxKy8Ep5Pni0/EK3la+PPmMCGhps7ZGwXKOLOlV5Ne4 w7eVi41YZZlxbkPLo3l+gCNqYF63vQGnm2IW+b6BO+4nIDyzIVwMytHcZvzmMP2Pg81Fh6ut8FQ 2jlgKxULK/6EsrQ7Hv3LpI3PWGEAC/UfYLn7ULsIejeAISW+eFsf44A1X5RkDE5X/GyM= X-Received: by 2002:a05:6214:3316:b0:882:63cf:3970 with SMTP id 6a1803df08f44-894e9f3155fmr23295796d6.1.1769764391742; Fri, 30 Jan 2026 01:13:11 -0800 (PST) X-Received: by 2002:a05:6214:3316:b0:882:63cf:3970 with SMTP id 6a1803df08f44-894e9f3155fmr23295576d6.1.1769764391276; Fri, 30 Jan 2026 01:13:11 -0800 (PST) Received: from [192.168.119.254] (078088045245.garwolin.vectranet.pl. [78.88.45.245]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-658b46abea5sm3874864a12.31.2026.01.30.01.13.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 30 Jan 2026 01:13:09 -0800 (PST) Message-ID: Date: Fri, 30 Jan 2026 10:13:06 +0100 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: Gaurav Kohli , 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> <98397a59-8ef2-4202-ae41-015c895d6bce@oss.qualcomm.com> Content-Language: en-US From: Konrad Dybcio In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Proofpoint-GUID: wrhmWdM82oOZOU2xXeAcquN86f7PvAYB X-Proofpoint-ORIG-GUID: wrhmWdM82oOZOU2xXeAcquN86f7PvAYB X-Authority-Analysis: v=2.4 cv=d6T4CBjE c=1 sm=1 tr=0 ts=697c7628 cx=c_pps a=UgVkIMxJMSkC9lv97toC5g==:117 a=FpWmc02/iXfjRdCD7H54yg==:17 a=IkcTkHD0fZMA:10 a=vUbySO9Y5rIA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=KKAkSRfTAAAA:8 a=gv82KYJJj_s6uarY3okA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=1HOtulTD9v-eNWfpl4qZ:22 a=cvBusfyB2V15izCimMoJ:22 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMTMwMDA3MyBTYWx0ZWRfX/5pQ/ndGS8o4 PewKIXOzUcH+YdJ2DoU4ztOvXeM8YBogsRBM+ejyAH0ZotofcLKjuicEqwtAX6A0Apu2CaWRJTF 7Utbsow2GWcImGg6Y8xV27iZvwQFKdFvtVX/EKvcAiRSWylsjRR+63TRbywOJ5MKiRSTXM0s8Po 4Hch5A/foCsRg05wiJxm8hpGnmRzEENESa45wgw7MuQ9wnkOmLqkV7JUSpLd133JTpKoGNcNkiw e8liPcdv3aEXSQCGBCwB0ZZt4ynPOvwBsObshVPUN+DdfWlCkhjaRXQu9GsTMIc1NhlOwLLFDSb xJuicMc295he7bKxyYbJVDSerp/FyzOYfeU3ir4hvEFJkwSFNJvdVW+nL4yqnMtfFYyvaCS3/CD G2kgvlINi2C3JLRtimLsb4zUTspcfgiBW9DRpPB2UWANArForWnhwTRVhI083/JUVn0FKKRXoxS DOz+Q7Bi+luW35DRegg== 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-29_03,2026-01-29_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 impostorscore=0 spamscore=0 lowpriorityscore=0 adultscore=0 bulkscore=0 malwarescore=0 clxscore=1015 phishscore=0 priorityscore=1501 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2601150000 definitions=main-2601300073 On 1/30/26 8:03 AM, Gaurav Kohli wrote: > > On 1/28/2026 3:15 PM, Konrad Dybcio wrote: >> On 1/28/26 10:39 AM, Gaurav Kohli wrote: >>> 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? >> I think the question is "why can't you register the remoteproc device >> as a cooling_device, with perhaps #cooling-cells = <1>; instead of >> any form of children?" >> >> Konrad > > > thanks Konrad, for the review. > > As each subsystem can expose multiple thermal mitigation devices via the remoteproc TMD service, so need to define child node. I think you're stuck in an XY problem - you keep insisting that adding a subnode is your end goal, while you really want to achieve being able to register multiple cooling devices. Or at least that's how I read your messages since you happen not to give any explanation as to why it's actually necessary. In my previous message, I forgot that cells for cooling devices actually represent the minimum and maximum cooling state allowed. But since the API is just part of the kernel, there's nothing preventing us from evolving it. Currently, we have: Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml properties: "#cooling-cells": description: Must be 2, in order to specify minimum and maximum cooling state used in the cooling-maps reference. The first cell is the minimum cooling state and the second cell is the maximum cooling state requested. const: 2 But I think it would be perfectly fine to suggest a change such that if cells > 2, the last two cells keep the current behavior and the former ones let you index into a cooling device exposed through a single OF node e.g. rproc_xyz: remoteproc { compatible = "qcom,rproc-xyz"; ... #cooling-device-cells = <3>; }; ... thermal-zones { super-rproc-therm-a { thermal-sensors = <&rproc_xyz RPROC_XYZ_COOLING_A THERMAL_NO_LIMIT THERMAL_NO_LIMIT>; trips { ... } ; }; super-rproc-therm-b { thermal-sensors = <&rproc_xyz RPROC_XYZ_COOLING_B THERMAL_NO_LIMIT THERMAL_NO_LIMIT>; trips { ... } ; }; }; This would be resolved by allowing drivers to register an .of_xlate-type function which would take the RPROC_XYZ_COOLING_n argument and e.g. use it as an index into struct thermal_cooling_device cdev[]; within the driver struct. Konrad