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 C92D1387367 for ; Fri, 13 Mar 2026 10:12:39 +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=1773396761; cv=none; b=J1Bs5EmoSW9qBCncvJiqsiRytpDbOiDPXqb4DWjbWVtkEQn7RlpsTUjh46818gXaKaru6jb+8oRaUJQB+4iM2EzemA48XXAoVZqmnWyuVthN6yF71GDGpRW3YH0IUsN4iUBBK91qiwqOzoBeBWNssEsxtnfca2Tm6PWCB8Nk1tY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773396761; c=relaxed/simple; bh=B172fkYW7Adv6DaHXie+bx7lUl2FGfQKcSP2Mk55elw=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=nqXFB6Vg+/msaf0GN0U1TMNrukhHkLgMtGs/xeSwikqBeAw0pUbwIk7L5nHeJDr2wYTyALxfHK6k7j8FzptTMYi3CVwWR/AmSEgPbtb2Npas/jIfIbk0Iesg/AgyirWpfDS9ZIJKeIpXtXDLBPCC3+7vHjT582YwvhQqDYfv4/0= 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=MFGh3MtZ; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=BkkDFQCk; 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="MFGh3MtZ"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="BkkDFQCk" Received: from pps.filterd (m0279862.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 62D7iM3C2262607 for ; Fri, 13 Mar 2026 10:12:39 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= 9BbEuZS7Ng2OaOV9gLRRvHCkVS3SerYmz9AJm+sIdhk=; b=MFGh3MtZW5t215rV Y0EmGFw5oxojVseyXu/dAGoHih85aN5vbieKbldHEU9ewd9OEMje8z61kQQ73g8o 99nG0CMRiYeD6GEngWVpqciV5s019zj21HCHszAC7VCznpcB6KIl6DGHqDz5Ua9j T3lVBB/3Ksv6iCmJfWVX+BdwucJb6RXgGYTkJRiXO3Xe+GN8FchCQQKghQ8oNE4r CK5RI8wq1J2ExUxm916HkrpUAuXcanjiARqeHRT935+uSzbuhHCEzSRMpxvzAKUJ Yp8XKZsN8eo6Q66GjUDPtjrmpyc0n/hHXvM+fL5c8FuI83A30mG+l5zt7F66kWDj vQ5z6w== 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 4cvef4rhmr-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Fri, 13 Mar 2026 10:12:39 +0000 (GMT) Received: by mail-pj1-f72.google.com with SMTP id 98e67ed59e1d1-359fe4e9ea7so1751557a91.0 for ; Fri, 13 Mar 2026 03:12:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1773396758; x=1774001558; 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=9BbEuZS7Ng2OaOV9gLRRvHCkVS3SerYmz9AJm+sIdhk=; b=BkkDFQCknUY8K/x1yfgumVQLjnXpY9cTg0+zNMue438XLGYEC1b1t9uM2Dftx+toUk FUJVYf8MBL9aHdDFNgaIE9jmExglbb0atcLFknRj9ONG5Ro8+BhTrd7EkNuposmyi1Mo rG8MZUhPIJ32fGBxc44aeaUQWTNq79Y/dSY/lQj5VlUjvxJ2YcBeUZMF77LChWOJY9WE mMlzrbDsXrtW++mNZmRo0KChtO2fxZUww2OINLLHx7HZuVACFbOp6qWXeq+XWXzXf1Xv GeRprk2EnmuYRdISV6GnlxruK5yPOl6yKdMzjxDA17WgT6mVzxgDHdBKk1HxIiQ+5+9U Aglw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773396758; x=1774001558; 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=9BbEuZS7Ng2OaOV9gLRRvHCkVS3SerYmz9AJm+sIdhk=; b=fXWB9TOZKtg4HiBIoAPQ5m5NWmBcvCguJ5kVTN1NKFrknfmAeUvj9/K7+104KA8LcZ v/cs6kTp7YkhMxgwBAhUk/CAiSK8g34eWg1SRoGxGACdqBAnEk2moH3aJZxtbfBPs8Fh sEe1nq0q35qcwVUA9/YG0C6yc6Q7bCDR4ESCtVLIlb2f4sfxYFXa9mRkIyID5vSuYvr6 cu51I6DWRDXbrGMPr1vnUhj3aZEqm7RPjSuefR6xRRk0VDC/9fRBJ8ZloM46+oSzL5z7 sbVcBFDXiYSyT/SQX3scgdgTByd5hj8LJd3gtGZl5xVWlyF5iwwsoWLWFeBeoJdWOPwt MQuA== X-Forwarded-Encrypted: i=1; AJvYcCXtmcgWJarTNzinN2gUwzhz4XgCNTjeA7HcG7EtRMu+M9U5qU868DdNbAO895++J8ZTJVl77BlhmlCGoUE=@vger.kernel.org X-Gm-Message-State: AOJu0YztvNqpjzH4InH6FCb1yTbuQw+IKfgZ54AEAs25VI8SQYa1wdgB /sFrYtVS+aTzGjZzoXSdX/IZppcFOPTjlt9FkoiyCCJ+IUwKDjxHcj+aDAS4TZzcrQzirj0WMLr Jale6+tMDrQ5OebAT500sEPTE7U5EC1sHNClHgW4Ax49KiueXpPKPt+FLBz0KL5mdJxc= X-Gm-Gg: ATEYQzy+z6hVcaZM+gN4tenes39Irtt8e/fWwIxQ30CapLMgnPalHsylCF6KOBlfjfH KPTOgUtWiu0ArvIwpoyMAtj1o2tFnNagVEwEaaYcjBbVnHuAL9AvtwcDT84jSFg/Sh9Ov+IxrfE D37t2iI2UAvHOtSid11FjD/V9qNGK5rcsZmTB7jAYgpLLxbVEJf25WxR4tUzm4GmJaSTKZW1Ejo kMdAYBNZ4DKZ0W04Qtrzv2SWljG7cBNvpaq1ZIunQfkKXPg8EOdJCL1+BW5hPM9v49Tx+E+y68H QgKbxxRh4FK+WFZj+KX4xiGKDzPUD4jhHhsEdkHGcaXzqJl2RPIjXCeENL++PV02fw1RHqDxQeW NMbRSUwOYIx6uF5p356DooK4wDgY+yn2zYXe2Ajj+k2mJCc11K3Q= X-Received: by 2002:a05:6a21:138e:b0:398:bcee:4519 with SMTP id adf61e73a8af0-398ecd1c731mr2379341637.41.1773396758367; Fri, 13 Mar 2026 03:12:38 -0700 (PDT) X-Received: by 2002:a05:6a21:138e:b0:398:bcee:4519 with SMTP id adf61e73a8af0-398ecd1c731mr2379301637.41.1773396757828; Fri, 13 Mar 2026 03:12:37 -0700 (PDT) Received: from [10.217.198.242] ([202.46.22.19]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-c73ebb96df8sm1680756a12.33.2026.03.13.03.12.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 13 Mar 2026 03:12:37 -0700 (PDT) Message-ID: <198ccf60-a4b9-438b-ad92-bc4d2cc84b83@oss.qualcomm.com> Date: Fri, 13 Mar 2026 15:42:32 +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: 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> Content-Language: en-US From: "Maulik Shah (mkshah)" In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Proofpoint-ORIG-GUID: djZj1VskpcWqjLuqrMQFBg6qL9327d2u X-Proofpoint-GUID: djZj1VskpcWqjLuqrMQFBg6qL9327d2u X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMzEzMDA3NiBTYWx0ZWRfX8Fbknr4y0hUN bIvcGsEWDjaFShVmGFvZD21wf+F95AwCV13YCOuQtcfY9vDaKM7L2bNm907lqTiI6Mvo2kP/OFo Sen6QpVVIdQ6Sh3quTeZ46fkLlxZkCsdP3TZe0NYjPExKhrj+kS4KjuCffrOkKD2exiHP+qgAoK p7s3Hdcho8Wv4KSgVidnXYdYT/8MQQusonwSV2isD/1AZtan3e5o47xBcnVths8rIWZjFRj6qBG 5+s5XVySoZZte+C9bcn2DpKNJ/EWT6Jr0cu5G3VXVeMCLke4/HtxXSOgMIYf/D327xN/A4Oti7u zytV8DxtQzMi5SM+B92di8Sq4re6v//7iYzU8DHE1gb/MaYdakU3h+Ak/pZA5X73nSmOVI0LBWQ dvFjMnpeWVE9JGUkgok4+7geLFvBzzCJkX7cT5bqv1WSCj2gty92czbjTScDYkRu2tSiGUMZD1Q o0WUgt2TasudLSK6rRQ== X-Authority-Analysis: v=2.4 cv=S9nUAYsP c=1 sm=1 tr=0 ts=69b3e317 cx=c_pps a=RP+M6JBNLl+fLTcSJhASfg==:117 a=fChuTYTh2wq5r3m49p7fHw==:17 a=IkcTkHD0fZMA:10 a=Yq5XynenixoA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=_K5XuSEh1TEqbUxoQ0s3:22 a=VwQbUJbxAAAA:8 a=COk6AnOGAAAA:8 a=EUspDBNiAAAA:8 a=j6RlDNsNG3S5HfLooScA:9 a=QEXdDO2ut3YA:10 a=iS9zxrgQBfv6-_F4QbHw:22 a=TjNXssC_j7lpFel5tvFf: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-12_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 adultscore=0 malwarescore=0 priorityscore=1501 suspectscore=0 clxscore=1015 lowpriorityscore=0 phishscore=0 bulkscore=0 spamscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2603050001 definitions=main-2603130076 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, int qcom_scm_ready(void) { if (__scm == NULL || __scm->dev == NULL) return -EPROBE_DEFER; return 0; } EXPORT_SYMBOL_GPL(qcom_scm_ready); This is inline with what cmd-db does today with cmd_db_ready() API. (drivers/soc/qcom/cmd-db.c). > >> >> Remove them from the scm device to unblock the user. >> >> Signed-off-by: Maulik Shah >> --- >> arch/arm64/boot/dts/qcom/hamoa.dtsi | 3 +-- >> 1 file changed, 1 insertion(+), 2 deletions(-) >> >> diff --git a/arch/arm64/boot/dts/qcom/hamoa.dtsi b/arch/arm64/boot/dts/qcom/hamoa.dtsi >> index d7596ccf63b90a8a002ad6e77c0fb2c1b32ec9c8..ebecf43e0d462c431540257e299e3ace054901fd 100644 >> --- a/arch/arm64/boot/dts/qcom/hamoa.dtsi >> +++ b/arch/arm64/boot/dts/qcom/hamoa.dtsi >> @@ -308,8 +308,7 @@ eud_in: endpoint { >> firmware { >> scm: scm { >> compatible = "qcom,scm-x1e80100", "qcom,scm"; >> - interconnects = <&aggre2_noc MASTER_CRYPTO QCOM_ICC_TAG_ALWAYS >> - &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>; >> + /* TODO: add interconnects */ > > Somebody will try to fix this TODO, reverting this patch. Let's find a > better way to handle it (which would also fit other platforms). > Originaly this was proposed by Sibi ([1]) to speed up PAS > authentication. Other platforms require RPM or GCC clocks to let the > firmware access crypto core. > > One of the (stupid) ideas would be to add a separate SCM (child?) device > which would be used for crypto-related SCM calls. I'd like to point out > that currently we bump those clocks or NoC bandwidth, but at the same > time we don't vote on the CX rail. I'm not sure of the firmware handles > that somehow or not. Nice catch, AFAIK firmware don't handle voting for CX rail during SCM call. > > [1] https://lore.kernel.org/all/1653289258-17699-1-git-send-email-quic_sibis@quicinc.com/ yes, I had already seen this, So remoteproc PAS driver gets performance benefit with crypto vote and interesting choice was made to place it from SCM driver. It was evaluated and considered reasonable one at that time, pasting from [2], The clocking needs for the CE relates to the SCM and not the remoteproc, and it's in line with the management of CE clocks from the SCM driver. With my limited understanding of remoteproc, SCM and crypto, - A crypto vote would no way bump up the performance of CPU jumping from/to non-secure and secure world. (actual "path" of SCM driver). if remoteproc requires the crypto vote for image validation/authentication then remoteproc should place the vote for crypto path before invoking SCM APIs, SCM don't really use this vote for itself. SCM driver though today adds/removes vote within remoteproc APIs keeping vote placement limited to remoteproc usage only. - Firmware could have put the crypto vote if firmware is doing image validation/authentication after the SCM call lands in firmware and remove it before returning to non-secure world. clearly not a choice now to update firmware. - I see crypto device too places same vote (at least on x1e) so i must be missing something and both SCM and crypto device vote are needed here. I was thinking if remoteproc should route the SCM call via crypto driver (which would places the required crypto vote) and crypto driver should then invoke the crypto related SMC calls. crypto: crypto@1dfa000 { compatible = "qcom,x1e80100-qce", "qcom,sm8150-qce", "qcom,qce"; .. interconnects = <&aggre2_noc MASTER_CRYPTO QCOM_ICC_TAG_ALWAYS &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>; }; 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. 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. d) Add separate SCM child device (with interconnects) under SoC. [2] https://lore.kernel.org/all/Yr0Os5TOITY7f0Wk@builder.lan/ Thanks, Maulik