Re: [v1 PATCH 1/1] bus: mhi: core: fix sys error handling latency

From: Qingtao Cao

Date: Mon Jun 15 2026 - 05:47:51 EST


Yes indeed, this is exactly what the original commit,
44b1eba44dc537edf076f131f1eeee7544d0e04f, by Loic Poulain on 2021 Jun
21 was about:

On graceful power-down/disable transition, when an MHI reset is
performed, the MHI device loses its context, including interrupt
configuration. However, the current implementation is waiting for
event(irq) driven state change to confirm reset has been completed,
which never happens, and causes reset timeout, leading to unexpected
high latency of the mhi_power_down procedure (up to 45 seconds).

Fix that by moving to the recently introduced poll_reg_field method,
waiting for the reset bit to be cleared, in the same way as the
power_on procedure.

Thanks,
Qingtao

On Mon, Jun 15, 2026 at 2:07 PM Krishna Chaitanya Chundru
<krishna.chundru@xxxxxxxxxxxxxxxx> wrote:
>
>
>
> On 6/11/2026 4:29 AM, Qingtao Cao wrote:
> > Hello Krishna,
> >
> > Thanks for your reply!
> >
> > I am using an old 5.17.0 kernel and Sierra Wireless EM9291, the MHI
> > pci_generic.c driver was modified a bit to support it,
> > which is very similar to EM919x and the modem_sierra_em919x_config
> > descriptor was reused for it (thus the timeout_ms
> > = 24000ms, or 24s applies)
> >
> > Without the proposed change, the AT!RESET handling will finish after
> > timeout in 24 seconds, whereas with the change,
> > the handling can finish in about 11 seconds
> >
> > I was inspired by another earlier commit to fix MHI_STATE_RESET handling in
> > mhi_pm_disable_transition().
> >
> > Warm regards,
> > Qingtao
>
> Looks like device is clearing reset state, but we are not getting any msi
> to trigger mhi state event. As MSI is not expected to send msi from the
> device after clearing MHI RESET.
>
> Reviewed-by: Krishna Chaitanya Chundru <krishna.chundru@xxxxxxxxxxxxxxxx>
>
> - Krishna Chaitanya.
>
> > On Wed, Jun 10, 2026 at 10:40 PM Krishna Chaitanya Chundru <
> > krishna.chundru@xxxxxxxxxxxxxxxx> wrote:
> >
> >>
> >> On 6/3/2026 6:36 AM, Qingtao Cao wrote:
> >>> Bring forward the idea to fix the power down latency in
> >>> mhi_pm_disable_transition() further to mhi_pm_sys_error_transition()
> >>> so that the transition into system error (triggered by AT!RESET)
> >>> won't have to return only after the timeout of up to 24 seconds
> >> Hi,
> >>
> >> Generally we should not see this delay, as device is actually clearing
> >> reset. can you give more details what is the device you are using and
> >> kernel you
> >> are using etc.
> >>
> >> - Krishna Chaitanya.
> >>> Signed-off-by: Qingtao Cao <qingtao.cao.au@xxxxxxxxx>
> >>> ---
> >>> drivers/bus/mhi/host/pm.c | 14 +++-----------
> >>> 1 file changed, 3 insertions(+), 11 deletions(-)
> >>>
> >>> diff --git a/drivers/bus/mhi/host/pm.c b/drivers/bus/mhi/host/pm.c
> >>> index f799503c8f36..9d29f1591a45 100644
> >>> --- a/drivers/bus/mhi/host/pm.c
> >>> +++ b/drivers/bus/mhi/host/pm.c
> >>> @@ -651,21 +651,13 @@ static void mhi_pm_sys_error_transition(struct
> >> mhi_controller *mhi_cntrl)
> >>> /* Trigger MHI RESET so that the device will not access host
> >> memory */
> >>> if (reset_device) {
> >>> - u32 in_reset = -1;
> >>> - unsigned long timeout =
> >> msecs_to_jiffies(mhi_cntrl->timeout_ms);
> >>> -
> >>> dev_dbg(dev, "Triggering MHI Reset in device\n");
> >>> mhi_set_mhi_state(mhi_cntrl, MHI_STATE_RESET);
> >>>
> >>> /* Wait for the reset bit to be cleared by the device */
> >>> - ret = wait_event_timeout(mhi_cntrl->state_event,
> >>> - mhi_read_reg_field(mhi_cntrl,
> >>> -
> >> mhi_cntrl->regs,
> >>> - MHICTRL,
> >>> -
> >> MHICTRL_RESET_MASK,
> >>> - &in_reset) ||
> >>> - !in_reset, timeout);
> >>> - if (!ret || in_reset) {
> >>> + ret = mhi_poll_reg_field(mhi_cntrl, mhi_cntrl->regs,
> >> MHICTRL,
> >>> + MHICTRL_RESET_MASK, 0, 25000,
> >> mhi_cntrl->timeout_ms);
> >>> + if (ret) {
> >>> dev_err(dev, "Device failed to exit MHI Reset
> >> state\n");
> >>> write_lock_irq(&mhi_cntrl->pm_lock);
> >>> cur_state = mhi_tryset_pm_state(mhi_cntrl,
> >>
>