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 5037D32E73E for ; Thu, 18 Jun 2026 07:17:21 +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=1781767042; cv=none; b=ndU3WpTQQ1TsGrVHd2oxVNzQNtFlKgPHDjnVPo6m5P/LDecvqd+HpNHnkhK5Zy0wAMIXYKuVFpOm/5gkjhamhPnrO1+/xePyVkTw4p3vTge7jUFeSEqLfYsY1vh7dE1GweceJFh9TjNHXtbQBLbEB1hV/wAcqG3kAgkQX3ZqEEM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781767042; c=relaxed/simple; bh=8E5qzq+mZ2iFEEVvuk30mGz2SpkrQKNDsaBE7t3Hf5Y=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=eF6BwOuALPyZlRZCC/y+2MRKVFYTJWW0W1AjVIU6VOffrTIwXI+npZK4UprwlL/o5d/gbJLS2/erNGcW7cOtG0/Otc+qgdPen28Kn87SmMGHNdJx9oUfq5QKbBAqlup2k07+wha4Kz4d7dRnUdqCtxgSn7HpY/UHD/YgTrCGAwA= 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=UvtMUwOx; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=jnbnW6cH; 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="UvtMUwOx"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="jnbnW6cH" 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 65I67tL73515323 for ; Thu, 18 Jun 2026 07:17:20 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= t7cu/kThVOp61khadvlTa0ooRt2HujLje7priNd4Ua8=; b=UvtMUwOx+IBw1L42 6Vx/3Jt9wIEbq1W3cy4jzghi9EIUr2I98o1Xip77t/5rGDmy+0rPIPGnnoOBxFy3 qKwdu8vlJI9GNln/DNllB1BVC4bQneecQsvu5yga0JMalJHqFQl/DAxiFdn5/3Dv VxE/CgMDGRf3OboxAgtogVAfEC6aK5EMUvpczIzOV/6QYcGVhimzs8BhiA2NEU0F fxwQaWLSHz6oFLTc1SSzV7P71b03lf8Ds+BrWr8+R+rI1EjGDGRE9c4+j8zcUfGY V3E2bkE0kd7GkIzYmaHMk4atgy5EEwF1rjxTMsOthHZScdWFnvMZqxRNmHjVlyyW 7cVCmw== 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 4ev1wc21j4-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Thu, 18 Jun 2026 07:17:20 +0000 (GMT) Received: by mail-qv1-f71.google.com with SMTP id 6a1803df08f44-8dcfdbe9da2so18760786d6.0 for ; Thu, 18 Jun 2026 00:17:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1781767039; x=1782371839; 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=t7cu/kThVOp61khadvlTa0ooRt2HujLje7priNd4Ua8=; b=jnbnW6cH1RgWV1PZ+30mJFAje1p8AIFn+pADGWPa7E/Z5Orkhe7I2cxQz9K7VxsScs OR813jxRuYthujfop5Et1V2D9FV1sfFmX61B9qcgcr1MZlJ1jdkh/0E/8OIMGnpYVeBy sG+FTnNL2ONH2xQouxQF09x9nPjCsLwhNJ4pyL/Rsb/QiSe/QLA/ftFdmePrtbYBSt+r zGylPLFF0/CcvdKLHGs3FwgFmzOP9tFfbREV285oV3Q561MmE+X0oTTMWhSSQIv3E8WJ wTvN1redhyvgWZINzrZhpHfBdGiJ0KwKcP5oSg0P3tp2x1ZVvuNwBNiiNlUS2ucp6oKf ssIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781767039; x=1782371839; 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=t7cu/kThVOp61khadvlTa0ooRt2HujLje7priNd4Ua8=; b=iEZsPW1QJhGYaXZConKuDm6SE8bpRRa4Ha9/17ViN0Db88g1DWxXxCmauW4YYHXyF0 eCLxsKCl3z62e157iCwjOfZsW/SkwjBh0lfgMDKtrydGij9enJml+OxFov/NlbPnVFsJ Zw9qEHZqXWidfr5gmjP/xcJNB2kIOtBexADXOVmOvqDrbT5YIRMddM0jZQFSoAxJmzIG t5gROpj6c1MLnSnCmIqsEp3JPtJekDVZge5wDCDvKZaPFdQ3mdsIurTDKs/LH6rjXrsh 9v6NhfDUWrvuz5zWPaU59tMJQS+3eptFI/RG/iydgDTzq0Kae+sSvr2u+W7Hy2lS8a/b j0Tw== X-Forwarded-Encrypted: i=1; AFNElJ9QuU+oV4TR7Uho57Wr1tlxZRZk5qk/MUMwFSbL01Wi3IY3TLh0YvuaCFPMrAzvGV/1tDciROBYTrt85dY=@vger.kernel.org X-Gm-Message-State: AOJu0YzOBJTG1IXAjHqUfyY2KoNJXwBXh63KaSkqdhFuarn0wnW8+nGq Nn70y6xCF6a08RoVCXNCC2F6hK7aqzZzTc0DinKeqrnre9If1vhwAvZgdhDioBG0gyGzcxiDJXU OGuZ53Ywl43iKo+PNT3RnMWjG6vIVZebUE2WJfBMDzbe35WYEMu8x7PmpgXcNfavrYPA= X-Gm-Gg: Acq92OEj71t4lRljPLv7TdXw4dhXeAXKTQ/45Bqu3uXQQmr+w7EL+mBarb3MtcpUYwE CIN76LJPeuN5MnZtBd1NE1zFSAwKFOcVVoY/wcZg8cOAUgIt469rjfBFCih/SEHZh5fL/HbOE4T tWJUeMtzc94G9MoBPlvmFHE0dS8VSCXAF63tVKK5mV/DrwjB+vktZqCxVBbWFHfdNgpT3pk7WB6 vzGTyvUlovs5EbAg6hIf8ynrWcWkoyEZ461+Inud2uXg6vB9IesXMUpo7364+uWmDmAodPLrB4g P8wb+CgYviibE+sYdaiFrFZ9IvhGVfhudbeetJbwhOEbLRKVkGMYSHMHYS6a9uFczILnXdpro9g 43gGX4CLEtDF1UPAE6P7pEKD+DBkYixKRHJQaswTOExS1AebNaA0lagvuq0ILgZMF2tK/np/4Hg == X-Received: by 2002:a05:620a:4722:b0:915:8502:f808 with SMTP id af79cd13be357-91f27600dc1mr350113085a.25.1781767039526; Thu, 18 Jun 2026 00:17:19 -0700 (PDT) X-Received: by 2002:a05:620a:4722:b0:915:8502:f808 with SMTP id af79cd13be357-91f27600dc1mr350109585a.25.1781767039081; Thu, 18 Jun 2026 00:17:19 -0700 (PDT) Received: from ?IPV6:2a05:6e02:1041:c10:5ac4:8c5e:b742:f9c9? ([2a05:6e02:1041:c10:5ac4:8c5e:b742:f9c9]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4606f2c3782sm55095264f8f.25.2026.06.18.00.17.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 18 Jun 2026 00:17:18 -0700 (PDT) Message-ID: <61765401-3397-497d-a0ca-e9bf9d76cc6a@oss.qualcomm.com> Date: Thu, 18 Jun 2026 09:17:17 +0200 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 v3 1/8] dt-bindings: remoteproc: qcom,pas: add thermal mitigation properties To: Krzysztof Kozlowski , Gaurav Kohli Cc: Bjorn Andersson , Mathieu Poirier , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Amit Kucheria , Manivannan Sadhasivam , Konrad Dybcio , Kees Cook , "Gustavo A. R. Silva" , cros-qcom-dts-watchers@chromium.org, linux-arm-msm@vger.kernel.org, linux-remoteproc@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, linux-hardening@vger.kernel.org, Manaf Meethalavalappu Pallikunhi References: <20260609-qmi-tmd-v3-0-291a2ff4c634@oss.qualcomm.com> <20260609-qmi-tmd-v3-1-291a2ff4c634@oss.qualcomm.com> <20260610-ocelot-of-stimulating-excellence-bcb0fe@quoll> <03d863ee-2caa-41f2-94b5-7332fc930b42@oss.qualcomm.com> <7f1e46fb-15e3-4638-9930-8abc1dd5a778@oss.qualcomm.com> <3cbcaf8c-357e-42d2-91c1-9d1a32c55ed0@oss.qualcomm.com> <9a31bb29-75d7-42fa-b8a8-4155cf85cadf@oss.qualcomm.com> Content-Language: en-US From: Daniel Lezcano In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Authority-Analysis: v=2.4 cv=TMt1jVla c=1 sm=1 tr=0 ts=6a339b80 cx=c_pps a=UgVkIMxJMSkC9lv97toC5g==:117 a=xqWC_Br6kY4A:10 a=IkcTkHD0fZMA:10 a=FelO9ux0wxsA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=yx91gb_oNiZeI1HMLzn7:22 a=VwQbUJbxAAAA:8 a=EUspDBNiAAAA:8 a=kCrNj1x4bCXofucgv5AA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=1HOtulTD9v-eNWfpl4qZ:22 X-Proofpoint-GUID: IcELvaSSTXkBuCoAzluN-LAc2VYqPs_f X-Proofpoint-Spam-Info: AW1haW4tMjYwNjE4MDA2NSBTYWx0ZWRfXzsyOVhqb4un7 Vyv21y51zqta0lfImpXE9+IlJf9/Wvr5n4mHnFMbTM1kk77vwYoVu5/e9ZJuRKPO1I2OrPwNOQs 5jqPUxLoQgpln6hkftaE06BXdbTAkEw= X-Proofpoint-ORIG-GUID: IcELvaSSTXkBuCoAzluN-LAc2VYqPs_f X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwNjE4MDA2NSBTYWx0ZWRfX1Dig7F/8drmJ MxcL4zlHuBeIecEdG5QbaYt8hx5B1SWoGw5K1t06YHDcRt/E4iiGdHg5DpFdb4IOZl2o08Hv11V Y2PS2uzFg6H8kpSbqOYeK8QxLybekOd9l4+1cWUInSovbsTH7nuPu/O7Huq8fu0hdSXCCf6NtRI 6+EWfMm2bWEVwOq9oqMhk9Lq54YbODMWC6WEezh9ojGs3rtRQZkJExU3e4nT/bihE/CfZz+aJV7 kK9W2yVrxZhyk1kz+O0Z9IUuU5eN82xydk0C5iSev+mZEFXWsTfaR34H1+xTXMNgSOpBuL5qWcY 2ZhKCbhP3MOKv15ePvcaK8xSP7rvHj7j5keqPVUcd5hp1SnkJLGeBCBkzsjH1hHM8yPgAB+0m+y pr2WNcCQxYe52MZGGpqhSizY42f/NkDu9FHD0K4DFexAw7zpzAF/WYJJLtNRbBY+gELL7EjqaA+ pvpbzfZpUtxh38XKfGA== X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.125,FMLib:17.12.100.49 definitions=2026-06-17_02,2026-06-17_03,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 phishscore=0 bulkscore=0 adultscore=0 impostorscore=0 priorityscore=1501 suspectscore=0 lowpriorityscore=0 spamscore=0 clxscore=1015 malwarescore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2606180065 On 6/16/26 06:21, Krzysztof Kozlowski wrote: > On 15/06/2026 14:30, Daniel Lezcano wrote: >> Hi Gaurav, >>>>> thanks for review, shall i use driver data, which is basically pas >>>>> data structure like below: >>>>> >>>>> static const struct qcom_pas_data { >>>>>      .crash_reason_smem = 601, >>>>>      .firmware_name = "cdsp.mdt", >>>>>      .tmd_names = (const char *[]){"xyz", NULL}, >>>>>      .num_tmds = 1, >>>>> >>>>> Is something like above acceptable? and this will also help to filter >>>>> tmd names as well? >>>> >>>> >>>> How the thermal framework will bind the thermal zone with the TMD ? >>>> (node pointer, id) ? >>>> >>> >>> Hi Daniel, >>> >>> thanks for review. >>> >>> With id only, in this case instead of taking tmd names from device tree, >>> qmi_tmd will take tmd name from pas_data(driver) and register with the >>> cooling framework with id only. Please let us know if this looks fine. >> May be I'm missing something but: >> >> - The QMI TMD returns a list of names, not ids >> - The QMI TMD may return the list in different order than assumed >> - The cooling map index points to the name of the TMD in the DT >> - This name is used to match the name in the aformentionned list >> - The index in the list and the id in the DT can differ >> >> Krzysztof , I don't get why having the TMD names as properties is wrong, >> they describes the existing TMDs on the system and the cooling maps >> index points to the one to be connected with thermal zone. > > > 'xxx-names' have a fixed meaning in DT by convention - assign > identifiable strings to the 'xxx'. I miss the property 'tmd' in such > case - its definition and meaning. Where is it? > > But maybe you just want list of strings, so I am open to discuss it - I > don't understand the need for this property and commit and property > description tell me nothing. > > Really, this commit message is basically non-existing. It explains what > it did and provides that much explanation WHY: > > "- tmd-names (thermal mitigation device names)" > > Really? This is the explanation why this change is being made, why this > property is needed? > > So sure, describe the problem being solved and WHY this problem is being > solved that way. Maybe it will fit DT. Ok, I understand Let me try to clarify. When the QMI TMD protocol is initialized, the list of available TMDs provided by the service is requested. They are identified by a *string* not a numerical id. We can not assume the list is always in the same order because the QMI TMD is a separate subsystem and the interface is the protocol. The protocol does not refer to any TMD with an index but its name. Hardcoding an index here is not possible. The name identifies the TMD we connect to and in return we receive a handler to use when sending the QMI messages. That is for the driver part. I understand for the DT, it is possible to not give the tmd-names because the it can go into the driver's data structure. But the thermal framework won't be able to associate a cooling device (one TMD) with a thermal zone because the cooling mapping must point to a cooling device in the DT. Initially, Gaurav sent a description where each TMD was a child node of the remote proc node. And you rightfully told us it is no longer the way to go as stated in the documentation. And you suggested to replace the child nodes with an array with the tmd-names and add an index in the cooling map pointing to this array. The thermal framework has been extended to support this new format and associate the cooling device with the thermal zone. This change is now upstream for v7.2 [1] The resulting implementation is the driver gets the tmd-names array property. For each name, it connects to the QMI TMD and register the cooling device with the index corresponding to the name position on the tmd-names array. On the other side, the thermal framework parses the cooling-map, gets the index and do the association (binding). The tmd-names array property replaces the child nodes and allows to do the mapping between the string based identifier with a numerical id. I hope that clarifies the approach. -- Daniel [1] https://lore.kernel.org/all/20260526140802.1059293-12-daniel.lezcano@oss.qualcomm.com/