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 11A2C37C939 for ; Tue, 2 Jun 2026 07:49:24 +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=1780386567; cv=none; b=PX78CO4RA3wDLK2QavaHfKFkDjb0JyLr6pc1Cvjq1tfbxp5UjK6AubzYlT9aHpnf0T/nn1VaSB7VhgRnOS2NgxygXtbQBMRw5lUK72EB8lwE89oJkbZFu59bzVI3ETFynoymjsgEqI4ivZ4QXROdrYtFN4SNbfeN58bMYY9FFgs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780386567; c=relaxed/simple; bh=MBYrlWGRXUhaChKy3GOMO8jIKccnmzMEQbiqE/azJzY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=UiKjaDLll9TqjV4ojfR42bubEzi/OYs1RPn/V1c4nJDEwexbiA/mv+J7Dn5pkGa3+UdDa4ERqsq2cT6Luy+mKZ6U6OYUrR9BpobA8thvjjrNgTTHcyFYqYw/gvTGuOpYCq4714JzJ42bjZ69mIzYxas1lIDNjO7uzD0V/0i70dE= 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=hCe3oWOn; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=ajZBnv5L; 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="hCe3oWOn"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="ajZBnv5L" Received: from pps.filterd (m0279869.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 6527hE5Y1639577 for ; Tue, 2 Jun 2026 07:49:24 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= YDdEChdOuz5vhEBHofl90s3kNaFQdp9Q/jmTxWEH9Y8=; b=hCe3oWOnqcgVGRAJ +9IhOdG/zNmP0uBHEFnV47ire3nAm5RQYKytuot9eQqsLCg/nbEEJMSMdhL96/Ze i984VghdAbeaa3FQ6GdKVPRaBjmL3zcRWmz6hCHEz9nBtK/nuJSi9RzybcKqef0Q THbj5dq4jK9lFStY0xZeFttexOFkFireeLGzELITAfmz7JQu+opP2l0QznO+KSOu vKISd+DOMhigXFI8dScEzlfxC50tSw39kKtyZr4OzhpyB2WC8eLg7DkArifVmizl 6z1oCW6VWXn2pVmD/hWh/n9cOVr3CrWE4hNy8H7oH8cZn1AKrzxEQ83kem9ig959 ufusfw== Received: from mail-pl1-f198.google.com (mail-pl1-f198.google.com [209.85.214.198]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4ehu1cg0vh-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Tue, 02 Jun 2026 07:49:23 +0000 (GMT) Received: by mail-pl1-f198.google.com with SMTP id d9443c01a7336-2c0c36f4b76so23532935ad.3 for ; Tue, 02 Jun 2026 00:49:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1780386563; x=1780991363; 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=YDdEChdOuz5vhEBHofl90s3kNaFQdp9Q/jmTxWEH9Y8=; b=ajZBnv5LYMviMbKN4mGfxhuu/Jqh6qPR3butO3qB8/W94LX4bsXBe9olyoYj3k1E3R RLEUR3Mw0IGVz9h0YiPxtVsZ/0FLi9w5frzl8cBkvTUDfSN0hswJU8RNS+pm9HqU2TTT e1qDaUzvoawsx/L6qYa5LWIjQ/LjjOIQI1vE3P7chh1lDZXAZu3QPh+iEiWnkSHEu8sn Ij6ST5H+MLIyZn3bmUPQ/xtozq4DrBpJRKK9+MKMEGpjHlrZuJP38vKU9YSI71qd4pcr nbtNTTFtZrK4o+3yFe0BVJR52IFoBlpio9Gu+PhQckobwTPnRsTYTuFNUBjazNdyiPgm n3Qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780386563; x=1780991363; 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=YDdEChdOuz5vhEBHofl90s3kNaFQdp9Q/jmTxWEH9Y8=; b=WId01+mUZWLSkh2+QDnkUcF1qcg7LMIDdDxvWUELU6NCVXwaGrK0UMN/6QOt25LevN gPZ+qRvP3aN6+9dY5aclYBuMYbqDAs8KLe4E8umY/xXqhxpcHX8YoJlz1JvZTuVwmBrT l3ngSawcCtV1n8/9Mcn7XfhkJjnIClLoPZ7cvxJXjfGJkwjYpjSRoQ/ycA5qwb6VTzOM EVKnvG5LTIf3XnU0ZgChC2zZGcEXNpvL+v8hyIdhOgVJ1qzAnq0Snht9JzcYH93Qs5nB cAgHS4V7df6/3q3yVOl6J7Mkt5JfCPlV+r7La5L8Lp19RPxk/F28Xg5Sr4lS/0gwmdR2 fQHg== X-Forwarded-Encrypted: i=1; AFNElJ/hchuAq+Qp3Z12zO95wZhVSyPZO5hrpTGAyPm3lzS4ySq1sHkJf0oXQuQZzkl6RurfWFeMeRe1r2fYPhw=@vger.kernel.org X-Gm-Message-State: AOJu0Yw+7+/2E1iJWm1efxg/hG4Yf1H9RVKcJCCAU71nzuEkONDA2b+2 3yAVCXgy+boTx89yQK3yp6kTMhPbWx9qeIIZdo/2w8e0FjzbLg2C3+V6EthWNiRIEIGN9bjvcD7 N9GSk6Oz2IZYduiq/T66El3e1hyE+B6aZl5bZTcT3b/iQ3uPRpia3L6q4I/Qx45Po2g8= X-Gm-Gg: Acq92OFNDE6BokmwhhqFsbfebX7IrzjNeL/kW/ngsGYqO+e7a3cYm8gNkHu61JZv/g5 RH52mGeL7hV0PKmgGQDYSjI68cJu4tBnNfP1gAzoMZkLFBnMyPZf+9p18c0qblkGnoBjw7C3F+A fR5oChZfJ0Z5gHJO7gwxXdxFNVlXJ12qGub8qRjIY8CsuI3kVSc68VZdjrX5siVQ/zAoDo8HlTC EFhtH7KSYudI3pwPZ2Y9RlUx2xAuoIddI4Zqb3wXiy9c1p50R5cihdft0Itb7vRJQF7u99TIUlX xoW0o8DJ4Cm2rlAzHu0N69dg4KHixs2X4NSkV4LMjcQRlxCSwGCR2eF83JOXQc6EUlA+M4HS6Ig nt5R0fvU9m3oRMa2mXI51vWWm7PSSCMxWm+Ksr/XXKhd2Oik9GJUfSTWw1XIK+m3gpZqQg9F/vp m7NyJGUpRpjg70F7AfmStQRc6vSg== X-Received: by 2002:a17:903:2d1:b0:2c0:e5ee:f56c with SMTP id d9443c01a7336-2c0e5eef815mr76947075ad.20.1780386562808; Tue, 02 Jun 2026 00:49:22 -0700 (PDT) X-Received: by 2002:a17:903:2d1:b0:2c0:e5ee:f56c with SMTP id d9443c01a7336-2c0e5eef815mr76946845ad.20.1780386562337; Tue, 02 Jun 2026 00:49:22 -0700 (PDT) Received: from [10.133.33.72] (tpe-colo-wan-fw-bordernet.qualcomm.com. [103.229.16.4]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2bf23b011d3sm128255215ad.52.2026.06.02.00.49.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Jun 2026 00:49:21 -0700 (PDT) Message-ID: Date: Tue, 2 Jun 2026 15:49:16 +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 , Bjorn Andersson , shengchao.guo@oss.qualcomm.com Cc: Mathieu Poirier , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Manivannan Sadhasivam , Luca Weiss , Bartosz Golaszewski , Konrad Dybcio , aiqun.yu@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: Jingyi Wang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Proofpoint-ORIG-GUID: AR-LmN4YnyB58l1ltPB4F6CXJ-RxP52V X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwNjAyMDA3MCBTYWx0ZWRfX76thA4qPQYbx Tgvv/xgh0RRhov/zDtJJy1MmWWj0sNGv8AsMxVsGv0xL0fVCsIsDzpGizgn6+UksTIU52PIkGGq jMZjmiDo3UeinWa7YZqrA4eq0lJB2BsLieWZiq/KebIPaOVB0n7JWqhvo6n7/G2Xb1kCfpvsoCL J9YaXn2LnMQc7W3N0WM7fDgKdOU0stJVzywtcQTnyGjHx/mlI+z1Q5vY84bKLlX2jGH7eBIWzQq /UtUgqNYtF+0nA74oJe5xfBFf4XXthMBto/DImI8ioRjDNEOLGVhHjdMXFvq5o0HNCvYyGUbhpT ZmbB0RacPo+nbr4RCZWc6711XMJA/t3CZexmSiKH6Xc8+SXGfxgq0h4kZYyaClMxvkJUCahUYwn erbLIIUDYHBmiOVxCDryCgghkkXKdq7n4dWO9YzydBOSlKPs6zEud7SRAHKgeEj8i0o6Yiv/EED 4OYHqzgYMCPV6cAedpw== X-Proofpoint-GUID: AR-LmN4YnyB58l1ltPB4F6CXJ-RxP52V X-Authority-Analysis: v=2.4 cv=O6IJeh9W c=1 sm=1 tr=0 ts=6a1e8b03 cx=c_pps a=MTSHoo12Qbhz2p7MsH1ifg==:117 a=nuhDOHQX5FNHPW3J6Bj6AA==:17 a=IkcTkHD0fZMA:10 a=FelO9ux0wxsA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=_glEPmIy2e8OvE2BGh3C:22 a=EUspDBNiAAAA:8 a=sGMcLsgT0xZ_I58ti9EA:9 a=QEXdDO2ut3YA:10 a=GvdueXVYPmCkWapjIL-Q:22 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-01_07,2026-05-28_03,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1015 suspectscore=0 bulkscore=0 malwarescore=0 lowpriorityscore=0 impostorscore=0 spamscore=0 adultscore=0 phishscore=0 priorityscore=1501 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2605210000 definitions=main-2606020070 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. > Indeed, I did a local test on Kaanapali, ready bit is not cleared and it will be taken as attached wrongly. +Bjorn, do you think this would be a valid case for adding ping-pong back? I have another concern that, if we add ping-pong test, when ping-pong failed, shall we take remoteproc as crashed or offline? > 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 > sha() 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. I also didn't find PAS API that can tell this, I guess this is why "ready bit" detect is introduced. Thanks, Jingyi > > Thanks, > Stephan