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 4FF253385B6 for ; Fri, 21 Nov 2025 08:11:29 +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=1763712692; cv=none; b=EjCF+eEVBryGwpj9HogQMoCZdKUqQYAucIITxObz6Gx3dkoFG4/jubgqBWGBaohw8oDEVRebL560up+BAQEVRsabpmcikHV5AVhtuHf1cyJSrzZtZfp9ltcyu+/DNyE3akeBlAArG16Dp7yx6jy1AFkLwzVt1SGw2MxiShqGxn4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763712692; c=relaxed/simple; bh=KcJktsy4rWjR7RysDuDNP6xdH8+Qlnk83GyDNML9TtY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=kx3SUTsyixMF1oWb2YDTLvAWZaXufUyPW6yE3PvuJQVN2mbygI+F14TR6VGh3ICjM5anUDnOzd0+aA7y9oNIpyOErppixDv0rmYTfJsP2gvKVpwa43IxqZKdrsCMfhpWPnH48cuRprc/w1EbfqJuE1FLdnX/hDtHOI1HAghMnsU= 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=XaQbK5g7; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=Faqdqz5l; 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="XaQbK5g7"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="Faqdqz5l" Received: from pps.filterd (m0279865.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 5AL5TFNd2831879 for ; Fri, 21 Nov 2025 08:11:28 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= KcJktsy4rWjR7RysDuDNP6xdH8+Qlnk83GyDNML9TtY=; b=XaQbK5g7HC+YWWxT /2t1e/RCrJRd4o42peRCXzeJtBzIHyTTP/OTUqOM1o16rInvA51rS+UImck8Ux5w G47wSDeEr1mhHVYBKLVj7Ep9it25XOmSWH0EaioY3zJoAfUbAvjCj4nKMYHdrSDx EK+BSg3hEtU+u6WiP+EDTPS7MPlhpolPIqw7zjlOOKSKZw1EpuGp+OK74FMSlYsE BhdvPed2zvg0XjqIX/3Y8pR+5jz/Ko4Lx6MCsdsTenK+hGveGtl3ovf/iLhVHvj8 7UFKdxpNwGhPaEqalcKTNd12ZN0NUUjl+K92NxrfTaxm1HhRPh2fQJAOgqxw/yVu pLTKNg== Received: from mail-pl1-f199.google.com (mail-pl1-f199.google.com [209.85.214.199]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4ajhyq0dxy-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Fri, 21 Nov 2025 08:11:28 +0000 (GMT) Received: by mail-pl1-f199.google.com with SMTP id d9443c01a7336-2958c80fcabso56145675ad.0 for ; Fri, 21 Nov 2025 00:11:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1763712688; x=1764317488; 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=KcJktsy4rWjR7RysDuDNP6xdH8+Qlnk83GyDNML9TtY=; b=Faqdqz5lnuHk+aRC+cIwI0Brlc9nnoPYX0tghZUWSNR3ISr38/0q3k8LnR36OSCBRl 06Y3Iyo7RLlaUB9+4Z6WwClAKDhq0cjoTPU+6WZKSArnp4w14Unwvol9EaOo+x6I5okZ iR+rfVZomTKExZYj+VpyHoaDzSL+lg95D8624EuKKTWqlNyJc3qXd36BEP2k8eeMzMPI oLt7Cc74HIOFJxSi5Qvuc+Pya0sVavk3ovw3LKKA2y8Q98dQKSBlcEVZ2eYp5P6k7ZjT JmmuUj54MX0MYWYqTgIYLj4376w9bT/gFMP60fz+bpa136FIS5jUCx7k3RenpuA/ePsC ksvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763712688; x=1764317488; 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=KcJktsy4rWjR7RysDuDNP6xdH8+Qlnk83GyDNML9TtY=; b=RntpTBjk3bTEZ4vPyVLBQcxYOJsXSNlZoCvzFdBxg61lD9yxkEiZYgBQIHAx/cXOBN BDu+s//NxiPoRz/4OmlOhCAJLD5adKiwdIy24aZ5igca0JRQaNDHVRLbtJaFQCU9Rc+C MQiDZ3jR8Dffy9AbOkqJU6nH2MxFwuZFCO4cu3feip7CyHYR/wlh4ygMxlP//m/7qfXL 1kFhE2ypreVW0gtAiOQNEtWYW4wY4BA38n78Y0SVwqXsgQrVAzTEiAGa5eOPl1bJLQoP c+iw0Vv31H2Tjijp1Dibe6m1gsj4ltU3cIpBH/b1gIIZRPxJBMfjnX9mj7FgNYqQ4rvi vl9g== X-Forwarded-Encrypted: i=1; AJvYcCWjR/UH+kLNvuTMJdJmi3C5u985A6k1IFXTp5fHsN2KJg/FUvx6rNip4yifBlXkHtUxzltJiVWhhUoWiOU=@vger.kernel.org X-Gm-Message-State: AOJu0Yx//mAcar+gETRX/LhEfsBTBvmFB2znu70Ic6ROVMhJ6wwDT+Th 5DJVeWZPlBe1cCAlLirZ5SUFkasxFafGyH8mv75URsEEFRBWzprD62b+wdKuim79VfgYSj8++48 SR63LajQBlCRmrBuDC8vCUOaXUrrc9OR8+Tc+X2AtvDDqeLhHOrlklap9a5EQdNaigYg= X-Gm-Gg: ASbGncvV5qhoCkrSOCBDVTqLo9BDtyBiF23ozUDoSKwpobCk/JygdfZfMXOLZcFrmgb 291Y90jHscH/RPlhsl9ypnIf50I8WGiEwqO/pv//21Biwt5zNlyntHz4k8D5CwL1nMuEnVG0baQ N/Fj7nhkMfLB8OJQXlok1rm6Q2o2E7OeVkfrF6wWjVEoEQn+pV9bpVFZOPYsbAJYfMS4Kx7HLwd VkpIXLzEAkeSPiHskOlIUVm/i00a7cLD8pbMJOBQwhRwPbnrllDADpgnqerDAmQnvLh0Dg4XvYf 34ACeD7+rJytq7Mfx+Ym5mU7JzqRpqRiTtSh9MiLhh+A1h1fXlS1AOvdkqzb8++XROR6lftggl0 Rfx24/s8b8Or4HYQf+urHCQ3P9XPPdgfVrv+1ByE= X-Received: by 2002:a17:902:d541:b0:295:9db1:ff32 with SMTP id d9443c01a7336-29b6bf5d676mr22230305ad.48.1763712687565; Fri, 21 Nov 2025 00:11:27 -0800 (PST) X-Google-Smtp-Source: AGHT+IGQ0POECUYr8Xi+MCkibQlmUTDkwh9AnKtRjukTgJNxNGRyWixQQuO+kWBVp6BQj31NX1Uj1Q== X-Received: by 2002:a17:902:d541:b0:295:9db1:ff32 with SMTP id d9443c01a7336-29b6bf5d676mr22229955ad.48.1763712687023; Fri, 21 Nov 2025 00:11:27 -0800 (PST) Received: from [10.204.78.148] ([202.46.23.25]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-29b5b1075ddsm48324575ad.3.2025.11.21.00.11.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 21 Nov 2025 00:11:26 -0800 (PST) Message-ID: Date: Fri, 21 Nov 2025 13:41:21 +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 v2 1/3] arm64: dts: qcom: sdm630/660: Add CDSP-related nodes To: Konrad Dybcio , Nickolay Goppen , Srinivas Kandagatla , Bjorn Andersson , Konrad Dybcio , Rob Herring , Krzysztof Kozlowski , Conor Dooley Cc: linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, ~postmarketos/upstreaming@lists.sr.ht, linux@mainlining.org, Chenna Kesava Raju , Bharath Kumar References: <20251023-qcom-sdm660-cdsp-adsp-dts-v2-0-895ffe50ab5f@mainlining.org> <20251023-qcom-sdm660-cdsp-adsp-dts-v2-1-895ffe50ab5f@mainlining.org> <07066c46-4121-48da-846a-3a180d245589@oss.qualcomm.com> <47b40a91-8365-4431-9fd9-1e48fad2a4e1@mainlining.org> <83c3aea5-764e-4e60-8b16-67b474f19357@oss.qualcomm.com> <80836b8f-16a8-4520-ad11-5ca0abb3403e@oss.qualcomm.com> <99c22e73-797c-4a30-92ba-bc3bd8cf70f0@oss.qualcomm.com> <0b06f744-b695-43d9-8da3-4424e2b53a5e@oss.qualcomm.com> <24221ce7-24e4-4eaa-8681-ed9b4b9f2d6e@oss.qualcomm.com> Content-Language: en-US From: Ekansh Gupta In-Reply-To: <24221ce7-24e4-4eaa-8681-ed9b4b9f2d6e@oss.qualcomm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Proofpoint-GUID: ft4U4eDorVJnw1TdEmZSTbYaY_YyNLuS X-Proofpoint-ORIG-GUID: ft4U4eDorVJnw1TdEmZSTbYaY_YyNLuS X-Authority-Analysis: v=2.4 cv=N94k1m9B c=1 sm=1 tr=0 ts=69201eb0 cx=c_pps a=JL+w9abYAAE89/QcEU+0QA==:117 a=ZePRamnt/+rB5gQjfz0u9A==:17 a=IkcTkHD0fZMA:10 a=6UeiqGixMTsA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VwQbUJbxAAAA:8 a=D19gQVrFAAAA:8 a=OuZLqq7tAAAA:8 a=-v0Gm8E9aN-zKP_vqnUA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=324X-CrmTo6CU4MGRt3R:22 a=W4TVW4IDbPiebHqcZpNg:22 a=AKGiAy9iJ-JzxKVHQNES:22 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUxMTIxMDA2MiBTYWx0ZWRfX6OcEsm18eun/ 4XrjQHN7w0vFMEw6ivdubzJ52kRqjdx6X88Ucltl41yaFBnl4omLJ1pSIqq2Kvo00/8sviyFjn7 Zix/ZmnlkmOcChQk04skR8Q64yajOhi8zYKFd29ELGIBN+tOFDEgygNUlxOOQUtzuzPj76R4+kx GGRuUW1TmmLJ1EIpgDMurpTXN/9mnTZNfqOXl3ILRRGqVyljpvGMrin7PwPqe7h0R/oZdGCymw1 h9+hrQb6nFfJXye3+9tzUh8a5DX3qTzE2EYlAN8/2l991Hi4ePd3O+DuGc/86UL+Mtbp/6citsy ofONoRo0ks8ztYJmhCkoJXwo3uBJu82hs41aNJJdqaofS1a9BkqRxNa+fvbgWQ3zgCi0hsgiqQC 5Ge0B3XJLHJ7c7FuU1xNNIzrao79tA== X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1121,Hydra:6.1.9,FMLib:17.12.100.49 definitions=2025-11-21_02,2025-11-20_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 suspectscore=0 spamscore=0 adultscore=0 clxscore=1015 priorityscore=1501 impostorscore=0 malwarescore=0 phishscore=0 lowpriorityscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2510240001 definitions=main-2511210062 On 11/20/2025 5:17 PM, Konrad Dybcio wrote: > On 11/20/25 11:54 AM, Ekansh Gupta wrote: >> >> On 11/20/2025 1:27 PM, Nickolay Goppen wrote: >>> 20.11.2025 07:55, Ekansh Gupta пишет: >>>> On 11/20/2025 1:58 AM, Srinivas Kandagatla wrote: >>>>> On 11/12/25 1:52 PM, Konrad Dybcio wrote: >>>>>> On 11/10/25 6:41 PM, Srinivas Kandagatla wrote: >>>>>>> On 11/3/25 12:52 PM, Konrad Dybcio wrote: >>>>>>>> On 10/31/25 12:30 PM, Nickolay Goppen wrote: >>>>>>>>> 24.10.2025 16:58, Nickolay Goppen пишет: >>>>>>>>>> 24.10.2025 11:28, Konrad Dybcio пишет: >>>>>>>>>>> On 10/23/25 9:51 PM, Nickolay Goppen wrote: >>>>>>>>>>>> In order to enable CDSP support for SDM660 SoC: >>>>>>>>>>>>    * add shared memory p2p nodes for CDSP >>>>>>>>>>>>    * add CDSP-specific smmu node >>>>>>>>>>>>    * add CDSP peripheral image loader node >>>>>>>>>>>> >>>>>>>>>>>> Memory region for CDSP in SDM660 occupies the same spot as >>>>>>>>>>>> TZ buffer mem defined in sdm630.dtsi (which does not have CDSP). >>>>>>>>>>>> In sdm660.dtsi replace buffer_mem inherited from SDM630 with >>>>>>>>>>>> cdsp_region, which is also larger in size. >>>>>>>>>>>> >>>>>>>>>>>> SDM636 also doesn't have CDSP, so remove inherited from sdm660.dtsi >>>>>>>>>>>> related nodes and add buffer_mem back. >>>>>>>>>>>> >>>>>>>>>>>> Signed-off-by: Nickolay Goppen >>>>>>>>>>>> --- >>>>>>>>>>> [...] >>>>>>>>>>> >>>>>>>>>>>> +            label = "turing"; >>>>>>>>>>> "cdsp" >>>>>>>>>> Ok, I'll change this in the next revision. >>>>>>>>>>>> +            mboxes = <&apcs_glb 29>; >>>>>>>>>>>> +            qcom,remote-pid = <5>; >>>>>>>>>>>> + >>>>>>>>>>>> +            fastrpc { >>>>>>>>>>>> +                compatible = "qcom,fastrpc"; >>>>>>>>>>>> +                qcom,glink-channels = "fastrpcglink-apps-dsp"; >>>>>>>>>>>> +                label = "cdsp"; >>>>>>>>>>>> +                qcom,non-secure-domain; >>>>>>>>>>> This shouldn't matter, both a secure and a non-secure device is >>>>>>>>>>> created for CDSP >>>>>>>>>> I've added this property, because it is used in other SoC's, such as SDM845 and SM6115 for both ADSP and CDSP >>>>>>>>> Is this property not neccessary anymore? >>>>>>>> +Srini? >>>>>>> That is true, we do not require this for CDSP, as CDSP allows both >>>>>>> unsigned and signed loading, we create both secured and non-secure node >>>>>>> by default. May be we can provide that clarity in yaml bindings so that >>>>>>> it gets caught during dtb checks. >>>>>>> >>>>>>> >>>>>>> However in ADSP case, we only support singed modules, due to historical >>>>>>> reasons how this driver evolved over years, we have this flag to allow >>>>>>> compatiblity for such users. >>>>>> Does that mean that we can only load signed modules on the ADSP, but >>>>>> the driver behavior was previously such that unsigned modules were >>>>>> allowed (which was presumably fine on devboards, but not on fused >>>>>> devices)? >>>>> Yes, its true that we allowed full access to adsp device nodes when we >>>>> first started upstreaming fastrpc driver. >>>>> >>>>> irrespective of the board only signed modules are supported on the ADSP. >>>>> I think there was one version of SoC i think 8016 or some older one >>>>> which had adsp with hvx which can load unsigned modules for compute >>>>> usecase only. >>>>> >>>>> I have added @Ekansh for more clarity. >>>>> >>>>> --srini >>>> For all the available platforms, ADSP supports only signed modules. Unsigned >>>> modules(as well as signed) are supported by CDSP and GDSP subsystems. >>>> >>>> qcom,non-secure-domain property marks the corresponding DSP as non-secure DSP. >>>> The implications of adding this property would be the following: >>>> on ADSP, SDSP, MDSP: >>>> - Only non-secure device node(/dev/fastrpc-Xdsp) is created. >>>> - Non-secure device node can be used for signed DSP PD offload. >>>> >>>> on CDSP, GDSP: >>>> - Both secure(/dev/fastrpc-Xdsp-secure) and non-secure(/dev/fastrpc-Xdsp) devices >>>>    are created, regardless of this property. >>>> - Both the nodes can be used for signed and unsigned DSP PD offload. >>>> >>>> Note: If the property is not added for CDSP/GDSP, only secure device node can >>>> be used for signed PD offload, if non-secure device is used, the request gets >>>> rejected[1]. >>>> >>>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/misc/fastrpc.c#n1245 >>>> >>>> //Ekansh >>> Does this mean that the qcom,non-secure-domain property should be dropped from both nodes?  >> I checked again and found that unsigned module support for CDSP is >> not available on this platform. Given this, the safest approach would >> be to add the property for both ADSP and CDSP, ensuring that all >> created device nodes can be used for signed PD offload. I can provide > The property allows *unsigned* PD offload though I don't think I can directly relate this property to unsigned PD offload. This is just defining what type of device node will be created and whether the channel is secure or not. There is a possibility of making unsigned PD request(on CDSP/GDSP) irrespective of whether this property is added or not. If DSP does not support unsigned offload, it should return failures for such requests. > >> a more definitive recommendation once I know the specific use cases >> you plan to run. > Why would the usecase affect this? I'm saying this as per past discussions where some application was relying on non-secure device node on some old platform(on postmarketOS)[1] and having this property in place. So if similar usecase is being enabled here, the property might be required[1]. [1] https://lkml.org/lkml/2024/8/15/117 > > Konrad