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 5C8E72F5A1C for ; Wed, 3 Dec 2025 12:36:37 +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=1764765399; cv=none; b=imHa9sE8k7dphb6tbNtjS3LEdEiZa+q2+HJHUhyPUws9DvoZeTWg92ZHSH0S0MJ3uRgD4hiwH6XbsWLPyp7nunUIg8Ru0lgRHJLBs3JL9gnsAeEyA4g7blcBPOqR+w5Zdd2g/5/uGWAhTqeBOVr4Wn4m8b3uTL8fyVxCe0YiVAI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764765399; c=relaxed/simple; bh=133zDIChdD60IUS6JZm2ZJGsM91OrEgjoeRRjXh18zc=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=XT19cy54zGa7lZMc+vZ2HHCgUetRPlaeoxR8KTVeERt9Zfjpm4c9G/SkqnjAiguI7CSCIUCZGJg6nLD85NNDrjzc/qmU35T20DCEXOVS5Drb9B9tLDz6UuivSSz1oep4j8GBdRjwCuCJaON/wlu98HiMm2EtNMs9Ugt+gF1EX7E= 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=Fje1H/Ov; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=XWmV9HOo; 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="Fje1H/Ov"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="XWmV9HOo" 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 5B396Rre805887 for ; Wed, 3 Dec 2025 12:36:36 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= ECdp/n5IfO3x2LfiEzdXETlp4AG0BzfMJTkuSdywFLk=; b=Fje1H/Ov3ZZtY/HH hJQtSmWleqciRpglbAms3u7r1TAc/2FJwlhNzPqu6FP8h8T+VrE3hVzhTNbESAk9 2n/YbqIkz+qeHkB3Rlrmpf+PgC/xQDijkIxX4Ov7Byt0wKIG+M26Yt5nm3zEuIq4 zILyGFTCBq3OqFEitnKGMzaBxgtvmjBPb0APfu04uNh8uBZHDMT5j5iUMCxmBizH OkqVEV/dlI5675cpRWxXomyRjpUVndTBZ2iUvKgV1Pd90P5KPvQepjybPzNTvSXU MReIvUI5h2Jn7yg/RcEy9yybKLpvKyzKWgen1sHaZ/fFbCkRHdfHNUikl3eCUyll saWNug== Received: from mail-qt1-f200.google.com (mail-qt1-f200.google.com [209.85.160.200]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4atbmmhxxh-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Wed, 03 Dec 2025 12:36:36 +0000 (GMT) Received: by mail-qt1-f200.google.com with SMTP id d75a77b69052e-4ee05927208so18903631cf.1 for ; Wed, 03 Dec 2025 04:36:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1764765395; x=1765370195; 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=ECdp/n5IfO3x2LfiEzdXETlp4AG0BzfMJTkuSdywFLk=; b=XWmV9HOoABMfPjeJNIvV6KIPrTD06o5GbtRqC1jxSnDUZxYuoxwm798ewVguBSXRU+ ujv7A9dYdJDvPToaylEH6n1GV8SG+tivHVaHve3dhogUK/lm8D/ZslpOzrqDWcpiL3LQ 2rLePKFs1Xvs/+3g8oWGIDEhYe57RaPB/Qe8rq6JQEI3v3RdOChUBKZS9zpNyac0+M4s NTLgS8e1JGKzffRle1wdwxPjIIbMLX/beLSc/Cpr8UrBIfaKvboWVXaqzChwbo3bB9/9 kir8n6vBMLsFJhsIpKQdx4pEswqLvICJG6QDtH7GljxLmhLuMs7sH5rsiMZ1XT5w8y0I jmtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764765395; x=1765370195; 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=ECdp/n5IfO3x2LfiEzdXETlp4AG0BzfMJTkuSdywFLk=; b=G/qTD0oM+JDAFLSn7kgxS60g4NU1VTl4fpZD+xTp3FBFizzIdC+n/e9vjmaGukpnXL MlqJNonE8P5rRtGLIrrPOgo7F0hjOYq27zpdmLTcJafRJfV4phk5LFqsS5MgP2VP5Ahg /L2HYlIlvWpLV/MxmPWHqEYKXveCFvyPwsZxToyBcS+RFACDv7opbQv/pXJSRd4NP0i3 M9LiY/sQuUQo/99BLLRwXGJV5su5/ZXvIkxXRC3YvRCnZZAnoiniermKIsgVZ7vdbMUs edzhoaJhHZsLTXAUiJY5yU49zv1udSJP/H/7SS7U/D4RRP9xnfXVMMUzlIvXeJ8DmqQ6 4qEw== X-Forwarded-Encrypted: i=1; AJvYcCWcCrQAU+fnc2UURr/tIYNXWenr6AxAoQxvE0+w2E1atogOLc/aY9btZ8ZeNEysmFFmTfFFP2I6M4UZfxs=@vger.kernel.org X-Gm-Message-State: AOJu0YwNR7d2qDDDE0Z5PZO+EbfZoFFkmQwOygj0Yf48Qaild0YCpcOw v63Xvl6id2KVatrdzcRRJaMEsF+Za+HTSi3QtAJ1NyFMoTtkyd9nv38MwmeUGspnBFh2dF1ZoeW AbXRQzHZeJYepKo0qkRXhum1Wo9I/i0SpOMcnGzUIIh6nGdH9Bu8SOPfFhnAG6/QRQdE= X-Gm-Gg: ASbGncsgrfocLQZS72yKNX5qdZbp1OEogt5zlKRL8VKeh4TUQeXPDx5IFgLb3a3yC5V blRneZgN+CVs5ljicEewWUU4RaAXfG8XGroHs7LvUFq3Q5VgZWQR087kP1ezUs7REvyGjmor+Ln 5ATiFG+87K52evATsmG5weXvg5EJ0kINtVTnPfSiP+qnPKZ6ScI/RPKl9yMAZlldPIxBH5q7upP Ol4+plw7AKTIFHaWkW28r+o9lZuqjPPuKrjz/rioxYWGY317vrtOk5OAHFX6HwXIocWzvwwyrMJ oFhUMUyWmAPlbsAywknw6eB/4LYP3kytsmVUp1Q4IUMP/WcsR88ft0a/3T81D+m58RegXtM50tY QXPUOeoANZugTCqJtRbrzPb8N1wm+Xwq+3VbfystRdY2K0kJzItU53CIZt2ZDc7GE4w== X-Received: by 2002:ac8:5715:0:b0:4e6:eaff:3a4b with SMTP id d75a77b69052e-4f01752fdd6mr19881541cf.4.1764765395456; Wed, 03 Dec 2025 04:36:35 -0800 (PST) X-Google-Smtp-Source: AGHT+IHgZNV2JmzxRkxvlZWlNQ34zmRdp6HoWlpB99+fd6sdr5WUTZMu9AQXTQ2JTGHrRS8I+lCTIg== X-Received: by 2002:ac8:5715:0:b0:4e6:eaff:3a4b with SMTP id d75a77b69052e-4f01752fdd6mr19881311cf.4.1764765394876; Wed, 03 Dec 2025 04:36:34 -0800 (PST) Received: from [192.168.119.72] (078088045245.garwolin.vectranet.pl. [78.88.45.245]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b76f5a4b762sm1798644866b.67.2025.12.03.04.36.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 03 Dec 2025 04:36:34 -0800 (PST) Message-ID: <4376b7cf-7088-412b-8596-bdec5bdc273d@oss.qualcomm.com> Date: Wed, 3 Dec 2025 13:36:32 +0100 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 v8 11/14] firmware: qcom_scm: Add qcom_scm_pas_get_rsc_table() to get resource table To: Mukesh Ojha Cc: Bjorn Andersson , Mathieu Poirier , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Manivannan Sadhasivam , Konrad Dybcio , linux-arm-msm@vger.kernel.org, linux-remoteproc@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org References: <20251121-kvm_rproc_v8-v8-0-8e8e9fb0eca0@oss.qualcomm.com> <20251121-kvm_rproc_v8-v8-11-8e8e9fb0eca0@oss.qualcomm.com> <86f3cb9f-e42d-40f9-9103-1a4953c66c71@oss.qualcomm.com> <20251124152538.wt3kzztqmpr76hsx@hu-mojha-hyd.qualcomm.com> Content-Language: en-US From: Konrad Dybcio In-Reply-To: <20251124152538.wt3kzztqmpr76hsx@hu-mojha-hyd.qualcomm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Proofpoint-GUID: IXHStgi4Tgao1_MsuGsMJnFvhRN1kWP8 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUxMjAzMDEwMCBTYWx0ZWRfX3Ox5vRCGatph rtBK9555vKxNPptoT8Ri5uLyxrrmeazX0bqVAEJjou8kj500thd0g6aQ1Aoy8VDPR8xiGyIwugU 5iX13Bbxd09KO2xS1DubkyKi95zn41jT1mBgnW4AWs4Om9CpIr1REprdrnr9tdw3febQNPSgn74 aBvYLFmH7aq/kDIqDrGi1Uv6ayZumxPY704V0/Go+rf+nlFvLgWO5KwGwJSvfADbXRex9qiKoHH qtpz6ae73T7x7zgD5yHowu2pXR2BE+sz++bvFDRA3c6ttp23MeFW3w69s+eN/A3IFm1wkqSmQDN nwZMmAtEwX/iTZ1EzQF6oiNqBhXTMUbeo9nKvynrE8p9o+Fjjz9DYzyLwMgmzl1Kahj5bpufFpJ TH/GJtIbiHO2HUr45Z3xyt5FyDyhuw== X-Proofpoint-ORIG-GUID: IXHStgi4Tgao1_MsuGsMJnFvhRN1kWP8 X-Authority-Analysis: v=2.4 cv=ApjjHe9P c=1 sm=1 tr=0 ts=69302ed4 cx=c_pps a=JbAStetqSzwMeJznSMzCyw==:117 a=FpWmc02/iXfjRdCD7H54yg==:17 a=IkcTkHD0fZMA:10 a=wP3pNCr1ah4A:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VwQbUJbxAAAA:8 a=EUspDBNiAAAA:8 a=G1CHwEGKOm80qSXAIBcA:9 a=QEXdDO2ut3YA:10 a=uxP6HrT_eTzRwkO_Te1X:22 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-12-03_01,2025-11-27_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 lowpriorityscore=0 priorityscore=1501 impostorscore=0 adultscore=0 bulkscore=0 phishscore=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-2510240001 definitions=main-2512030100 On 11/24/25 4:25 PM, Mukesh Ojha wrote: > On Mon, Nov 24, 2025 at 12:48:31PM +0100, Konrad Dybcio wrote: >> On 11/21/25 12:01 PM, Mukesh Ojha wrote: >>> Qualcomm remote processor may rely on Static and Dynamic resources for >>> it to be functional. Static resources are fixed like for example, >>> memory-mapped addresses required by the subsystem and dynamic >>> resources, such as shared memory in DDR etc., are determined at >>> runtime during the boot process. >>> >>> For most of the Qualcomm SoCs, when run with Gunyah or older QHEE >>> hypervisor, all the resources whether it is static or dynamic, is >>> managed by the hypervisor. Dynamic resources if it is present for a >>> remote processor will always be coming from secure world via SMC call >>> while static resources may be present in remote processor firmware >>> binary or it may be coming qcom_scm_pas_get_rsc_table() SMC call along >>> with dynamic resources. >>> >>> Some of the remote processor drivers, such as video, GPU, IPA, etc., do >>> not check whether resources are present in their remote processor >>> firmware binary. In such cases, the caller of this function should set >>> input_rt and input_rt_size as NULL and zero respectively. Remoteproc >>> framework has method to check whether firmware binary contain resources >>> or not and they should be pass resource table pointer to input_rt and >>> resource table size to input_rt_size and this will be forwarded to >>> TrustZone for authentication. TrustZone will then append the dynamic >>> resources and return the complete resource table in output_rt >>> >>> More about documentation on resource table format can be found in >>> include/linux/remoteproc.h >>> >>> Signed-off-by: Mukesh Ojha >>> --- >> >> [...] >> >>> +int qcom_scm_pas_get_rsc_table(struct qcom_scm_pas_context *ctx, void *input_rt, >>> + size_t input_rt_size, void **output_rt, >>> + size_t *output_rt_size) >>> +{ >>> + unsigned int retry_num = 5; >>> + int ret; >>> + >>> + do { >>> + *output_rt = kzalloc(*output_rt_size, GFP_KERNEL); >>> + if (!*output_rt) >>> + return -ENOMEM; >>> + >>> + ret = __qcom_scm_pas_get_rsc_table(ctx->pas_id, input_rt, >>> + input_rt_size, output_rt, >>> + output_rt_size); >>> + if (ret) >>> + kfree(*output_rt); >>> + >>> + } while (ret == -EAGAIN && --retry_num); >> >> Will firmware return -EAGAIN as a result, or is this to handle the >> "buffer too small case"? > > The latter one where a re-attempt could pass.. > >> >> I think the latter should use a different errno (EOVERFLOW?) and print >> a message since we decided that it's the caller that suggests a suitable >> output buffer size > > Agree with error code.. > > This is kept on the caller side keeping future in mind. where we can have > resource table coming from the client and it needs to go to TZ for > authentication. > > Are you suggesting to move this retry on the caller side ? I think we got confused in the review of the previous iterations and made qcom_scm_pas_get_rsc_table() retry 5 times (on the basis that "some" error could happen in firmware), but if it's specifically "buf too small", we should only need to call it utmost twice - once to get the required larger size (or succeed and exit) and another one with a now-correctly sized buffer. Looking at it again, do we really need to be so stringent about the maximum resource table size? Can we just push the currently defined SZ_16K inside qcom_scm_pas_get_rsc_table() as a constant and bump it up as necessary in the future? > Just for information, once video patches becomes ready, we may bring this > qcom_mdt_pas_map_devmem_rscs()[1] helper for video or any other client > should be do this here as well ? > > I wanted to optimize this path, where caller is making a guess and > gets the updated output size in return. We always end up allocating in __qcom_scm_pas_get_rsc_table() so I think guessing a number like SZ_16K which is plenty for a effectively small u64[] in this file is ok too. Perhaps we could even shrink it down a bit.. > [1] > https://lore.kernel.org/lkml/20250819165447.4149674-9-mukesh.ojha@oss.qualcomm.com/#t > >> >> In case it doesn't make sense for the caller to share their expectations, >> the buffer could be allocated (and perhaps resized if necessary) internally >> with some validation (i.e. a rsctable likely won't be 5 GiB) > > Are you saying output_size as well should be checked and it should not be > greater than something like UINT_MAX or something.. ? > > + *output_rt_size = res.result[2]; Yeah we should probably make sure this doesn't exceed a large-but-not- entirely-unreasonable value Konrad