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 EBFEC2E1F06 for ; Thu, 2 Jul 2026 02:49:07 +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=1782960549; cv=none; b=DAAKvWIuem/Yo6f3EEaNAJ7IGid857eQum2P5eOcMyTTzTAa8SwQn4Eh6ntUYdLbo3PbBU7gNd9Llr06xNIS2bqIDNfrO7U39dBbSOppT0CC4DTPoZpU4G2q9CFgePrS1atkqCHpcKEBWp9GBnEVgYIPhS8Gk4zanceOT4CxRko= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782960549; c=relaxed/simple; bh=AfVlfqVRM83w/2+kbTyFI/v1InzBtt6aUMbIahCrumM=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Ut5XXJHJ3w/U/RuVPQT81/RSa7Rb4gRw+fJcJuylpV2SNYCkvVeo/hPKuLHSm7XIJ2i1v5jdQLGUjv5qP9UP5ciIqJPpIDjM/Hvyen4orJrAz/X1mX7YO/obIdlSghaJxqTWpK5Z2hM2s1gYbHwI6WvaVQYQudEdbH5otkpOh0w= 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=jC7nawt3; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=ek3w9Hgq; 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="jC7nawt3"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="ek3w9Hgq" Received: from pps.filterd (m0279863.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 6621KExF3053467 for ; Thu, 2 Jul 2026 02:49:07 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= lLaxFpS100Xk7qebtOIZC9YPDVj1gBjt4peUMTWselI=; b=jC7nawt3ScLwBbnz 1mG93i6dkmMbzsQWDwKKdnlTw0AdW/WgQuu/rUzq9LX+bXEZlrbCvfpyvngQ871o sDdmiVajT5W9WYS+RUkIPZu5h4W+XjC/YS5R7t6ilETgLK19lbSnf8TQq2yDnjpc ZHv4Wc2i3Fgp14QSgup0+BvY9bVBIXvPk3eYKad8QDqMvDz1hHcq25vEnuopa+NZ 8lhfTASdd52U2Rok3mzlSCM+WkJupIebo66YFnS2920l8cBooW6hdcwhb2OWAkCv 2EKQJY2HNFI/+pHYytx+ZO0Eg/GgKAtNurdqatHo3bcsxrwxwjmgW4JJ1Jbv8Kzw C60ZZg== Received: from mail-pl1-f200.google.com (mail-pl1-f200.google.com [209.85.214.200]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4f50sd3nj7-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Thu, 02 Jul 2026 02:49:06 +0000 (GMT) Received: by mail-pl1-f200.google.com with SMTP id d9443c01a7336-2ca0d4fb061so19621465ad.3 for ; Wed, 01 Jul 2026 19:49:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1782960546; x=1783565346; 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=lLaxFpS100Xk7qebtOIZC9YPDVj1gBjt4peUMTWselI=; b=ek3w9HgqditCgvpUq0gVVrASlLRFmHF0CYAWBxx3cO0riu4qfLM9pcVoPhB1IPL67z NEx348VR6u4iEU6DbnXhz8zwmOMgqvNilCzZv4SvCvgonZ0RaXc1Takg8AlJ5jO1iLmO ijofZTLHDH3TnTk+OHuMNxkhnoLzD+eLFOe6VJzRaNNe5kQJshCS3i/m1lB4QgA8uk8y kURGHsxLu4lVd4dYNhg1IzVa+p4iRs01HDxEWwQqb6KKgICpmmPcIZQSM2ZgBj6czZQe zwkJAhXROum/8ebeo7c1fRC3rqjEGDudjXwkC9sAg9DycYCG5v40BDxoX2P0K/qW6Gg2 Y3rQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782960546; x=1783565346; 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=lLaxFpS100Xk7qebtOIZC9YPDVj1gBjt4peUMTWselI=; b=d1TgA9EaLG1ULVLsxX9EiQa0Dd1/xSN0AY9e/jnO4uzVM6l2nIEWjecthQW2cJeF7b CdGr1RI+TahItag56zyHhyR1ajb71UbPeF3VbOCX3+1HwcwclohogLMOkjJaOquOZX04 GWixATP7Lb4Y/OUCQmWv26hfVOEjaGn/FwrLS6dnuaZoh/Se0n95sK+HqPPaCIl1SGW+ mdEIl+Ebd2wcsnn+Z+2G+rgSJbQ+bNsRNW30FaFUuQeBTs0gJGZj6f14s7XsMOl2dXKB iPDFTFkkc7Jz1PhrtxoU+9RzLpFkaArhAtzl+bTSUc8vwJLmH63mubrTgSnqAAUyRcDi X0QQ== X-Forwarded-Encrypted: i=1; AFNElJ90qHccCO9rM29ICt2ZB7/Q0qHwj/nS8YqqiHiai0orXNYdAnLyJNz4W3G24EeMqB3jyMhDFLu9pM3JiTY=@vger.kernel.org X-Gm-Message-State: AOJu0YxR2wf1gN6obuFJm6FklHPJiVqPQ6uT/EI0iSsWV3TP+SZJUVmV OpmXjLJ6LBwX+/egwp/6XvRjs3hM8GQDaKRAxl9N7WoyNNX7DjlgbG7FOHjdGfiCjXlw+JYzl9E +ssHxbaPQGZU78wFO8M3Kq5+DXiPfwFTqX0EVg6rG6iNmZX56Z8g8AC2n1eV3yDv3YZI= X-Gm-Gg: AfdE7ckxENxR5M7wnNWuOgFFQbHEQtACRgTIXDbxmOjUlVPZ5OzYlTqmsoiEcyq0AR4 mQTHHTrg209y5j/GdqmDlZgr7JjibSCzcnKLeKDa30kJ6IRJJkO8dwhT033tgOARd/1S9pYBq2l 54j2Fdm7NG1JWGZxic/AEKB4mPDIzLdxCDl19WlE40a6vO0JpXWskWJVw5/3v0Mrnjv5MzS9EDt aljaMH3PYTrVRb+db/yJMvVcUz2Xd0hbgPqkcpvPH2QKNdtCrA4ldw9gAfoYpTsqnRmCy9Ehqdu HqmHyCgiDVWJOfXK9USnvIqWL1pMTHA9e61sMdjrpX5ibCpJvDOEa6lLJfMspPJEbZV7A2Nu7E9 3v/C2fZzUS7gebQ9a3JTLLlEXpSqva/EXyjYdXe+B1Nw= X-Received: by 2002:a05:6a21:696:b0:3b2:a8cd:ef4e with SMTP id adf61e73a8af0-3bfed3b2776mr4936148637.28.1782960546021; Wed, 01 Jul 2026 19:49:06 -0700 (PDT) X-Received: by 2002:a05:6a21:696:b0:3b2:a8cd:ef4e with SMTP id adf61e73a8af0-3bfed3b2776mr4936097637.28.1782960545007; Wed, 01 Jul 2026 19:49:05 -0700 (PDT) Received: from [192.168.0.4] ([49.204.106.248]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-30f0bbdc544sm3802085eec.25.2026.07.01.19.49.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 01 Jul 2026 19:49:04 -0700 (PDT) Message-ID: <4fa2a2ef-90ec-4f06-8611-c508ce0bbec8@oss.qualcomm.com> Date: Thu, 2 Jul 2026 08:18:57 +0530 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] serial: qcom-geni: add force suspend/resume to system sleep callbacks To: Mukesh Savaliya , Greg Kroah-Hartman , Jiri Slaby , bjorn.andersson@oss.qualcomm.com, Konrad Dybcio Cc: aniket.randive@oss.qualcomm.com, chandana.chiluveru@oss.qualcomm.com, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org References: <20260701-add_force_suspend_resume_to_system_sleep_callbacks-v1-1-38c9a721a462@oss.qualcomm.com> <73243e36-175c-4fe3-a448-b30eef9c44ee@oss.qualcomm.com> Content-Language: en-US From: Praveen Talari In-Reply-To: <73243e36-175c-4fe3-a448-b30eef9c44ee@oss.qualcomm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Authority-Analysis: v=2.4 cv=Z+3c2nRA c=1 sm=1 tr=0 ts=6a45d1a3 cx=c_pps a=IZJwPbhc+fLeJZngyXXI0A==:117 a=ZY8+d+ilh5AZ8AQMB2/tOA==:17 a=IkcTkHD0fZMA:10 a=RAioF0-LDSMA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=yOCtJkima9RkubShWh1s:22 a=EUspDBNiAAAA:8 a=1ym4DecIM8o6dCVoxpoA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=uG9DUKGECoFWVXl0Dc02:22 X-Proofpoint-ORIG-GUID: 2it1etJVveu6tcpdPZCB3gjWxG3A4zVX X-Proofpoint-Spam-Info: AW1haW4tMjYwNzAyMDAyNSBTYWx0ZWRfX64LfGheULxWG ztKViRPbTYhiNM0ZmbsHPNjmaPgQuWVbCbyDQztgvvYUxvdT3YAmMGS8F77gT2935nvLKBL/FH9 BXyBMsWQg7ipPMTek+RR/r3CTtSM41E= X-Proofpoint-GUID: 2it1etJVveu6tcpdPZCB3gjWxG3A4zVX X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwNzAyMDAyNSBTYWx0ZWRfX3/mY969JFmX3 xpSkSki7xOsD+jxRVtP/nJxM2jBX+xYyKu9Ml+O6MA5XH9tC2O4uuJeLulbqrIsoc2rPmw2SSvH XBAUDYP6LupyfPy6s//OkJHf3VeROYKACCUl2eT0ux89cTCLy8MdkejCoxLlruV0tS7qtcExY6n /At+v9didLFwLlkmuSSPQt9gpMJwaI6+rtl+XHYrxjpyoNAyMH7FIqvGzNoIPLwEh+/3g2CEY9t 5kqyrwgGJtYMVjZwmoYcTwdq3RilfrKXsQRIVCM4mSL2bWZxdATxK7iccNh8CQZUkFWjGmccLvt uysfBPLvNgBXr+a0C2+zrSUPnfMFsTB/0TO1l6jbRChZT+ZFYmc2Je+rTtLbIz62/fCiVp4+6bR 6CE18Xgn0NjKQb3aS1XsgG3WmVyrHeDZVO+IG4HBGDoalwMuL7W98fSKS3xsIrd2uX39tQJJfq4 EyNA/bF7tkc8E473K/A== 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-07-02_01,2026-06-26_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 suspectscore=0 adultscore=0 priorityscore=1501 spamscore=0 phishscore=0 impostorscore=0 malwarescore=0 lowpriorityscore=0 clxscore=1015 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2607020025 HI Mukesh On 01-07-2026 20:47, Mukesh Savaliya wrote: > > > On 7/1/2026 11:27 AM, Praveen Talari wrote: >> During system sleep the hardware resources (clocks, interconnect) are >> not gated because the runtime-suspend callback is never invoked from >> the system sleep path.  This prevents the platform from reaching its >> lowest idle state. >> >> The system sleep callbacks qcom_geni_serial_suspend() and >> qcom_geni_serial_resume() rely solely on uart_suspend_port() / >> uart_resume_port() to manage power.  uart_suspend_port() drives the >> UART PM state machine to UART_PM_STATE_OFF, which in turn calls >> pm_runtime_put_sync() and eventually the runtime-suspend callback. >> However, if the runtime-PM usage count is still elevated at the time >> of system sleep (e.g. the port is held active by an open file >> descriptor), the runtime-suspend callback is never invoked and the >> hardware resources (clocks, interconnect) remain enabled across >> suspend, preventing the platform from reaching its lowest idle state. >> >> Fix this by calling pm_runtime_force_suspend() at the end of >> qcom_geni_serial_suspend() so that the runtime-suspend callback is >> always executed regardless of the usage count, and by calling >> pm_runtime_force_resume() at the start of qcom_geni_serial_resume() >> to restore those resources before uart_resume_port() re-opens the >> port. >> >> Signed-off-by: Praveen Talari >> --- > [...] >> @@ -1963,7 +1964,19 @@ static int qcom_geni_serial_suspend(struct >> device *dev) >>           geni_icc_set_tag(&port->se, QCOM_ICC_TAG_ACTIVE_ONLY); >>           geni_icc_set_bw(&port->se); >>       } >> -    return uart_suspend_port(private_data->drv, uport); >> + >> +    ret = uart_suspend_port(private_data->drv, uport); >> +    if (ret) >> +        return ret; >> + >> +    /* >> +     * When no_console_suspend is set the console must remain active >> +     * across system sleep, so skip the force suspend path. >> +     */ >> +    if (uart_console(uport) && !uport->suspended) >> +        return 0; > Rather use console_suspend_enabled and take action to go force suspend. In uart_suspend_port(), uport->suspended is updated only after the console_suspend_enabled check. Therefore, its value directly reflects whether the console suspend path was taken: uport->suspended == 0 → the console was not suspended. uport->suspended == 1 → the console was suspended. Looking at the code below, when console_suspend_enabled is disabled for a console port, the function returns before setting uport->suspended = 1. As a result, uport->suspended remains 0, which accurately indicates that the console was not suspended. Therefore, I believe using uport->suspended is the more appropriate check here. Please let me know your thoughts. Code snippet from core layer int uart_suspend_port(struct uart_driver *drv, struct uart_port *uport) { [...]     /*      * Nothing to do if the console is not suspending      * except stop_rx to prevent any asynchronous data      * over RX line. However ensure that we will be      * able to Re-start_rx later.      */     if (!console_suspend_enabled && uart_console(uport)) {         if (uport->ops->start_rx) {             guard(uart_port_lock_irq)(uport);             uport->ops->stop_rx(uport);         }         device_set_awake_path(uport->dev);         return 0;     }     uport->suspended = 1;     if (tty_port_initialized(port)) { [...] } > Here, it sounds opposite, if port is resumed, you don't go to suspend > within suspend function. It is straightforward: uport->suspended remains 0 even after uart_suspend_port() is called, which indicates that the console has not been suspended. >> + >> +    return pm_runtime_force_suspend(dev); > Is this really required ? if  uart_suspend_port() successful, what > will happen with this ? Yes, this is covered in the commit message. The key point is that uart_suspend_port() may not trigger the runtime suspend callback if the runtime-PM usage count remains non-zero. In such cases, pm_runtime_force_suspend() is needed to ensure that the hardware resources are properly suspended during system sleep like our i2c/spi supported. Thanks, Praveen Talari > >>   } > [...] > >