* [PATCH] bus: mhi: pci_generic: Fix erroneous system suspend abort
@ 2026-11-11 17:23 Len Brown
2026-11-12 8:22 ` Loic Poulain
0 siblings, 1 reply; 6+ messages in thread
From: Len Brown @ 2026-11-11 17:23 UTC (permalink / raw)
To: rafael, Manivannan Sadhasivam, Loic Poulain; +Cc: linux-pm, mhi, linux-kernel
From: Len Brown <len.brown@intel.com>
mhi sometimes aborts system suspend on the thinkpad T16 gen3:
mhi-pci-generic 0000:08:00.0: failed to suspend device: -16
mhi-pci-generic 0000:08:00.0: PM: pci_pm_suspend(): mhi_pci_suspend [mhi_pci_generic] returns -16
mhi-pci-generic 0000:08:00.0: PM: dpm_run_callback(): pci_pm_suspend returns -16
mhi-pci-generic 0000:08:00.0: PM: pci_pm_suspend returned -16 after 15145 usecs
mhi-pci-generic 0000:08:00.0: PM: failed to suspend async: error -16
When a driver returns -EBUSY for its runtime suspend method,
that means "try again later".
But when a driver returns anything but 0 from its system-suspend
method, that means "abort system suspend".
Always return 0 from mhi_pci_suspend().
Fixes: d3800c1dce24 ("bus: mhi: pci_generic: Add support for runtime PM")
Signed-off-by: Len Brown <len.brown@intel.com>
---
drivers/bus/mhi/host/pci_generic.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/bus/mhi/host/pci_generic.c b/drivers/bus/mhi/host/pci_generic.c
index 7193a384cca4..b036fa6e06c4 100644
--- a/drivers/bus/mhi/host/pci_generic.c
+++ b/drivers/bus/mhi/host/pci_generic.c
@@ -1727,7 +1727,8 @@ static int __maybe_unused mhi_pci_runtime_resume(struct device *dev)
static int __maybe_unused mhi_pci_suspend(struct device *dev)
{
pm_runtime_disable(dev);
- return mhi_pci_runtime_suspend(dev);
+ mhi_pci_runtime_suspend(dev);
+ return 0;
}
static int __maybe_unused mhi_pci_resume(struct device *dev)
--
2.45.2
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] bus: mhi: pci_generic: Fix erroneous system suspend abort
2026-11-11 17:23 [PATCH] bus: mhi: pci_generic: Fix erroneous system suspend abort Len Brown
@ 2026-11-12 8:22 ` Loic Poulain
2026-11-13 12:42 ` Len Brown
0 siblings, 1 reply; 6+ messages in thread
From: Loic Poulain @ 2026-11-12 8:22 UTC (permalink / raw)
To: Len Brown; +Cc: rafael, Manivannan Sadhasivam, linux-pm, mhi, linux-kernel
Hi Len,
On Wed, Nov 11, 2026 at 6:23 PM Len Brown <lenb@kernel.org> wrote:
>
> From: Len Brown <len.brown@intel.com>
>
> mhi sometimes aborts system suspend on the thinkpad T16 gen3:
>
> mhi-pci-generic 0000:08:00.0: failed to suspend device: -16
> mhi-pci-generic 0000:08:00.0: PM: pci_pm_suspend(): mhi_pci_suspend [mhi_pci_generic] returns -16
> mhi-pci-generic 0000:08:00.0: PM: dpm_run_callback(): pci_pm_suspend returns -16
> mhi-pci-generic 0000:08:00.0: PM: pci_pm_suspend returned -16 after 15145 usecs
> mhi-pci-generic 0000:08:00.0: PM: failed to suspend async: error -16
>
> When a driver returns -EBUSY for its runtime suspend method,
> that means "try again later".
>
> But when a driver returns anything but 0 from its system-suspend
> method, that means "abort system suspend".
>
> Always return 0 from mhi_pci_suspend().
Two things:
- I think we should simply use pm_runtime_force_suspend() /
pm_runtime_force_resume() for the system sleep callbacks instead of
implementing separate suspend/resume handling.
- Rather than silently ignoring the error, I think it would be worth
looking at the mhi_pm_suspend() implementation to understand what can
be returned here and under which conditions the MHI device fails to
suspend.
Regards,
Loic
>
> Fixes: d3800c1dce24 ("bus: mhi: pci_generic: Add support for runtime PM")
> Signed-off-by: Len Brown <len.brown@intel.com>
> ---
> drivers/bus/mhi/host/pci_generic.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/bus/mhi/host/pci_generic.c b/drivers/bus/mhi/host/pci_generic.c
> index 7193a384cca4..b036fa6e06c4 100644
> --- a/drivers/bus/mhi/host/pci_generic.c
> +++ b/drivers/bus/mhi/host/pci_generic.c
> @@ -1727,7 +1727,8 @@ static int __maybe_unused mhi_pci_runtime_resume(struct device *dev)
> static int __maybe_unused mhi_pci_suspend(struct device *dev)
> {
> pm_runtime_disable(dev);
> - return mhi_pci_runtime_suspend(dev);
> + mhi_pci_runtime_suspend(dev);
> + return 0;
> }
>
> static int __maybe_unused mhi_pci_resume(struct device *dev)
> --
> 2.45.2
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] bus: mhi: pci_generic: Fix erroneous system suspend abort
2026-11-12 8:22 ` Loic Poulain
@ 2026-11-13 12:42 ` Len Brown
2026-11-13 13:20 ` Loic Poulain
0 siblings, 1 reply; 6+ messages in thread
From: Len Brown @ 2026-11-13 12:42 UTC (permalink / raw)
To: Loic Poulain; +Cc: rafael, Manivannan Sadhasivam, linux-pm, mhi, linux-kernel
Hello Loic,
I agree that the device and the driver should be debugged, and perhaps
re-implemented.
Indeed, I'm happy to share the dmesg from 28,000 suspend/resume cycles
on this machine
over the last few months to support that effort, should somebody else
undertake it.
But today, this device is allowing its internal contagion to spread
into Linux and interfere with
system wide suspend due to an obvious 1-line programming error.
This 1-line fix should be applied NOW, without waiting for internal
mhi internal or development.
thanks,
-Len
ps. I filed this over a year ago:
https://bugzilla.kernel.org/show_bug.cgi?id=220020
On Thu, Nov 12, 2026 at 5:23 AM Loic Poulain
<loic.poulain@oss.qualcomm.com> wrote:
>
> Hi Len,
>
> On Wed, Nov 11, 2026 at 6:23 PM Len Brown <lenb@kernel.org> wrote:
> >
> > From: Len Brown <len.brown@intel.com>
> >
> > mhi sometimes aborts system suspend on the thinkpad T16 gen3:
> >
> > mhi-pci-generic 0000:08:00.0: failed to suspend device: -16
> > mhi-pci-generic 0000:08:00.0: PM: pci_pm_suspend(): mhi_pci_suspend [mhi_pci_generic] returns -16
> > mhi-pci-generic 0000:08:00.0: PM: dpm_run_callback(): pci_pm_suspend returns -16
> > mhi-pci-generic 0000:08:00.0: PM: pci_pm_suspend returned -16 after 15145 usecs
> > mhi-pci-generic 0000:08:00.0: PM: failed to suspend async: error -16
> >
> > When a driver returns -EBUSY for its runtime suspend method,
> > that means "try again later".
> >
> > But when a driver returns anything but 0 from its system-suspend
> > method, that means "abort system suspend".
> >
> > Always return 0 from mhi_pci_suspend().
>
> Two things:
> - I think we should simply use pm_runtime_force_suspend() /
> pm_runtime_force_resume() for the system sleep callbacks instead of
> implementing separate suspend/resume handling.
> - Rather than silently ignoring the error, I think it would be worth
> looking at the mhi_pm_suspend() implementation to understand what can
> be returned here and under which conditions the MHI device fails to
> suspend.
>
> Regards,
> Loic
>
> >
> > Fixes: d3800c1dce24 ("bus: mhi: pci_generic: Add support for runtime PM")
> > Signed-off-by: Len Brown <len.brown@intel.com>
> > ---
> > drivers/bus/mhi/host/pci_generic.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/bus/mhi/host/pci_generic.c b/drivers/bus/mhi/host/pci_generic.c
> > index 7193a384cca4..b036fa6e06c4 100644
> > --- a/drivers/bus/mhi/host/pci_generic.c
> > +++ b/drivers/bus/mhi/host/pci_generic.c
> > @@ -1727,7 +1727,8 @@ static int __maybe_unused mhi_pci_runtime_resume(struct device *dev)
> > static int __maybe_unused mhi_pci_suspend(struct device *dev)
> > {
> > pm_runtime_disable(dev);
> > - return mhi_pci_runtime_suspend(dev);
> > + mhi_pci_runtime_suspend(dev);
> > + return 0;
> > }
> >
> > static int __maybe_unused mhi_pci_resume(struct device *dev)
> > --
> > 2.45.2
> >
--
Len Brown, Intel Open Source Technology Center
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] bus: mhi: pci_generic: Fix erroneous system suspend abort
2026-11-13 12:42 ` Len Brown
@ 2026-11-13 13:20 ` Loic Poulain
2026-11-13 14:09 ` Len Brown
0 siblings, 1 reply; 6+ messages in thread
From: Loic Poulain @ 2026-11-13 13:20 UTC (permalink / raw)
To: Len Brown; +Cc: rafael, Manivannan Sadhasivam, linux-pm, mhi, linux-kernel
On Fri, Nov 13, 2026 at 1:43 PM Len Brown <lenb@kernel.org> wrote:
>
> Hello Loic,
>
> I agree that the device and the driver should be debugged, and perhaps
> re-implemented.
>
> Indeed, I'm happy to share the dmesg from 28,000 suspend/resume cycles
> on this machine
> over the last few months to support that effort, should somebody else
> undertake it.
>
> But today, this device is allowing its internal contagion to spread
> into Linux and interfere with
> system wide suspend due to an obvious 1-line programming error.
>
> This 1-line fix should be applied NOW, without waiting for internal
> mhi internal or development.
Fair enough, but would only ignoring error on -EBUSY would work for
you? as this is clearly something which is not relevant for system
wide suspend cases.
Also would it be possible to add a small inline comment saying we
purposely ignore this because of buggy mhi suspend handling.
With your patch what happens on the system resume path? is the MHI
device recovered?
Regards,
Loic
> thanks,
> -Len
>
> ps. I filed this over a year ago:
> https://bugzilla.kernel.org/show_bug.cgi?id=220020
>
> On Thu, Nov 12, 2026 at 5:23 AM Loic Poulain
> <loic.poulain@oss.qualcomm.com> wrote:
> >
> > Hi Len,
> >
> > On Wed, Nov 11, 2026 at 6:23 PM Len Brown <lenb@kernel.org> wrote:
> > >
> > > From: Len Brown <len.brown@intel.com>
> > >
> > > mhi sometimes aborts system suspend on the thinkpad T16 gen3:
> > >
> > > mhi-pci-generic 0000:08:00.0: failed to suspend device: -16
> > > mhi-pci-generic 0000:08:00.0: PM: pci_pm_suspend(): mhi_pci_suspend [mhi_pci_generic] returns -16
> > > mhi-pci-generic 0000:08:00.0: PM: dpm_run_callback(): pci_pm_suspend returns -16
> > > mhi-pci-generic 0000:08:00.0: PM: pci_pm_suspend returned -16 after 15145 usecs
> > > mhi-pci-generic 0000:08:00.0: PM: failed to suspend async: error -16
> > >
> > > When a driver returns -EBUSY for its runtime suspend method,
> > > that means "try again later".
> > >
> > > But when a driver returns anything but 0 from its system-suspend
> > > method, that means "abort system suspend".
> > >
> > > Always return 0 from mhi_pci_suspend().
> >
> > Two things:
> > - I think we should simply use pm_runtime_force_suspend() /
> > pm_runtime_force_resume() for the system sleep callbacks instead of
> > implementing separate suspend/resume handling.
> > - Rather than silently ignoring the error, I think it would be worth
> > looking at the mhi_pm_suspend() implementation to understand what can
> > be returned here and under which conditions the MHI device fails to
> > suspend.
> >
> > Regards,
> > Loic
> >
> > >
> > > Fixes: d3800c1dce24 ("bus: mhi: pci_generic: Add support for runtime PM")
> > > Signed-off-by: Len Brown <len.brown@intel.com>
> > > ---
> > > drivers/bus/mhi/host/pci_generic.c | 3 ++-
> > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/bus/mhi/host/pci_generic.c b/drivers/bus/mhi/host/pci_generic.c
> > > index 7193a384cca4..b036fa6e06c4 100644
> > > --- a/drivers/bus/mhi/host/pci_generic.c
> > > +++ b/drivers/bus/mhi/host/pci_generic.c
> > > @@ -1727,7 +1727,8 @@ static int __maybe_unused mhi_pci_runtime_resume(struct device *dev)
> > > static int __maybe_unused mhi_pci_suspend(struct device *dev)
> > > {
> > > pm_runtime_disable(dev);
> > > - return mhi_pci_runtime_suspend(dev);
> > > + mhi_pci_runtime_suspend(dev);
> > > + return 0;
> > > }
> > >
> > > static int __maybe_unused mhi_pci_resume(struct device *dev)
> > > --
> > > 2.45.2
> > >
>
>
>
> --
> Len Brown, Intel Open Source Technology Center
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] bus: mhi: pci_generic: Fix erroneous system suspend abort
2026-11-13 13:20 ` Loic Poulain
@ 2026-11-13 14:09 ` Len Brown
2026-11-13 15:06 ` Loic Poulain
0 siblings, 1 reply; 6+ messages in thread
From: Len Brown @ 2026-11-13 14:09 UTC (permalink / raw)
To: Loic Poulain; +Cc: rafael, Manivannan Sadhasivam, linux-pm, mhi, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1758 bytes --]
> > This 1-line fix should be applied NOW, without waiting for internal
> > mhi internal or development.
>
> Fair enough, but would only ignoring error on -EBUSY would work for
> you? as this is clearly something which is not relevant for system
> wide suspend cases.
Although I've seen only -EBUSY, I would turn that around...
Are there ANY mhi suspend cases that merit aborting system wide suspend?
If there are, then check for those and explicitly abort system suspension.
(experience shows that these scenarios are quite rare, and it would
be remarkable if there were such a condition here)
> Also would it be possible to add a small inline comment saying we
> purposely ignore this because of buggy mhi suspend handling.
I agree. I'll add a comment to clarify.
> With your patch what happens on the system resume path? is the MHI
> device recovered?
This laptop is generally quite a good suspend-resume regression test bed.
It does actually have a wireless modem, but AFAIK, the device itself
is always unused.
$ lspci -nnk | grep -B 2 -A 3 -i mhi
08:00.0 Unassigned class [ff00]: Quectel Wireless Solutions Co., Ltd.
Device [1eac:1007]
Subsystem: Quectel Wireless Solutions Co., Ltd. Device [1eac:100c]
Kernel driver in use: mhi-pci-generic
Kernel modules: mhi_pci_generic
I have over 28,000 suspend resume results on its local drive, dating
back to Linux-7.2.
The most recent 3,000 cycles included this one line patch and showed no issues.
There were 9 suspend failures on a run of 2,500 suspend cycles run Nov
8 - Nov 9.
I've attached the mhi messages, as they'd wrap if I pasted them here.
Twice we see this:
mhi-pci-generic 0000:08:00.0: Unbalanced pm_runtime_enable!
perhaps a hint?
thanks,
-Len
ps. apology for the previous top-post.
[-- Attachment #2: mhi.dmesg.txt --]
[-- Type: text/plain, Size: 7254 bytes --]
suspend-261108-235706/lenb-thinkpad-t16-gen-3_freeze_dmesg.txt:[ 858.658113] mhi-pci-generic 0000:08:00.0: failed to suspend device: -16
suspend-261108-235706/lenb-thinkpad-t16-gen-3_freeze_dmesg.txt:[ 858.658133] mhi-pci-generic 0000:08:00.0: PM: pci_pm_suspend(): mhi_pci_suspend [mhi_pci_generic] returns -16
suspend-261108-235706/lenb-thinkpad-t16-gen-3_freeze_dmesg.txt:[ 858.658149] mhi-pci-generic 0000:08:00.0: PM: dpm_run_callback(): pci_pm_suspend returns -16
suspend-261108-235706/lenb-thinkpad-t16-gen-3_freeze_dmesg.txt:[ 858.658159] mhi-pci-generic 0000:08:00.0: PM: pci_pm_suspend returned -16 after 15145 usecs
suspend-261108-235706/lenb-thinkpad-t16-gen-3_freeze_dmesg.txt:[ 858.658162] mhi-pci-generic 0000:08:00.0: PM: failed to suspend async: error -16
suspend-261109-023323/lenb-thinkpad-t16-gen-3_freeze_dmesg.txt:[10240.621426] mhi-pci-generic 0000:08:00.0: failed to suspend device: -16
suspend-261109-023323/lenb-thinkpad-t16-gen-3_freeze_dmesg.txt:[10240.621484] mhi-pci-generic 0000:08:00.0: PM: pci_pm_suspend(): mhi_pci_suspend [mhi_pci_generic] returns -16
suspend-261109-023323/lenb-thinkpad-t16-gen-3_freeze_dmesg.txt:[10240.621501] mhi-pci-generic 0000:08:00.0: PM: dpm_run_callback(): pci_pm_suspend returns -16
suspend-261109-023323/lenb-thinkpad-t16-gen-3_freeze_dmesg.txt:[10240.621510] mhi-pci-generic 0000:08:00.0: PM: pci_pm_suspend returned -16 after 88 usecs
suspend-261109-023323/lenb-thinkpad-t16-gen-3_freeze_dmesg.txt:[10240.621513] mhi-pci-generic 0000:08:00.0: PM: failed to suspend async: error -16
suspend-261109-024206/lenb-thinkpad-t16-gen-3_freeze_dmesg.txt:[10763.773690] mhi-pci-generic 0000:08:00.0: failed to suspend device: -16
suspend-261109-024206/lenb-thinkpad-t16-gen-3_freeze_dmesg.txt:[10763.773705] mhi-pci-generic 0000:08:00.0: PM: pci_pm_suspend(): mhi_pci_suspend [mhi_pci_generic] returns -16
suspend-261109-024206/lenb-thinkpad-t16-gen-3_freeze_dmesg.txt:[10763.773716] mhi-pci-generic 0000:08:00.0: PM: dpm_run_callback(): pci_pm_suspend returns -16
suspend-261109-024206/lenb-thinkpad-t16-gen-3_freeze_dmesg.txt:[10763.773722] mhi-pci-generic 0000:08:00.0: PM: pci_pm_suspend returned -16 after 34 usecs
suspend-261109-024206/lenb-thinkpad-t16-gen-3_freeze_dmesg.txt:[10763.773725] mhi-pci-generic 0000:08:00.0: PM: failed to suspend async: error -16
suspend-261109-044656/lenb-thinkpad-t16-gen-3_freeze_dmesg.txt:[18254.529615] mhi-pci-generic 0000:08:00.0: failed to suspend device: -16
suspend-261109-044656/lenb-thinkpad-t16-gen-3_freeze_dmesg.txt:[18254.529632] mhi-pci-generic 0000:08:00.0: PM: pci_pm_suspend(): mhi_pci_suspend [mhi_pci_generic] returns -16
suspend-261109-044656/lenb-thinkpad-t16-gen-3_freeze_dmesg.txt:[18254.529651] mhi-pci-generic 0000:08:00.0: PM: dpm_run_callback(): pci_pm_suspend returns -16
suspend-261109-044656/lenb-thinkpad-t16-gen-3_freeze_dmesg.txt:[18254.529660] mhi-pci-generic 0000:08:00.0: PM: pci_pm_suspend returned -16 after 48 usecs
suspend-261109-044656/lenb-thinkpad-t16-gen-3_freeze_dmesg.txt:[18254.529662] mhi-pci-generic 0000:08:00.0: PM: failed to suspend async: error -16
suspend-261109-044821/lenb-thinkpad-t16-gen-3_freeze_dmesg.txt:[18339.528817] mhi-pci-generic 0000:08:00.0: failed to suspend device: -16
suspend-261109-044821/lenb-thinkpad-t16-gen-3_freeze_dmesg.txt:[18339.528831] mhi-pci-generic 0000:08:00.0: PM: pci_pm_suspend(): mhi_pci_suspend [mhi_pci_generic] returns -16
suspend-261109-044821/lenb-thinkpad-t16-gen-3_freeze_dmesg.txt:[18339.528839] mhi-pci-generic 0000:08:00.0: PM: dpm_run_callback(): pci_pm_suspend returns -16
suspend-261109-044821/lenb-thinkpad-t16-gen-3_freeze_dmesg.txt:[18339.528845] mhi-pci-generic 0000:08:00.0: PM: pci_pm_suspend returned -16 after 31 usecs
suspend-261109-044821/lenb-thinkpad-t16-gen-3_freeze_dmesg.txt:[18339.528847] mhi-pci-generic 0000:08:00.0: PM: failed to suspend async: error -16
suspend-261109-053226/lenb-thinkpad-t16-gen-3_freeze_dmesg.txt:[20984.601312] mhi-pci-generic 0000:08:00.0: failed to suspend device: -16
suspend-261109-053226/lenb-thinkpad-t16-gen-3_freeze_dmesg.txt:[20984.601346] mhi-pci-generic 0000:08:00.0: PM: pci_pm_suspend(): mhi_pci_suspend [mhi_pci_generic] returns -16
suspend-261109-053226/lenb-thinkpad-t16-gen-3_freeze_dmesg.txt:[20984.601354] mhi-pci-generic 0000:08:00.0: PM: dpm_run_callback(): pci_pm_suspend returns -16
suspend-261109-053226/lenb-thinkpad-t16-gen-3_freeze_dmesg.txt:[20984.601359] mhi-pci-generic 0000:08:00.0: PM: pci_pm_suspend returned -16 after 55 usecs
suspend-261109-053226/lenb-thinkpad-t16-gen-3_freeze_dmesg.txt:[20984.601361] mhi-pci-generic 0000:08:00.0: PM: failed to suspend async: error -16
suspend-261109-053240/lenb-thinkpad-t16-gen-3_freeze_dmesg.txt:[20997.534278] mhi-pci-generic 0000:08:00.0: Unbalanced pm_runtime_enable!
suspend-261109-053240/lenb-thinkpad-t16-gen-3_freeze_dmesg.txt:[20997.561203] mhi-pci-generic 0000:08:00.0: Unbalanced pm_runtime_enable!
suspend-261109-053519/lenb-thinkpad-t16-gen-3_freeze_dmesg.txt:[21157.715248] mhi-pci-generic 0000:08:00.0: failed to suspend device: -16
suspend-261109-053519/lenb-thinkpad-t16-gen-3_freeze_dmesg.txt:[21157.715264] mhi-pci-generic 0000:08:00.0: PM: pci_pm_suspend(): mhi_pci_suspend [mhi_pci_generic] returns -16
suspend-261109-053519/lenb-thinkpad-t16-gen-3_freeze_dmesg.txt:[21157.715277] mhi-pci-generic 0000:08:00.0: PM: dpm_run_callback(): pci_pm_suspend returns -16
suspend-261109-053519/lenb-thinkpad-t16-gen-3_freeze_dmesg.txt:[21157.715287] mhi-pci-generic 0000:08:00.0: PM: pci_pm_suspend returned -16 after 41 usecs
suspend-261109-053519/lenb-thinkpad-t16-gen-3_freeze_dmesg.txt:[21157.715291] mhi-pci-generic 0000:08:00.0: PM: failed to suspend async: error -16
suspend-261109-054114/lenb-thinkpad-t16-gen-3_freeze_dmesg.txt:[21512.348289] mhi-pci-generic 0000:08:00.0: failed to suspend device: -16
suspend-261109-054114/lenb-thinkpad-t16-gen-3_freeze_dmesg.txt:[21512.348335] mhi-pci-generic 0000:08:00.0: PM: pci_pm_suspend(): mhi_pci_suspend [mhi_pci_generic] returns -16
suspend-261109-054114/lenb-thinkpad-t16-gen-3_freeze_dmesg.txt:[21512.348355] mhi-pci-generic 0000:08:00.0: PM: dpm_run_callback(): pci_pm_suspend returns -16
suspend-261109-054114/lenb-thinkpad-t16-gen-3_freeze_dmesg.txt:[21512.348365] mhi-pci-generic 0000:08:00.0: PM: pci_pm_suspend returned -16 after 77 usecs
suspend-261109-054114/lenb-thinkpad-t16-gen-3_freeze_dmesg.txt:[21512.348368] mhi-pci-generic 0000:08:00.0: PM: failed to suspend async: error -16
suspend-261109-091429/lenb-thinkpad-t16-gen-3_freeze_dmesg.txt:[34308.085783] mhi-pci-generic 0000:08:00.0: failed to suspend device: -16
suspend-261109-091429/lenb-thinkpad-t16-gen-3_freeze_dmesg.txt:[34308.085793] mhi-pci-generic 0000:08:00.0: PM: pci_pm_suspend(): mhi_pci_suspend [mhi_pci_generic] returns -16
suspend-261109-091429/lenb-thinkpad-t16-gen-3_freeze_dmesg.txt:[34308.085801] mhi-pci-generic 0000:08:00.0: PM: dpm_run_callback(): pci_pm_suspend returns -16
suspend-261109-091429/lenb-thinkpad-t16-gen-3_freeze_dmesg.txt:[34308.085807] mhi-pci-generic 0000:08:00.0: PM: pci_pm_suspend returned -16 after 25 usecs
suspend-261109-091429/lenb-thinkpad-t16-gen-3_freeze_dmesg.txt:[34308.085809] mhi-pci-generic 0000:08:00.0: PM: failed to suspend async: error -16
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] bus: mhi: pci_generic: Fix erroneous system suspend abort
2026-11-13 14:09 ` Len Brown
@ 2026-11-13 15:06 ` Loic Poulain
0 siblings, 0 replies; 6+ messages in thread
From: Loic Poulain @ 2026-11-13 15:06 UTC (permalink / raw)
To: Len Brown; +Cc: rafael, Manivannan Sadhasivam, linux-pm, mhi, linux-kernel
On Fri, Nov 13, 2026 at 3:09 PM Len Brown <lenb@kernel.org> wrote:
>
> > > This 1-line fix should be applied NOW, without waiting for internal
> > > mhi internal or development.
> >
> > Fair enough, but would only ignoring error on -EBUSY would work for
> > you? as this is clearly something which is not relevant for system
> > wide suspend cases.
>
> Although I've seen only -EBUSY, I would turn that around...
> Are there ANY mhi suspend cases that merit aborting system wide suspend?
> If there are, then check for those and explicitly abort system suspension.
> (experience shows that these scenarios are quite rare, and it would
> be remarkable if there were such a condition here)
Taking a second look, it seems that we're not propagating the error
from MHI core in mhi_pci_runtime_suspend() and simply return always
-EBUSY instead, making it the only error that is reported anyway.
So your patch is fine as it stands as an immediate fix (along with the
comment). We can then work on a proper long-term solution separately.
>
> > Also would it be possible to add a small inline comment saying we
> > purposely ignore this because of buggy mhi suspend handling.
>
> I agree. I'll add a comment to clarify.
>
> > With your patch what happens on the system resume path? is the MHI
> > device recovered?
>
> This laptop is generally quite a good suspend-resume regression test bed.
> It does actually have a wireless modem, but AFAIK, the device itself
> is always unused.
>
> $ lspci -nnk | grep -B 2 -A 3 -i mhi
> 08:00.0 Unassigned class [ff00]: Quectel Wireless Solutions Co., Ltd.
> Device [1eac:1007]
> Subsystem: Quectel Wireless Solutions Co., Ltd. Device [1eac:100c]
> Kernel driver in use: mhi-pci-generic
> Kernel modules: mhi_pci_generic
>
> I have over 28,000 suspend resume results on its local drive, dating
> back to Linux-7.2.
> The most recent 3,000 cycles included this one line patch and showed no issues.
> There were 9 suspend failures on a run of 2,500 suspend cycles run Nov
> 8 - Nov 9.
It would be worth including this result/info in the commit message.
> I've attached the mhi messages, as they'd wrap if I pasted them here.
>
> Twice we see this:
> mhi-pci-generic 0000:08:00.0: Unbalanced pm_runtime_enable!
>
> perhaps a hint?
Thanks, I will look at this.
Regards,
Loic
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2026-11-13 15:06 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-11-11 17:23 [PATCH] bus: mhi: pci_generic: Fix erroneous system suspend abort Len Brown
2026-11-12 8:22 ` Loic Poulain
2026-11-13 12:42 ` Len Brown
2026-11-13 13:20 ` Loic Poulain
2026-11-13 14:09 ` Len Brown
2026-11-13 15:06 ` Loic Poulain
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®