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 C660F480356 for ; Tue, 4 Aug 2026 16:51:44 +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=1785862309; cv=none; b=aXxP+Tic1UtNkgMjQWgiNI774SQXrYo8gG0qHzyCF8FEsps3Qy9C6gJKCG5xrtjrg+45+k0irdrjMffBaMOwzm4hYD/zv0lB231rboQjueMkf3OteUbAIaDObUiLb55O1vOH7rIcqVJN8A/F+Ck6JZ/PXrjzoXs4CxudxnW7o2Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785862309; c=relaxed/simple; bh=+0iaAebDZTu2n9MNDfpOO8xO2Pql0lKsfUHfy+zph+Y=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=OcZj8tt5bn00mzr0yWtBp9CVvUy500jxvHLm3DbY6UMxZV/SEb1W32yH18TdIB2EgT8KBX3vcYoOd0ymYy8bWOr7n004pSDP/rftDiKz1NpBMIP4KjD0JN7ulUfjXLZffD5OwcwgVfbALqY1LkoyzAP5kd0SwoqMutGJT3wpC7M= 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=USmE76bp; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=iy1fjyXd; 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="USmE76bp"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="iy1fjyXd" 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 674FfbdB133309 for ; Tue, 4 Aug 2026 16:51:40 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= HHenXeOrbWY/SXqKB8NPQYcUSj7j7mcQ5KUAGFCPsmY=; b=USmE76bpPNJK8Afy RPzOs/hbkq4Bu9+FeEHNf0bY9K7FOskdpOZXryrD6DSwvq9CTPY4el7gf/1gqtzc mkH95U5WJYCoNin3u4F1R17l1A6h1xJQ9Ic48LyuNLBA/8GDhs1JaOVuqnCkjtVF q5kLU6dAZACitTB6JjGFsrl0Z7Uzl5C9Is/YPJooXyOyjqsJXOFZw9ajT12Tcp1+ 15yK/NCWf1X2Zbh8r1zmdgL/bIikTlbRdrCqrERCPiWjcbSIGYjz6RNzpc7GWXow /LDMidhmjeImiWV6D4UskguKyUTQ4taYL+Q6tAA87jWvqYqaoLXtIO6C8Igh8pyF z2D+ig== Received: from mail-pg1-f197.google.com (mail-pg1-f197.google.com [209.85.215.197]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4fu1p8csf9-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Tue, 04 Aug 2026 16:51:39 +0000 (GMT) Received: by mail-pg1-f197.google.com with SMTP id 41be03b00d2f7-ca124bf0189so969045a12.0 for ; Tue, 04 Aug 2026 09:51:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1785862299; x=1786467099; darn=vger.kernel.org; h=content-transfer-encoding:content-type: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 :content-type; bh=HHenXeOrbWY/SXqKB8NPQYcUSj7j7mcQ5KUAGFCPsmY=; b=iy1fjyXdOS2r7xzUuw22SFRYP1jRkdlq/HtEt++bfOXRUuc5h9oRqal7t19rK2rEXe e3KJyFvAZsninL1W45FPbsLwjoolE++Ffi1XXR15G4rC7HEtTvdLYcRfqR+KikBLloVM 5/ZPFuHs0VrqleFnY/HGvdwnWSvpCn28COcHFzLhjbLyGZ2KGka9cTRWLI0RlkjycgqQ AnDAsIvBnhr4uchaFKt4mceo032dfM7BG+QcXOmBXqSmcBLdgSIFZeVC9AkK8mhkenMy fKmAXJe0sMdZwYr8Y5qKJL5nZNUYO7s9N5Raq5F4gVZ1CrXrK6J/h62UBDFZHoMNmDRI VkHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785862299; x=1786467099; h=content-transfer-encoding:content-type: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:content-type; bh=HHenXeOrbWY/SXqKB8NPQYcUSj7j7mcQ5KUAGFCPsmY=; b=hukAUNKEZ4Knmtk7xIosNqzIVcMIJnrtdbmwP7SHY4HivPw4jkJ2slY9DnZUyla8ZF kgv8mq+4bKMjoqF4X2OafkJrqgHp4lM1dUugppDV+K/FCnZaQZVnvPIl7OWrdlhcnv/B pjpqI35QH5GIha/A2t6LshAiehvtiA6Mycv8OEGFAol3R8hRn9mgZgNp1LS/vyOVp0QO aBwrDCUhejujqMF8bMbChWFrrZ4iXC1cqiDFJaopML0DK6FpmJy/F9Y1fk5mLuNZiBpI sUCIJQHFCQQU9ejzFaB4r9nelLihzgeAkEbWuPUxrfATtMwMeFEsxR6SxT8fjDW03gWm txzw== X-Forwarded-Encrypted: i=1; AHgh+RqfeELjbcOdfLxFP5vLJeqlK9jMgv1abIhmDrSEux6JkjYD4VRxGynpXjmBNabktFz++uwZ5sNTVK5xkrg=@vger.kernel.org X-Gm-Message-State: AOJu0YxGZS9y1RyDAnakazpN3rePR0SkbJfecLrE7Cq6nJA6ZEZlT9we JAtyeoh9ESQGegXv7zLlIVtJncSryAGSI+IE45/72KtLdWRv0hMvNedVLWFsgoSEZmYWy+/jAaA Zd2HF5bVgmWOzPudhMJWmILe83ceunQ+VZE/aCNejGDB11GftOKQxL1kzNRXyLr0kEN0= X-Gm-Gg: AR+sD13mPW4alWCtFvrZXBbJoF9Mom7n2/o0XIVVz5quPNhhR2hRFqNpEYAByrYSgAM PQMClW/cdvWiC4wIkqdN8T7bleOi9Pim66lf7yR3P5jLZu36+jwCp9brNGTY/IBcx0R8SyFWVt4 g3QBrMQQFadOHOzqWZ40KSJy9a2vUQignFg8qqoQ2NtAMHP+LqP8wBm8cqT0ea9rZvRHpXAFqCe bprRe5jE7jkVBb3e/zTD35PMlyUu67dNS9xlyde3oT1Ky+Xsy+LL9s/qHr2uLtxoZIPaOFWPexN voGetKxsrSTutXpZXl+l/kIukmGJki752QbkB920cRIt5acNUFX5Van8k+3xu1Uu7eoG+MKDWUj SvX3hmEvwuJs51zUHXdfFxvdSvjMYynnm1B8ypytWp4ZmnflXKaeVYA== X-Received: by 2002:a05:6a21:138e:b0:3b5:530d:d96d with SMTP id adf61e73a8af0-3cb859365b6mr531299637.12.1785862298699; Tue, 04 Aug 2026 09:51:38 -0700 (PDT) X-Received: by 2002:a05:6a21:138e:b0:3b5:530d:d96d with SMTP id adf61e73a8af0-3cb859365b6mr531229637.12.1785862297948; Tue, 04 Aug 2026 09:51:37 -0700 (PDT) Received: from [10.226.59.182] (i-global254.qualcomm.com. [199.106.103.254]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-13fca50ad27sm4971328c88.2.2026.08.04.09.51.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 04 Aug 2026 09:51:37 -0700 (PDT) Message-ID: <3ce8f794-3582-4d69-8b7d-1f7c10689a0b@oss.qualcomm.com> Date: Tue, 4 Aug 2026 10:51:35 -0600 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] bus: mhi: host: Flush the posted write after writing to MHI_SOC_RESET_REQ_OFFSET To: Manivannan Sadhasivam Cc: Manivannan Sadhasivam , mhi@lists.linux.dev, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, Alex Williamson References: <20260623145134.43976-1-manivannan.sadhasivam@oss.qualcomm.com> <6e2fda2f-ce14-4f81-b848-9fee4e6a221a@oss.qualcomm.com> Content-Language: en-US From: Jeff Hugo In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Authority-Analysis: v=2.4 cv=A5xc+aWG c=1 sm=1 tr=0 ts=6a72189b cx=c_pps a=rz3CxIlbcmazkYymdCej/Q==:117 a=JYp8KDb2vCoCEuGobkYCKw==:17 a=IkcTkHD0fZMA:10 a=Sv0fKeRqtYgA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=gowsoOTTUOVcmtlkKump:22 a=ZXrcf1LaNO3NQIdrEiYA:9 a=QEXdDO2ut3YA:10 a=bFCP_H2QrGi7Okbo017w:22 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODA0MDEzNiBTYWx0ZWRfX+hokn84DLhu3 i7rA61RVm2llYgbWpmdfIn8DVDumvLnDqyLRgxwihTLPRk+5DKSJ2rmE+2c2m/trbisXNXIL3bR oiCK4xVXMedUCq8FOAhaS9ixxUyQeF4Zg5D1mCHZ3lasCmsDumSnTiXRAZfQyQc1aGO5PmpkQq6 M224kY2bBEoS9dDyUMzYAUQhdb25fQ2VcsV1C29/c06Be5GTwWLewtqtU8ZnC8trPonooXXzXns Vu6l70SyS1fCtw9vhlx2V8aVmDwy4f72kSnMOguJ4Wt1UIP/GSekDOHFcPh/VfpDPsv8YvBA51A +DrJQfDX5rfuogGPGLLN9+7Ij5liQszTimsdI/6HnidZxB2PKCm0tdZwdVuCqMJNzS12N7+lyEy BmtapKZ9G5LhtMevmqty4PThVAv4cmCQ3TMGFjxJSx7u4c08EeOzsn5Q7rfYEGHzSuxYM/3IXiq HfP3d811mx3ESzJiH/w== X-Proofpoint-Spam-Info: AW1haW4tMjYwODA0MDEzNiBTYWx0ZWRfXz+jeF8hsf54T EvUWvU47qCf3hFRsBHGeTa65tP+cKazJPk/fsC/Q0gv2YCVQiIjLuGOyh+Y6o84/nz3mLC/dd4D n/4deWmQYzUMIr6q+L8idAx2TP1WRp8= X-Proofpoint-ORIG-GUID: W-wucAKLavEsMk0Gx79oHclf22EgTZD9 X-Proofpoint-GUID: W-wucAKLavEsMk0Gx79oHclf22EgTZD9 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-08-04_03,2026-08-04_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 malwarescore=0 priorityscore=1501 clxscore=1015 suspectscore=0 adultscore=0 bulkscore=0 spamscore=0 impostorscore=0 phishscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2608040136 On 8/3/2026 10:57 AM, Manivannan Sadhasivam wrote: > On Mon, Aug 03, 2026 at 09:57:47AM -0600, Jeff Hugo wrote: >> On 7/29/2026 11:19 PM, Manivannan Sadhasivam wrote: >>> On Wed, Jul 29, 2026 at 03:07:00PM -0600, Jeff Hugo wrote: >>>> On 6/23/2026 8:51 AM, Manivannan Sadhasivam wrote: >>>>> mhi_soc_reset() tries to reset the device by writing to the >>>>> MHI_SOC_RESET_REQ_OFFSET register. But it doesn't do a read-back to ensure >>>>> that the write gets flushed to the device before returning to the caller. >>>>> >>>>> This may lead to the delay (if implemented) on the caller to be >>>>> insufficient, if the posted write doesn't reach the device before the >>>>> delay. >>>> >>>> Interesting. Is the delay tight enough that a few ms will possibly blow it? >>>> Seems like a poorly defined delay. All the devices I'm familiar with take >>>> multiple seconds to boot (with some variability due to ddr training and >>>> thermal constraints), and if the reset triggers a crash dump, then its >>>> easily tens of seconds. >>>> >>> >>> Which delay you are referring to? RDDM delay which is just 2ms? Yeah, that seems >>> questionable. But this function itself doesn't implement any delay. So your >>> comment was somewhat confusing. >> >> The delay at the caller of the API referenced by the commit text - "This may >> lead to the delay on the caller to be insufficient" >> >> I looked at the thread referenced by this patch via the closes tag, and >> while I can follow the virtualization flow, I didn't get a good view on the >> specifics. >> >>>> Regardless, since this reset will either kill the pcie link, or disconnect >>>> the SoC from the link for a time, >>> >>> No, this will not reset the PCIe link AFAIK. PERST separation logic available in >>> the Endpoint should make sure the PCIe link is active while the SoC is >>> undergoing the reset. Otherwise, if the host tries to access the device config >>> space before the device is ready, it will blow up. >> >> Reset separation (PERST separation is one part of) is not always enabled. >> PBL won't enable it as it requires loading the reset sequences to the PMIC, >> which is outside the scope of ROM. So, if you have a non-flash boot device, >> or a flash boot device that has a non-provisioned/otherwise corrupt flash, >> the EP may be sitting in PBL from cold boot without reset separation >> enabled. If the EP is then passed to a VM per the related thread, a reset >> will occur, which will take the link down. >> >> Also, if I recall correctly, automotive products do not enable reset >> separation at all for ASIL reasons. >> > > Ok, I was not aware of these scenarios. > >> If the link is down, the upstream component of the EP should complete the >> read with an error, not cause the host to blow up. > > If the PCIe link is down and if the host tries to read the Endpoint config > space or BAR, most of the PCIe RC integrations in ARM64 platforms return AXI > error instead of the typical 'all-one' response and that causes 'Synchronous > Abort' on the host. And that's what I meant as 'blow up' as it will crash the > host kernel. This feels like a PCIe spec violation, or at-least undesired behavior from the user perspective. Maybe a DoS attack vector? I assume you are specifically talking about Qualcomm MSM Arm64 platforms, and not the entire Arm64 ecosystem? I don't recall seeing this in the Arm64 server space. Do we need to talk to Joe about this? > Anyhow, the motivation of this patch is to ensure that the posted write gets > flashed to the device before the delay. But I'm not sure on how one should > address the concern you raised on waiting till the Endpoint reboots. Sadly I think the user implementing the delay will need to be aware of the specific device they are using, and the likely required delay to account for the various scenarios that device implements. I don't think we really have the infrastructure to make this universal, and if we did, I'm not sure a blanket "all MHI devices reboot in X time" is going to work in the long term.