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 EA0D5237180 for ; Thu, 11 Jun 2026 03:10:34 +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=1781147437; cv=none; b=SeXh43bugymDktBeCdRPI85rEj5pdfQ6bRBKeEdGuW6qKand4hEoWVutXMVYYWJb3ZRsvcQaA3QYzbjnpOuMAtxerBYwwYbXZmun1mjhf2Q4wEK1Vj82kJdLs6ZBchaLxMH5M4A8PknawrEHUUW179gcHIzBAeQEbN39it+hya8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781147437; c=relaxed/simple; bh=/xDqAx/7oWtInGBo7t87Mo2o7EzRq/zRTqU+5rnPOvs=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=He96pL1ezfCP+BIUzEZg3k4slMgkfOyWGU3NFY1iLNe2mO7qNFp874C8oL/JhcHikLkwub5EnmmNfVcMWcyWV9teyUkEm+msDDYI768NbfpZRM9zxRgUtuzkr77GOiTuPBaLEAGSmyqidk+aS33eQCybwU0sij1pJBW7S5uRhFg= 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=KcH+fQ0T; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=cZLZku9o; 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="KcH+fQ0T"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="cZLZku9o" Received: from pps.filterd (m0279870.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 65B0OAiA3216497 for ; Thu, 11 Jun 2026 03:10:34 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= bfOXY/bV6WKanzF7Cg7TmExSjsVgoEG3Y8BQ1vxwqO0=; b=KcH+fQ0TPi0X+nmB +/D2wqO1pwI3aRF9/pjdfsU8FHH9iIAihTO2EqVifeZQecpVKJ8t5WSbnShJHfM/ MlRtMKnfmYAstu9Wn9qnoM7EvNsRxUJwN0FsrLhzqG92LInwz0+H9DjauVR9pnyb lMvnKeGFxcdSpGZQosBMGqdoQn2H3Sakc0sn8hU27KduhdU16WJYFW5KrkMLwGzC AE4EwnEb7d9STfP9QY2zxes7/TfCXs7aJ6j/7xIBCQ28TlMn+VwnwwLvEEFLhEHY W2xL4HDxdUF41mqMQzfvWqBDhHD8P4ifIUyoSEAd3TncAWp9b6KL74qCb00oWBa4 cLY9CA== 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 4eqe6u1bga-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Thu, 11 Jun 2026 03:10:33 +0000 (GMT) Received: by mail-pj1-f72.google.com with SMTP id 98e67ed59e1d1-36b97b72bd7so1650269a91.3 for ; Wed, 10 Jun 2026 20:10:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1781147433; x=1781752233; 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=bfOXY/bV6WKanzF7Cg7TmExSjsVgoEG3Y8BQ1vxwqO0=; b=cZLZku9ohUY3Kyh4kJ+N5u+FBb4tognclMkXq8Khwn+fFFuc7z0vl+U5CkTWeNaKbg zTcRzVlOT5f52BgR/ky9jgoDnD3PgDT/UZsFWjMjccxFYL3dGd1b2sMNiwbIGRmffLAv RYwx5yOJB+U6HVpcntj+61N4mUNfmWI3QtnayhQZ+lEpXYYP4kvysBkvliWr3I5/3tvg K9wRDIwzOB7OHZg1/RGSgbgtel7/2J/MErVCqN0vPzPRWFp+rdGcukk6wPXqbaYebECs 2SGtm2L6SHnX4UMbutsWbGKEx1Yw4SIXgEuS/f6/l7qrWQS+SVwstv9x0kIfQlAYroXL F8zQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781147433; x=1781752233; 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=bfOXY/bV6WKanzF7Cg7TmExSjsVgoEG3Y8BQ1vxwqO0=; b=MzWB+IGWg9iKzX/s+zc2RKyfcncKAsdVS/lT/b5OYkOOifgOIgBVSnFo5SwgYjo9Sy ekJxpVHIqtLQKbk7EYMXJw1OfLElWtvDAW0sORD6MzeHDo4vehvf9+nBJzmsBFOzfcBl pQqwP566EofZtv+8OdmZBJhJ/aS9/GCWGWOIqEpLzj84GsdH57yLYHdVTbKzqyIeRpCT kTesDFAS+Wjx92g5Etc51pMS0IVzAKLI0nwavtrrdUPDv6vy4Sx4LJQyFvBzap6x9K9M deR1OkFY2G7hybzRfEe7kDxlsEya5o7JaEh5+473d3NDcmn6dyOopYZh6y412w7jORmq ga7g== X-Forwarded-Encrypted: i=1; AFNElJ/ao2dK+BNYKwlISfDQh7QKEbpnGP2JwOrfVSRAwxLra0RwAj0JCKtGpLEcNrUbCWYFfGXLmeDjlzAcov0=@vger.kernel.org X-Gm-Message-State: AOJu0YwO8l+6ebSTXey7EvK0eeamBVrIl1IFzVNWsb0b2GhUccyf6tJS B3b2+zOHA/vuxZ+uc24cdjI9T0syrq82rwNYPax91zRkuQNVN8EZlYSrFf25g9CgBdPiwP6QQYo Vz4gi8DgTLqWerHlhZGHNXMOs5MAd1PRkn1Rpbeuh79snogVjF6zO/lLxVUf8Hadl4Pc= X-Gm-Gg: Acq92OG0aH/idcl+6BslWiB0QTZy2s1yL8HX3IHJFldgfGX2KPL+SgnHiyoVkmvxeEY gVFsIky5A/LYIZ4GQt34VooYSrzPkXVquby1rOBK63OudQ4fkfSiryaUz/hk0piv+6XodE1KrSH +KDzOrvK7xFIiKAU2bYBN76lR6OHQd9Pn/nBhphaZdbZMeW/V9nVca2ZiJlWQpnm2aB+CHnIrs2 JfLYVlMpj29jGfw5+I70u4KvbqGLsBscFLEAv6YfszAuF24Zra+8nibR4rd5wrVW69aJJGJwze+ vOxFqFwBubaWc21zupBjRj6JCMP+g+0bstZ4MHKVZZesxaIhecY0c3a+h0nBLF7zxhDS3goo5hT HrA82Z2JQf6TuTmoS+RG4pNv16B3wbo0C0TD1AG3sSv1hVfPF9zwjPE0d0DHoAntzYd+qi8AWYV hO7Pp+X9Dgpui1+CQT4IIRKEE= X-Received: by 2002:a17:90b:384b:b0:36b:5b82:4846 with SMTP id 98e67ed59e1d1-377a73e2c9cmr539096a91.5.1781147432882; Wed, 10 Jun 2026 20:10:32 -0700 (PDT) X-Received: by 2002:a17:90b:384b:b0:36b:5b82:4846 with SMTP id 98e67ed59e1d1-377a73e2c9cmr539052a91.5.1781147432287; Wed, 10 Jun 2026 20:10:32 -0700 (PDT) Received: from [10.133.33.246] (tpe-colo-wan-fw-bordernet.qualcomm.com. [103.229.16.4]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-3774f99cf24sm847549a91.0.2026.06.10.20.10.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 10 Jun 2026 20:10:31 -0700 (PDT) Message-ID: <6df4c351-7287-4fb9-8af8-83b5deabfa07@oss.qualcomm.com> Date: Thu, 11 Jun 2026 11:10:25 +0800 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 v6 5/6] remoteproc: qcom: pas: Add late attach support for subsystems To: Stephan Gerhold , Jingyi Wang Cc: Bjorn Andersson , Mathieu Poirier , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Manivannan Sadhasivam , Luca Weiss , Bartosz Golaszewski , Konrad Dybcio , shengchao.guo@oss.qualcomm.com, tingwei.zhang@oss.qualcomm.com, trilok.soni@oss.qualcomm.com, yijie.yang@oss.qualcomm.com, linux-arm-msm@vger.kernel.org, linux-remoteproc@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Gokul Krishna Krishnakumar References: <20260519-knp-soccp-v6-0-cf5d0e194b5f@oss.qualcomm.com> <20260519-knp-soccp-v6-5-cf5d0e194b5f@oss.qualcomm.com> Content-Language: en-US From: "Aiqun(Maria) Yu" In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Authority-Analysis: v=2.4 cv=PZPPQChd c=1 sm=1 tr=0 ts=6a2a2729 cx=c_pps a=RP+M6JBNLl+fLTcSJhASfg==:117 a=nuhDOHQX5FNHPW3J6Bj6AA==:17 a=IkcTkHD0fZMA:10 a=FelO9ux0wxsA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=gowsoOTTUOVcmtlkKump:22 a=VwQbUJbxAAAA:8 a=EUspDBNiAAAA:8 a=h3XtbvSS6J2BgG28aqoA:9 a=QEXdDO2ut3YA:10 a=iS9zxrgQBfv6-_F4QbHw:22 X-Proofpoint-ORIG-GUID: JrA-4OzjILZUw20-qyZZx0SPNlUr_osQ X-Proofpoint-GUID: JrA-4OzjILZUw20-qyZZx0SPNlUr_osQ X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwNjExMDAyOCBTYWx0ZWRfX0Ce31cRzBHKL AAS4UZ5VLJcEVq19SYtmxUFuLh+3MyXqGq4hUuhYy/lb3aTHT4gxsLQD6Nq0p2QHCqBoO3dqTAL B3vOXYexPGusrSZiBDFnNH4/Y0BSVGZeVP9+9YU1ultCAdMI/A92W20DaawrTNQf3lTxhpxH4ZB j1FoF9/0Ps7DGANJ+fqT+08TWS0M7Fh/ChYXelml9ZbG+oeu0IK3/KSbYvOuVb69uDswTd3ohn9 +YTUkVaqZBe6Kqgx1D70Pv/m0uUAGX6a6/39Te8/fmGxIN/YSKS0btcNuTwnNBMM7ExEbRERIBd rMfPCsYjb4t8UXs9UGkgrfcYy7ER97mrfsRhKBgZmAmdY4tcSJsVaFXg5I7cwRQCvbu+kiMQIUl MfCWSxCeOW/NvX7Hd2pFHcUvbD3lqYdPXNWlxhB+6GQlfeyZJx9B+ueXiA+uAuma7SgPAqlL96a i7iyLh5Ik4A0kPy2aYQ== X-Proofpoint-Spam-Info: AW1haW4tMjYwNjExMDAyOCBTYWx0ZWRfX7+sYZtvQYA7J 6vp2eeTY1J7OKGkCuYDdDD220KCiHeqa93P/VzTFL8iEOB8OQFmKzW+aHAl6bSjF/+jUktT2euv QeEVD1aviJZyNDja86m0HiyZDTCePVY= X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.125,FMLib:17.12.100.49 definitions=2026-06-11_01,2026-06-09_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 malwarescore=0 priorityscore=1501 adultscore=0 lowpriorityscore=0 clxscore=1011 phishscore=0 spamscore=0 suspectscore=0 bulkscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606040000 definitions=main-2606110028 On 5/22/2026 8:07 PM, Stephan Gerhold wrote: > On Tue, May 19, 2026 at 12:24:23AM -0700, Jingyi Wang wrote: >> Subsystems can be brought out of reset by entities such as bootloaders. >> As the irq enablement could be later than subsystem bring up, the state >> of subsystem should be checked by reading SMP2P bits. >> >> A new qcom_pas_attach() function is introduced. if a crash state is >> detected for the subsystem, rproc_report_crash() is called. If the ready >> state is detected, it will be marked as "attached", otherwise it could >> be the early boot feature is not supported by other entities. In this >> case, the state will be marked as RPROC_OFFLINE so that the PAS driver >> can load the firmware and start the remoteproc. >> >> Co-developed-by: Gokul Krishna Krishnakumar >> Signed-off-by: Gokul Krishna Krishnakumar >> Signed-off-by: Jingyi Wang > > Unfortunately, removing the ping-pong functionality that was present in > previous patch versions makes the whole mechanism a lot more fragile. > I'm not entirely sure if this has changed in SMP2P v2 or more recent > firmware versions, but in my experience the SMP2P "ready" bit does not > tell you if the remoteproc is actually running. The problem is that the > "ready" bit is asserted by the remoteproc when the firmware is ready, > but it is not cleared when you shutdown or forcibly stop the remoteproc. > > If this is still the case, you can easily reproduce that with the > following test: > > 1. Start the system as usual and let it attach the remoteproc > 2. Manually stop the remoteproc in sysfs (echo stop > state) > 3. modprobe -r qcom_q6v5_pas > 4. modprobe qcom_q6v5_pas > 5. If the "ready" bit is still set, the driver will try attaching the > remoteproc, but it's actually not running. No recovery will happen. > > In this situation, it is very difficult to detect the correct remoteproc > state without relying on an additional query mechanism like the > ping-pong feature. This a valid use case and concern. We had a discussion with Bjorn, and want to take this scenario into consideration of the separate robustness improvement series[1]. Stephan could you agree to have the basic function in this series can be go in firstly. [1] https://lore.kernel.org/all/20260519-rproc-attach-issue-v2-0-caa1eaf75081@oss.qualcomm.com/ > > You can make it a bit more reliable if you also check the status of the > "stop-ack" bit. This would tell you if the remoteproc was cleanly > stopped with the SMP2P "stop" mechanism. However, that will typically > still not fix the case above since nowadays remoteprocs are typically > stopped via the QMI qcom_sysmon and the "stop-ack" is not set in that > case. I believe this might set the separate "shutdown-ack" bit though > that is described for some SoCs, I never finished testing that. > > And even if you check both "stop-ack" and "shutdown-ack", that doesn't > tell you if the remoteproc was forcibly killed using > qcom_scm_pas_shutdown() without gracefully stopping it first. The ideal > solution would be querying the PAS API to tell us if the remoteproc is > actively running, but the last time I checked I was unfortunately not > able to find a documented call that would tell us that. It is a state currently kernel don't know whether the remoteproc is offline or crashed when ready==1 && error==0 && ping-pong==0 scenario. If it is re-modprob, the software don't have any data and only the firmware can tell us whether if it is active or not per my understanding. Maybe let's have this scenario and solution discussion in the other series I mentioned before. > > Thanks, > Stephan -- Thx and BRs, Aiqun(Maria) Yu