drivers/net/wwan/t7xx/t7xx_pci.c | 3 +++ 1 file changed, 3 insertions(+)
SAP (Service Access Point) suspend occasionally times out with error
-110 (ETIMEDOUT), followed by modem port errors and complete modem
failure requiring a system reboot to recover.
Error symptoms:
mtk_t7xx 0000:72:00.0: [PM] SAP suspend error: -110
mtk_t7xx 0000:72:00.0: can't suspend (...returned -110)
mtk_t7xx 0000:07:00.0: Failed to send skb: -22
mtk_t7xx 0000:07:00.0: Write error on MBIM port, -22
The modem firmware needs time after receiving the MD (modem) suspend
request to complete internal operations before it is ready to accept
the SAP suspend request. Without this delay, if runtime PM attempts
to suspend while the firmware is busy, the SAP suspend command times
out, leaving the modem in an unrecoverable state.
Root cause and userspace interaction:
ModemManager 1.24+ includes changes that reduce the likelihood of this
issue by ensuring the modem is in a low-power state before the kernel
attempts runtime suspend. However, the kernel driver should not depend
on specific userspace behavior or ModemManager versions. Older versions
(1.20-1.22) are still widely deployed, and the kernel should be robust
regardless of userspace implementation details.
There appears to be no hardware status register or other mechanism
available to query whether the firmware is ready for SAP suspend.
A delay between the two suspend requests is the most reliable solution
found through testing.
Add a 50ms delay between MD suspend and SAP suspend. This gives the
firmware adequate time to complete internal operations without adding
significant latency to the suspend path. This makes the driver robust
across all ModemManager versions and system conditions.
Testing: 96+ hours of continuous operation with ModemManager 1.20.2
and Fibocom FM350-GL modem. Zero SAP suspend timeouts observed across
2000+ successful suspend/resume cycles. Previously failed within
24 hours with 100% reproducibility.
Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
---
drivers/net/wwan/t7xx/t7xx_pci.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/wwan/t7xx/t7xx_pci.c b/drivers/net/wwan/t7xx/t7xx_pci.c
index eb137e078423..46613bba1f41 100644
--- a/drivers/net/wwan/t7xx/t7xx_pci.c
+++ b/drivers/net/wwan/t7xx/t7xx_pci.c
@@ -447,6 +447,9 @@ static int __t7xx_pci_pm_suspend(struct pci_dev *pdev)
goto abort_suspend;
}
+ /* Delay to prevent SAP suspend timeout */
+ msleep(50);
+
ret = t7xx_send_pm_request(t7xx_dev, H2D_CH_SUSPEND_REQ_AP);
if (ret) {
t7xx_send_pm_request(t7xx_dev, H2D_CH_RESUME_REQ);
--
2.54.0
On Wed, May 27, 2026 at 8:15 AM Jose Ignacio Tornos Martinez
<jtornosm@redhat.com> wrote:
>
> SAP (Service Access Point) suspend occasionally times out with error
> -110 (ETIMEDOUT), followed by modem port errors and complete modem
> failure requiring a system reboot to recover.
>
> Error symptoms:
> mtk_t7xx 0000:72:00.0: [PM] SAP suspend error: -110
> mtk_t7xx 0000:72:00.0: can't suspend (...returned -110)
> mtk_t7xx 0000:07:00.0: Failed to send skb: -22
> mtk_t7xx 0000:07:00.0: Write error on MBIM port, -22
>
> The modem firmware needs time after receiving the MD (modem) suspend
> request to complete internal operations before it is ready to accept
> the SAP suspend request. Without this delay, if runtime PM attempts
> to suspend while the firmware is busy, the SAP suspend command times
> out, leaving the modem in an unrecoverable state.
>
> Root cause and userspace interaction:
> ModemManager 1.24+ includes changes that reduce the likelihood of this
> issue by ensuring the modem is in a low-power state before the kernel
> attempts runtime suspend. However, the kernel driver should not depend
> on specific userspace behavior or ModemManager versions. Older versions
> (1.20-1.22) are still widely deployed, and the kernel should be robust
> regardless of userspace implementation details.
>
> There appears to be no hardware status register or other mechanism
> available to query whether the firmware is ready for SAP suspend.
> A delay between the two suspend requests is the most reliable solution
> found through testing.
>
> Add a 50ms delay between MD suspend and SAP suspend. This gives the
> firmware adequate time to complete internal operations without adding
> significant latency to the suspend path. This makes the driver robust
> across all ModemManager versions and system conditions.
>
> Testing: 96+ hours of continuous operation with ModemManager 1.20.2
> and Fibocom FM350-GL modem. Zero SAP suspend timeouts observed across
> 2000+ successful suspend/resume cycles. Previously failed within
> 24 hours with 100% reproducibility.
>
> Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
Reviewed-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> ---
> drivers/net/wwan/t7xx/t7xx_pci.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/net/wwan/t7xx/t7xx_pci.c b/drivers/net/wwan/t7xx/t7xx_pci.c
> index eb137e078423..46613bba1f41 100644
> --- a/drivers/net/wwan/t7xx/t7xx_pci.c
> +++ b/drivers/net/wwan/t7xx/t7xx_pci.c
> @@ -447,6 +447,9 @@ static int __t7xx_pci_pm_suspend(struct pci_dev *pdev)
> goto abort_suspend;
> }
>
> + /* Delay to prevent SAP suspend timeout */
> + msleep(50);
> +
> ret = t7xx_send_pm_request(t7xx_dev, H2D_CH_SUSPEND_REQ_AP);
> if (ret) {
> t7xx_send_pm_request(t7xx_dev, H2D_CH_RESUME_REQ);
> --
> 2.54.0
>
© 2016 - 2026 Red Hat, Inc.