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 A89EC37F74F for ; Fri, 13 Mar 2026 15:17:36 +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=1773415057; cv=none; b=W43MksJ9wD7mkh90pIdB71j35YrOdKrWlH6BsKV40auwL+/ahPKNoeSmBCbnttjyjtZp27T6bqrb4h6GbHlAPzyDkG4HfifK3HMFWeKBIomr9wumr+6iV4FRYu63znGx2mIvLS4SxnaRMA4N963lq//Y6y8lzGjqXUGfse+nE7k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773415057; c=relaxed/simple; bh=l4HEowm5Fwgt90UaF5x2GYpYEwjxSinAsmsMDdusFdM=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=tqGmMJRz4RLSm78Kqj5qyoa/BgpE/jruFIlSNpRdqgQkU2dFQrY/gLyfqarPCrzACM2YBcHx4EsVrLcpqxJeUNYJOxiZsz/x/ybjpxUfoRzGLfNEOlRDKQLToATLlcMGHCOYLF2ct8jcahhtyDqed9cav+b0fGzrWwIFrVcSKE8= 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=DSKbESfP; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=UrQ3ikHV; 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="DSKbESfP"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="UrQ3ikHV" Received: from pps.filterd (m0279873.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 62D9B9FH3906341 for ; Fri, 13 Mar 2026 15:17:35 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= b8W61Muwi7dV63yRzThS1OSpPDfzReo082YGSyg6OME=; b=DSKbESfPijDRGU5Q PlLfExsCxVuH3htsE1f4t1mJ3nX1w5/rW0u/r4JFCXkpBSKNWl5jvu9rZaYcM9Pw EDBK4geza49DvwZBNkZbT7FuqnXwSIAu4gr0L5b8kI5uM64O6EXUi2YlQmu6DwfL FamQrNjhN8JZ0iVoaYjgQZRMdCBbZz6rT+/zW951Hxk2ZkehzwUqfKlcOZ+5tBGL 6ynZVvhLT/Y/bLzqfKb3x/iEN3sNJySMszUcLq1bSjKhDwZQSwfRe0do89RfgEWs xbnESEgGaBeZvBRDOGOIhDTs834FXqblh6SMp7wbpm8UtHmBSPV652Qmw3oBkXjb +3fHEw== Received: from mail-pj1-f72.google.com (mail-pj1-f72.google.com [209.85.216.72]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4cvfqs97e5-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Fri, 13 Mar 2026 15:17:35 +0000 (GMT) Received: by mail-pj1-f72.google.com with SMTP id 98e67ed59e1d1-3568090851aso16817906a91.1 for ; Fri, 13 Mar 2026 08:17:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1773415054; x=1774019854; 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=b8W61Muwi7dV63yRzThS1OSpPDfzReo082YGSyg6OME=; b=UrQ3ikHVDfXr7kIn7sSq2BkeCXNhqjjQUr0cvZ1JCIcEX6tjbfqpbZ2wnuJM1n6J0S 4AsmaJ8AjO5JiI3zygSRhMGfnrp+2PmCB4aNsPVCQRDaTS4XyAxsGu9sxFK/bH2/bRo+ kAdd5JYvZwYwvs9MefUpydUe0DIoW/s0ooIvtsuyEgRQHr9pIe1Eapg1i5MLoxKC0duL /VN9oyqEbeQNip4ivmezkZ2duRGucKArXANeEkDQOPFAESXyz2bR+wO5ySty7d2iug5P OdPT78kJRha5Vre4evbak7bYQ3qmlU7dgUKtzdyiC7HDhCaJbiBSMfkOiq0fnamcOg9i Sadw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773415054; x=1774019854; 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=b8W61Muwi7dV63yRzThS1OSpPDfzReo082YGSyg6OME=; b=XBhiluzuJycDg0zxmQEsIrDn0/qMVpXQA3jPWVKJulq70aL/ajBVzO6Zz91WRThJxa ThCDqhQ0EkCmTmqekKV5jzOpThXoQOssTtiIEuxuc2wAfhTV6+lHtE5ahAYLQ9oczUIz JHoB4qyxyk2LnDJ+Ip3CnW8aK5P3lG0PBQ58+k5XemARP6jT+H0oF95hW7GJg+TJnQB/ dRsLBp/O8yS5Bna9oCpv7kW6lP2E68xQuQX2q1/H7PEKcpOSNSuerPb0+D6HUI1oPILx jfsbRBqX4OGXKkJbbr3YxyvhJaYtGlyRaNVUzftl/lTvS7ljFaybJrUjZvM+5UjmOoI/ Ud/A== X-Forwarded-Encrypted: i=1; AJvYcCWPNjG2nAkoDfQwf2eQA1pCzDtJeX4KJPeCQURJUOpDwzNyNHhNbvRCo4DgVv5i6xxWP0icCzGw1ZL9Rm0=@vger.kernel.org X-Gm-Message-State: AOJu0YyLtzOF5s2lb0+qwunhpl0eNqQ84pK5HnPTss284eX/hO1T+PM4 qO/rY64Qo3fylAltKJ0UhqBoiU1Dwp4JMgl0CHGV3Ag/zLZ6721TLnwBiCwTuUJG/P3FxtifLT4 CrpSTIMvAHqKg1E2kvCXAl+rpP9GmfuzNYnPciBlQ2Vn1svPTEZDx5r/jfms6XcGv/JIaaj3zYj g= X-Gm-Gg: ATEYQzzQeQUDlWcTRhRG8aBg/Ud3/vbCaYjbSTDp4n5UPeknoE4bNr5X4FXGRqBP9Qp Fs+5FliEQ6pqKILkhdST2oL3hKt9n7iPKaKT2JPeGf6mzccnqamXtU8aQJ+lSF+p1Zvf0rhGYI2 TB4zjny/pt/vnvJEeGtk1+0rtMdOyn3zqNFIV7YmXzLmvVx+tnVo1x8wMOCaItcO+iksMaWzBHF TcFjsqg0Q1zGn6iAaLb5uM5UFeErA7IGWcppnY7j5jM70YXGyX+y1w8IsCDbkzcFqDZTUZAf/Pn jelCkze+TO9JHwKl7GqTycIdpjQupYBH/LRALKNJOeP0eVkUIwumlhRDboktAbpgfUKRFjjezNw XU5p7wv233aIaFC6Zdqu47ySUtWiAfOwlw46FmlnRv/6oNE0Auc4= X-Received: by 2002:a17:90b:1b10:b0:356:3ba2:122c with SMTP id 98e67ed59e1d1-35a21efa8cdmr3431195a91.9.1773415054478; Fri, 13 Mar 2026 08:17:34 -0700 (PDT) X-Received: by 2002:a17:90b:1b10:b0:356:3ba2:122c with SMTP id 98e67ed59e1d1-35a21efa8cdmr3431152a91.9.1773415053961; Fri, 13 Mar 2026 08:17:33 -0700 (PDT) Received: from [192.168.29.179] ([49.43.225.26]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-35a17be605asm7039006a91.17.2026.03.13.08.17.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 13 Mar 2026 08:17:33 -0700 (PDT) Message-ID: <8a857ccf-1aef-4214-a1a6-cbd910ae5ecf@oss.qualcomm.com> Date: Fri, 13 Mar 2026 20:47:26 +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 1/5] arm64: dts: qcom: x1e80100: Remove interconnect from SCM device To: Konrad Dybcio , Dmitry Baryshkov Cc: Bjorn Andersson , Konrad Dybcio , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Thomas Gleixner , Linus Walleij , linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-gpio@vger.kernel.org, Sneh Mankad References: <20260312-hamoa_pdc-v1-0-760c8593ce50@oss.qualcomm.com> <20260312-hamoa_pdc-v1-1-760c8593ce50@oss.qualcomm.com> <198ccf60-a4b9-438b-ad92-bc4d2cc84b83@oss.qualcomm.com> <90b3a7df-cd02-4878-b614-1499589f0906@oss.qualcomm.com> Content-Language: en-US From: "Maulik Shah (mkshah)" In-Reply-To: <90b3a7df-cd02-4878-b614-1499589f0906@oss.qualcomm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Proofpoint-ORIG-GUID: eWbfzkeb3O9tgSbcUZqtvwk_H1Jhvehm X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMzEzMDEyMSBTYWx0ZWRfXw7ATtJt9UqOQ qnQdd9zOa8TQwC5CKeK6hQ/5/lk+sMqT6+8d58dh+AEEWJQZ3SowFuEkwgNkLBD9i6r32Zo+x5W OVOgbEy477ZGIW/vkd/V3eEQd1gtXm35rVnDVBh0+g2s7W+kl6gTQtNuG+U3Kqij0B6j4z2B7ko k01ZalnEcWzSL8CpzVwOvXGf6yJcvac1mPS7xOC0hw8mvJCMOf+wFJwSlvgohI0YQ7caK6LQcBO oiXrA7NRIUpWgD283rMERUzWmfjDcc2tuuXskqaGY147LMQz1OTGCylb+HM2Kn9tbqMndMuRbqg YawaJu41wbr7ORrweTbGGs4ertkfuGvT+fetkqcscW+DLPXQZxG4QgEe8gr23S3rFLFaDJ2RLGB F+F+fQbG7eDKr/ZRqTI6K9RMbXAPXTAtH26VeY/jutUeqCPIhfE3SzhvjOL4TzNWibwBM+NxiyA XUTUe5duIvGi5r0DTEQ== X-Proofpoint-GUID: eWbfzkeb3O9tgSbcUZqtvwk_H1Jhvehm X-Authority-Analysis: v=2.4 cv=GoNPO01C c=1 sm=1 tr=0 ts=69b42a8f cx=c_pps a=RP+M6JBNLl+fLTcSJhASfg==:117 a=G0zgsK738vOuM7T1zJuYQg==:17 a=IkcTkHD0fZMA:10 a=Yq5XynenixoA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=rJkE3RaqiGZ5pbrm-msn:22 a=9LLCEl3WuFZl3W-Eh58A:9 a=QEXdDO2ut3YA:10 a=iS9zxrgQBfv6-_F4QbHw:22 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.51,FMLib:17.12.100.49 definitions=2026-03-13_02,2026-03-13_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 adultscore=0 malwarescore=0 lowpriorityscore=0 spamscore=0 impostorscore=0 bulkscore=0 priorityscore=1501 phishscore=0 clxscore=1015 suspectscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2603050001 definitions=main-2603130121 On 3/13/2026 5:29 PM, Konrad Dybcio wrote: > On 3/13/26 11:12 AM, Maulik Shah (mkshah) wrote: >> >> >> On 3/13/2026 7:41 AM, Dmitry Baryshkov wrote: >>> On Thu, Mar 12, 2026 at 09:26:35PM +0530, Maulik Shah wrote: >>>> Interconnect from SCM device are optional and were added to get >>>> additional performance benefit. These nodes however delays the >>>> SCM firmware device probe due to dependency on interconnect and >>>> results in NULL pointer dereference for the users of SCM device >>>> driver APIs, such as PDC driver. >>> >>> This sounds like a bug in the PDC driver. It should reject being probed >>> before SCM is available. >> >> The SCM driver provides no way to check if its ready or not to decide to reject/defer the probe. >> A new API like below would be needed here, > > There is, qcom_scm_is_available() Thanks, i will use this API in v2 to defer the probe and drop this patch. Deferring still delays PDC probe significantly but it would unblock this series. > > >> Let me know any preferences from below options or any other. >> >> a) Add the API like qcom_scm_ready(), this has been tested and works fine. >> b) Move interconnects from SCM to remoteproc PAS driver for all devices >> Take the vote before invoking SCM API and release after return. > > I think this is not the right decision. The crypto path is only necessary, > because cryptographic checks must be carried out in the TZ in order to > (dis)allow a certain firmware binary. This is not a characteristic of the > remoteprocs themselves, as with a non-prudent TZ, the firmware loading > would amount to a memcpy() (and some SMMU/XPU configs via reg writes) This does not seem to be a characteristic of SCM either. Loading and booting the firmware is part of remoteproc and not SCM. (Documentation/devicetree/bindings/remoteproc/*) The votes required to (dis)allow loading them faster (such as crpyto) should also fall under remoteproc otherwise any driver requiring SCM API (for other purposes) would put the burden of placing votes on SCM driver? > >> c) Remove the interconnects from SCM and rely on crypto driver already >> placing the vote, Route the remote proc to SCM call via crypto API, >> This would ensure crpyto is being used and it would have placed the required vote. > > I think this would make things even worse, because instead of waiting on > the interconnect driver, we'd now have to wait on the interconnect driver, > the clock driver and the crypto driver okay, i was just wondering if crypto vote can somehow be leveraged so SCM do not need to place the vote. Thanks, Maulik