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 72EBE23373E for ; Wed, 2 Apr 2025 08:38:58 +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=1743583140; cv=none; b=fS5vIVSHoa1cRogAjaSVU8gLZbJAFMZhubnwqQ6WG5KAuCS3wkvzene0wK8spaUXmGiD9pJDEVIKsQgHJNEeeGVXb3d3H1xU2ApmYjX/kD6TSE+PEngeA5ok0urMZl/7dMd/jLRxvZgIwh1HSGcf/h9n/t5CXqSyf9lc9feEJWs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1743583140; c=relaxed/simple; bh=GXqn91oM87dfs6ORjh1DbmH5yqUbfVcBo3QmJoJCJ5E=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=R1YUHct1XQ1TeL5TX9y6vkum6zdPXH3cU4htRTHb7NU0O5jp2tH/b0Sr/HVPK7e5DFsQMuO2pv4kDO9niJ3BvMjC5q5kBZ490czk2OYgVxznDZrn44e3/xSzHJvvY51zaSUui0VKoDwbNixDVfIhEmVrPzT2sdbGeIuSQ8EQQbc= 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=IXlwdO1m; 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="IXlwdO1m" Received: from pps.filterd (m0279865.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 5320tbcn014402 for ; Wed, 2 Apr 2025 08:38:57 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= GXqn91oM87dfs6ORjh1DbmH5yqUbfVcBo3QmJoJCJ5E=; b=IXlwdO1mKEyHcZRa 8XSR1STQl06bFOaPLdH9iaSGLzlA9YfEP6OuEh+Z2fr0jaVqR7WlSSsYxnxDuW/l lKp8Il1cNNRE8ogH3Op9dQpHjk/cEWzrlRgH4tpW/ICDPoy8OwKxgjMmmUlZq+m6 qKtTB6gtGPcEx10ZwJDThTxQUC60vmOLe2OwcVMqhywt+bx5MjeQfDmRqQV1lFEw pwUp1s1HvcI4RdmCX6mw6T9wQh4rntseYmAdYeuCPf8fUv8tZ1QOVarBldiebvEi Sej2G+1ZFD9lrDE7kAoWY5Tz/0+TNsbytrhyjUv7OUhEuJpSGVNLmGqLYiPPkRUa iqqXng== 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 45p7tvjrht-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Wed, 02 Apr 2025 08:38:57 +0000 (GMT) Received: by mail-pj1-f72.google.com with SMTP id 98e67ed59e1d1-3032f4ea8cfso12008391a91.3 for ; Wed, 02 Apr 2025 01:38:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743583136; x=1744187936; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=GXqn91oM87dfs6ORjh1DbmH5yqUbfVcBo3QmJoJCJ5E=; b=ttZ+pKSWMS9j2K/8H7F4fY7RfnDy5PUUK8c6UqDFxaToL2QRud2VkgSGP0vC7tNmdc GCynM96hsxNKgFCiRKKV8bVj1uqgfSX8IBOgfujJ3IhLdgbiDTzcTOQKWoQBET09Aq+3 oqQOQvZp5AKGP3VnsUoqnm0jvQybbeIets/F3aYj3n/VmRQeHz+0twv1peX8GhsKK81u YPKx4zL0BwWUbyLdbpaHK9YtKqat7VvVxjYqGjFK+S6AyiI7hk3WsMyKwsfMqAqL3ApF CiL6G1NyaxJeNGMsIEy+5sPkRsIR8nLPfLF5qSO7Ka6Vgdbg8MevTRcCAZBfTjJ/J/KE P7QA== X-Forwarded-Encrypted: i=1; AJvYcCVTAKoaYG5WzQcUeK8hLP351bKA11FeIc3BwfAhmbQd1aK6KnTjzuKYNnM2JFSID4tP17H+Ts/63RuQ1sE=@vger.kernel.org X-Gm-Message-State: AOJu0Yxcb9az3DUcE6lLIWLMsCczitJ9EMIhFxex6vDX0UxHFVdttBr8 OTPrCUAnjg29z2JTgj9TqpCpHHYd98m2avLzRcX0SqEkIooD+ugNC3/xoKNcxrGr4SPxv+RF3sU a08GNbD8LITIaiReiTo06Y7Fj8ihXsD3XxE7wkgCo52Q2/zv6BIUZabyZd6GYrQA= X-Gm-Gg: ASbGnctXXTkvVdHul2jgk/e8w/LaI3K3kRY81KovMf1NdTctJ3eyTBwpGa5ZRTqmpy2 whKe5xwFnXNztYadi7gOAeil9eFvlbi4PNxqn5NO6LOhZcycP3ObeoTvDhRcx6IndifiMUUE8PZ IU5O5aiHZwNJpqkekyt6b5KaK04gEVOU9tKQyNghuCBJTZGHSkjjO6Kqjw1NvWNmImdijFSTnPU HsJAwPoqQlqnhI3fPq2eM4GN4tqtlbj6ZSVStnXzGpc0CD//AalUCYYz3mrtZt4nzuQI7F9bHeH /s/E9DmBHNqsPwBSG0aixHswga/dKMEyE+nORcAU X-Received: by 2002:a17:90b:4c12:b0:305:2d27:7cb0 with SMTP id 98e67ed59e1d1-305320b95e3mr21253097a91.21.1743583136529; Wed, 02 Apr 2025 01:38:56 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGxpsxlI6jN778d4IK6ZYalPCibRjZVRcQJLRGaiqCKzoGfBMcE5UhmULWg6FxU234tpItMNQ== X-Received: by 2002:a17:90b:4c12:b0:305:2d27:7cb0 with SMTP id 98e67ed59e1d1-305320b95e3mr21253061a91.21.1743583136052; Wed, 02 Apr 2025 01:38:56 -0700 (PDT) Received: from [10.204.65.49] ([202.46.23.25]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2291eec52cbsm103025065ad.37.2025.04.02.01.38.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Apr 2025 01:38:55 -0700 (PDT) Message-ID: <412fe24e-ce70-4733-ace5-d3fbe43476c4@oss.qualcomm.com> Date: Wed, 2 Apr 2025 14:08:49 +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 2/3] misc: fastrpc: add support for gpdsp remoteproc To: Srinivas Kandagatla , Dmitry Baryshkov Cc: Ling Xu , andersson@kernel.org, konradybcio@kernel.org, robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org, amahesh@qti.qualcomm.com, arnd@arndb.de, gregkh@linuxfoundation.org, quic_kuiw@quicinc.com, quic_ekangupt@quicinc.com, linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org References: <20250320091446.3647918-1-quic_lxu5@quicinc.com> <20250320091446.3647918-3-quic_lxu5@quicinc.com> <30bba296-8e6f-41ee-880e-2d5ecc8fe5a4@linaro.org> <9962c517-5c0e-4d46-ac0c-2a7bab550156@linaro.org> Content-Language: en-US From: Ekansh Gupta In-Reply-To: <9962c517-5c0e-4d46-ac0c-2a7bab550156@linaro.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Authority-Analysis: v=2.4 cv=OIon3TaB c=1 sm=1 tr=0 ts=67ecf7a1 cx=c_pps a=RP+M6JBNLl+fLTcSJhASfg==:117 a=ZePRamnt/+rB5gQjfz0u9A==:17 a=IkcTkHD0fZMA:10 a=XR8D0OoHHMoA:10 a=VwQbUJbxAAAA:8 a=EUspDBNiAAAA:8 a=COk6AnOGAAAA:8 a=EjjHKn1hvHTiu-shZIMA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=iS9zxrgQBfv6-_F4QbHw:22 a=TjNXssC_j7lpFel5tvFf:22 X-Proofpoint-ORIG-GUID: CGnLW9nuVKbvumR_r98PUgf2m0-PSBpZ X-Proofpoint-GUID: CGnLW9nuVKbvumR_r98PUgf2m0-PSBpZ X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1095,Hydra:6.0.680,FMLib:17.12.68.34 definitions=2025-04-02_03,2025-04-01_01,2024-11-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 mlxlogscore=999 lowpriorityscore=0 malwarescore=0 mlxscore=0 clxscore=1015 adultscore=0 bulkscore=0 phishscore=0 suspectscore=0 impostorscore=0 spamscore=0 classifier=spam authscore=0 authtc=n/a authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.19.0-2502280000 definitions=main-2504020054 On 3/21/2025 5:53 PM, Srinivas Kandagatla wrote: > > > On 20/03/2025 18:43, Dmitry Baryshkov wrote: >> On Thu, Mar 20, 2025 at 05:11:20PM +0000, Srinivas Kandagatla wrote: >>> >>> >>> On 20/03/2025 09:14, Ling Xu wrote: >>>> The fastrpc driver has support for 5 types of remoteprocs. There are >>>> some products which support GPDSP remoteprocs. Add changes to support >>>> GPDSP remoteprocs. >>>> >>>> Reviewed-by: Dmitry Baryshkov >>>> Signed-off-by: Ling Xu >>>> --- >>>>    drivers/misc/fastrpc.c | 10 ++++++++-- >>>>    1 file changed, 8 insertions(+), 2 deletions(-) >>>> >>>> diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c >>>> index 7b7a22c91fe4..80aa554b3042 100644 >>>> --- a/drivers/misc/fastrpc.c >>>> +++ b/drivers/misc/fastrpc.c >>>> @@ -28,7 +28,9 @@ >>>>    #define SDSP_DOMAIN_ID (2) >>>>    #define CDSP_DOMAIN_ID (3) >>>>    #define CDSP1_DOMAIN_ID (4) >>>> -#define FASTRPC_DEV_MAX        5 /* adsp, mdsp, slpi, cdsp, cdsp1 */ >>>> +#define GDSP0_DOMAIN_ID (5) >>>> +#define GDSP1_DOMAIN_ID (6) >>> >>> We have already made the driver look silly here, Lets not add domain ids for >>> each instance, which is not a scalable. >>> >>> Domain ids are strictly for a domain not each instance. >> >> Then CDSP1 should also be gone, correct? > Its already gone as part of the patch that I shared in this discussion. > > I will send a proper patch to list once Ling/Ekansh has agree with it. > Thanks, Srini, for sharing this clean-up patch. It looks proper to me, but I was thinking if we could remove the domain_id dependency from the fastrpc driver. The addition of any new DSP will frequently require changes in the driver. Currently, its usage is for creating different types of device nodes and transferring memory ownership to SLPI when a memory region is added. The actual intention behind different types of device nodes can be defined as follows: fastrpc-xdsp-secure: Used for signed (privileged) PD offload and for daemons. fastrpc-xdsp: Should be used only for unsigned (less privileged) PD offload. The reason for this constraint is to prevent any untrusted process from communicating with any privileged PD on DSP, which poses a security risk. The access to different device nodes can be provided/restricted based on UID/GID (still need to check more on this; on Android-like systems, this is controlled by SELinux). There is already a qcom,non-secure-domain device tree property[1] which doesn't have a proper definition as of today. The actual way to differentiate between secure and non-secure DSP should be based on its ability to support unsigned PD. One way to remove the domain_id dependency that I can think of is to use this property to create different types of device nodes. Essentially, if unsigned PD is supported (e.g., CDSP, GPDSP), we add this property to the DT node and create both types of device nodes based on this. Otherwise, only the secure device node is created. This raises the question of backward compatibility, but I see that on most older platform DTs, this property is already added, so both device nodes will be created there, and applications will work as expected. If any old DT DSP node lacks this property, we can add it there as well. Going forward, the qcom-non-secure-property should be added only if unsigned PD is supported. This way, we can clean up the driver completely to remove the domain_id dependency. If this sounds good, I can work on this design and send out a patch. [1] https://web.git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/misc/qcom,fastrpc.yaml#n44 --Ekansh > --srini >> >