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 3967E2777FC for ; Tue, 3 Feb 2026 06:08:33 +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=1770098914; cv=none; b=OY8vR4xIC9dH5CbJvdtLrQm0SuO5yr2ONSvfZe81xC/cE2uuMYsobfq7+AmNKJdUyX4BDnszd8QhofcbzH4oxThS/r16FL9mllIUkKaLg/Kl4wlrBUmyVP9SHT2ITGO7/8xOXRaaCGtFuXDTPK55kDelU6uUN1N4nbSPUGRKgHk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770098914; c=relaxed/simple; bh=LN2IPck5ov//X45fmqxY5ixODOZQWmsjo8+ZE9Gl6AI=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=tzcu26dQa7vvPEYu6lZjtQJ3jDjsc8imwM1IryL6+gBkV+VvPMDu7XTXnR1GEw5wekN0EG87JMMi+eqqoqOU/1hGmkLux6/Ns2/55p78YyVad1xJbx/b00a1tEZMwAMTEMOjmIMupRu8PRItzi1R8MSk9bmDdHP584WpyWk+3ZA= 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=LWJWqfEB; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=dlrvfjWT; 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="LWJWqfEB"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="dlrvfjWT" Received: from pps.filterd (m0279872.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 6135VvKC2900116 for ; Tue, 3 Feb 2026 06:08:32 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= HtU0/hpdAIr+5h98ci3yTrohfWUAYAgRPyNrKyEhN+4=; b=LWJWqfEBUonRqOoB 8bH319KfLWL1MlRAZhGcaLoW/qkZI7XRaLcaDj3lRQe5I7LHX57YZzdrUn4pNui4 g9CXt4L6AgNXt6g+pIaTrZnP/LtQSXKORcLFJkGv8bgo+OgdOf8zQfyVapiA9s/i 55EAsHQYv275LVyAzPXCwr3tV+iAcJmP/zshw5e5o+FX3jM/KGTbZPQnLbC4EEz3 iBfbhZoJx/yGHQLpXUBrrSPYFpuiAFeq5hll3OLso3p30jy8EJKdzQUmAf0WMVK2 xNBieaon/0FKUz1tkEy/tp0oDe0TdcP8hqWF7h0x/2wGU3llXV3KNbp1Ed3scZ/s xQ/mMw== Received: from mail-pg1-f199.google.com (mail-pg1-f199.google.com [209.85.215.199]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4c2tp0u3bh-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Tue, 03 Feb 2026 06:08:32 +0000 (GMT) Received: by mail-pg1-f199.google.com with SMTP id 41be03b00d2f7-c54e81eeab9so3648591a12.3 for ; Mon, 02 Feb 2026 22:08:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1770098911; x=1770703711; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=HtU0/hpdAIr+5h98ci3yTrohfWUAYAgRPyNrKyEhN+4=; b=dlrvfjWTjoWqlx9CH5sRfsWUOm7WlqF3YD/3dHVkdXiZwwjtx5x3WxvriRedxi411j a57kG1zsrYu8PZ76EE+gfIYsWmbT9iZ+t12JnWO0HMscMDkywt5grY3+t2sbLo8p2DcL j+8eNEq8mOwc61wSoF7n3wpuZ0YY41ajbri/OAUJbs/8p+XBg7aPDl9Rl854tYRhTra7 SdDhYrs/ZCcYy2tqX9OOYZ3qLcaugbwi33PbvM8qAJLtNvLyQ4eqN8ItTJ23nXzAE1oc OFCA76e5ZpEEORl2VtIpjv6t2L4hK2hyesVvYZpdjEWygfQofB1vwY8f6zt9+Ee9fbVw N3mA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770098911; x=1770703711; h=content-transfer-encoding:in-reply-to:content-language:from :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=HtU0/hpdAIr+5h98ci3yTrohfWUAYAgRPyNrKyEhN+4=; b=RLWBGX3g05buIxMWCqGpirWXNmgXg/WXDTtUTSO03kj2tiRMLlDC/UdHhY50LSyJ+h aPCktGuzTqfWOYlhxCp+Z6jwoEYYTtitHYneavn82flbtz4Wm9R9M+fdZ44xRGytXvyt CCnwF+sqoBrrpV9Ck6LDN4h693/Mympf3XWUeZRg3bEjUkZzXuAkN/knPTvKPtCUHGs6 k76IfgMQDfEfrg0lk+3vC9SWvgZaY8ewCvScEsjYy5xq4ROOwUzjdxf/Xzuc1COmphmH YlGBPNByKRU5wRCCnfhX1LQAb1F3hfa46+63dM6WPCZNcu10vV1aWcOkDhH9TXehvWYe YRIg== X-Forwarded-Encrypted: i=1; AJvYcCVOeDpjZrISSzKKoOnQyoKGR+bW/vE9yqlSzPQGJSJcnAFtIvhPCf3e2VxyJJU3vcEqJTAk9nzHe8vEGJ0=@vger.kernel.org X-Gm-Message-State: AOJu0YxNQsKgM0L1TICHy7J+oe3d7Al5tqi72RWwMf2JgHOlrdT5rDI4 Cmit52dE73HtoQZRFxUfvR+NWfY7XiMLbdvu3zVwIRLTzmd/+9nvwAGmDGQ2ykIB6bPuIDo+GUc 5lOH16jHXPzyIVZt5A2Awsq6VxlkipTnzbJ2M7scT2T1fAS20oAK6QhkylD2hXzj30CA= X-Gm-Gg: AZuq6aLzpQgYk76sd21O4UfnFyJlVpeK5xRcLzVbJW1jZgUXl2eJZlMliNhp3aXn9Hm WJrAFQx4h4EoVgAIVMYvP7NGEad7DQnM4mQzD6Yt4qVvJ3U9wg4PlhpahU/jhTLuozJeOfQXFTq 60loVTPvCZ4Gh7fqb+uomhBg90ILnmXPTUYjPOQXx14ShMHZkQM+uHa4ch2+BgXhdapXCNIh7yf X1Vxrbt5xi9dqrB2YaBiOuihMzAUfa4dXMbKJYsX3+KXdhWYA1fLBERpoW2TGzGa/WM1TqtVcCl WtzFo2yXtA9UVf0zzjDbbWjaYPkrxIJlibhUI9rvcjwyLqb94ubKxP2HEHE3ptgaLZcz7oubhve A07VKa962eZPNuNatWt7BUdKQQV8yeoKAygdUXHRUOc/CqzS1dU97JszgdUpCxCemePfg4gaTKP H/x7WLuA== X-Received: by 2002:a05:6a20:a122:b0:38b:e944:3e98 with SMTP id adf61e73a8af0-392e0000568mr13670089637.5.1770098911302; Mon, 02 Feb 2026 22:08:31 -0800 (PST) X-Received: by 2002:a05:6a20:a122:b0:38b:e944:3e98 with SMTP id adf61e73a8af0-392e0000568mr13670071637.5.1770098910836; Mon, 02 Feb 2026 22:08:30 -0800 (PST) Received: from [10.133.33.43] (tpe-colo-wan-fw-bordernet.qualcomm.com. [103.229.16.4]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-c642a3359f4sm15788615a12.22.2026.02.02.22.08.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Feb 2026 22:08:30 -0800 (PST) Message-ID: <547a2c5c-fa11-4110-ae6f-17c12d6809f2@oss.qualcomm.com> Date: Tue, 3 Feb 2026 14:08:24 +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] wifi: ath12k: fix CMA error and MHI state mismatch during resume To: Jayasaikiran Banigallapati , Baochen Qiang , jjohnson@kernel.org, kvalo@kernel.org Cc: linux-wireless@vger.kernel.org, ath12k@lists.infradead.org, linux-kernel@vger.kernel.org References: <20260202151720.49904-1-bjsaikiran@gmail.com> <125f0ecb-79a5-4806-aa93-aecaf937885e@oss.qualcomm.com> <399d4ea0-5f70-4678-b0d6-9a80c3399ceb@gmail.com> From: Baochen Qiang Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Proofpoint-ORIG-GUID: --ROTe5HfXnqo9enJAXwdIdLJzcS7JnS X-Authority-Analysis: v=2.4 cv=VJ/QXtPX c=1 sm=1 tr=0 ts=698190e0 cx=c_pps a=Oh5Dbbf/trHjhBongsHeRQ==:117 a=nuhDOHQX5FNHPW3J6Bj6AA==:17 a=IkcTkHD0fZMA:10 a=HzLeVaNsDn8A:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=2ZLfKyb1yGKDWJBy5BIA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=_Vgx9l1VpLgwpw_dHYaR:22 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMjAzMDA0NyBTYWx0ZWRfX+E7mAzOyfnYt rJ/Po0oWfXx2qdkkywHehCmS1tCKdOJb8JO5LBXPgaa7gUUc8ytfJ6E1to40FPZAaZxs4Gposa4 LxoFYgJrqNB+AC2Mzk++iI3BA0mzLiIDsbKKy7pvgqHA5Ey4SVIsPBfChota8XdOxbHp64UXcJE Gpz1QjrKQ6w09h9ULY6tCe0ZBGvwnC2+qDW7DGM498E35FzLwvDxbsNZ7IzbleqBha8Zsqwg9mK 1PbDG3+50zTIGwG7+iPrG/z9CI8F8491rvoZpCb1Rh/oLUqJDlRxAjg5ki9DyP/9+HR5p8stfEw Qt7Gt9B2lhwGeMtDO9ws5LAI2duGvqyXzbc7Cg8t85CJudlXezbMIK7DdNRw5ax5Bp4VAKSJl95 7ix2uq7fRt7u7z0AtkpqGeF3ZDkIvCosFGbJ1Nfz6CLj5ySzFqRWpmrLybXAJmeMG+032WHJHaW nvabG071VKQk1s0ojkw== X-Proofpoint-GUID: --ROTe5HfXnqo9enJAXwdIdLJzcS7JnS X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1121,Hydra:6.1.51,FMLib:17.12.100.49 definitions=2026-02-03_01,2026-02-02_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 adultscore=0 malwarescore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 phishscore=0 priorityscore=1501 impostorscore=0 suspectscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2601150000 definitions=main-2602030047 On 2/3/2026 1:51 PM, Jayasaikiran Banigallapati wrote: > > On 2/3/26 11:00, Baochen Qiang wrote: >> >> On 2/3/2026 1:02 PM, Jayasaikiran Banigallapati wrote: >>> On 2/3/26 08:21, Baochen Qiang wrote: >>>> On 2/2/2026 11:17 PM, Saikiran wrote: >>>>> Commit 8d5f4da8d70b ("wifi: ath12k: support suspend/resume") introduced >>>>> system suspend/resume support but caused a critical regression where >>>>> CMA pages are corrupted during resume. >>>>> >>>>> 1. CMA page corruption: >>>>>      Calling mhi_unprepare_after_power_down() during suspend (via >>>>>      ATH12K_MHI_DEINIT) prematurely frees the fbc_image and rddm_image >>>>>      DMA buffers. When these pages are accessed during resume, the kernel >>>>>      detects corruption (Bad page state). >>>> How, FBC image and RDDM image get re-allocated at resume, no? >>>> >>>> To clarify, the BUG: Bad page state crash actually occurs during the suspend phase, >>>> specifically when ath12k_mhi_stop() calls mhi_unprepare_after_power_down(). >>>> >>>> The stack trace shows the panic happens inside mhi_free_bhie_table() while trying to >>>> free the pages: >>>> >>>>   mhi_free_bhie_table+0x50/0xa0 [mhi] >>>>   mhi_unprepare_after_power_down+0x30/0x70 [mhi] >>>>   ath12k_mhi_stop+0xf8/0x210 [ath12k] >>>>   ath12k_core_suspend_late+0x94/0xc0 [ath12k] >>>> >>>> The kernel reports nonzero _refcount when attempting to free the CMA pages (fbc_image/ >>>> rddm_image). This suggests that something is still holding a reference to these pages >>>> when DEINIT attempts to free them, causing the kernel to panic before we reach the >>>> resume stage. >> this seems like a bug either in MHI stack or in kernel DMA/MM subsystems, rather than in >> ath12k >> >>>> Since the pages cannot be safely freed during suspend, skipping DEINIT (and using >>>> MHI_POWER_OFF_KEEP_DEV) avoids this invalid free operation. This also aligns with the >>>> existing comment in ath12k_mhi_stop which suggests using mhi_power_down_keep_dev() for >>>> suspend. >> first of all, this is a workaround rather than fix. Ideally we should try to root cause >> the issue and fix it in the right way. > > > The original comment in existing code: > > > /* During suspend we need to use mhi_power_down_keep_dev() >  * workaround, otherwise ath12k_core_resume() will timeout >  * during resume. >  */ > > This patch aligns the code with this existing intent. The driver was previously > > calling DEINIT (and freeing resources) despite the comment advising to use keep_dev. > > If the intention of the driver authors was to use keep_dev for suspend, > > then my understanding is DEINIT is incorrect here (Correct me if I am wrong) > > regardless of the underlying MM behavior. keep_dev means not to destroy the mhi_device instance while going to suspend. The purpose is to get rid of the PROBE_DEFER problem in MHI during resume. You may want to check the upstream discussion to learn about the history. > >> >> Secondly the workaround here seems problematic: you skip INIT druing resume. However note >> several hardware registers need to be re-programmed during this stage, how could the >> target work if its power is cutoff during suspend and the register context is not restored >> during resume? > > > In my testing, WiFi functionality was fully restored after resume. > > The device associates and passes traffic immediately. I can imagine two reasons: either WLAN target's power is not cutoff during suspend, or you did not get into the issue scenario. For the latter, I mean you may need to trigger a firmware crash to see if RDDM works normally, since you skip RDDM register context restore during resume. > > My understanding is that: > > ATH12K_MHI_INIT primarily handles host memory allocation (which we preserved by skipping > DEINIT). In addition to memory allocation, there is also register programming. See mhi_prepare_for_power_up() and mhi_rddm_prepare(). > > ATH12K_MHI_POWER_ON calls mhi_sync_power_up(). This function triggers the MHI state machine, > > which handles the necessary BHI/BHIE programming and firmware download (SBL) sequence. > > Since mhi_sync_power_up() is still called during resume, the target is correctly re- > initialized and > > registers are programmed, even if we skip the redundant host memory allocation step (INIT). > > Thanks & Regards, > Saikiran >