From: "Peter Wang (王信友)" <peter.wang@mediatek.com>
To: "linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
"bvanassche@acm.org" <bvanassche@acm.org>,
"martin.petersen@oracle.com" <martin.petersen@oracle.com>
Cc: "Tun-yu Yu (游敦聿)" <Tun-yu.Yu@mediatek.com>,
"Alice Chao (趙珮均)" <Alice.Chao@mediatek.com>,
"Eddie Huang (黃智傑)" <eddie.huang@mediatek.com>,
"CC Chou (周志杰)" <cc.chou@mediatek.com>,
"Ed Tsai (蔡宗軒)" <Ed.Tsai@mediatek.com>,
wsd_upstream <wsd_upstream@mediatek.com>,
"Chaotian Jing (井朝天)" <Chaotian.Jing@mediatek.com>,
"Chun-Hung Wu (巫駿宏)" <Chun-hung.Wu@mediatek.com>,
"Yi-fan Peng (彭羿凡)" <Yi-fan.Peng@mediatek.com>,
"Qilin Tan (谭麒麟)" <Qilin.Tan@mediatek.com>,
"linux-mediatek@lists.infradead.org"
<linux-mediatek@lists.infradead.org>,
"Jiajie Hao (郝加节)" <jiajie.hao@mediatek.com>,
"Lin Gui (桂林)" <Lin.Gui@mediatek.com>,
"Naomi Chu (朱詠田)" <Naomi.Chu@mediatek.com>
Subject: Re: [PATCH v1 01/10] ufs: host: mediatek: Fix runtime suspend error deadlock
Date: Mon, 22 Sep 2025 08:37:10 +0000 [thread overview]
Message-ID: <4f8d4f0c9efd24aa4448e6dda064b0633d253f2d.camel@mediatek.com> (raw)
In-Reply-To: <bc612c10-a4eb-41ab-b8e5-726d22935518@acm.org>
On Fri, 2025-09-19 at 13:57 -0700, Bart Van Assche wrote
>
> If the suspend callback waits for error handling to finish and the
> error handler waits until resuming has finished, isn't this an issue
> that can occur for any UFS host controller and hence that should be
> fixed in the UFSHCI driver core rather than in one host driver only?
>
> Why is the hba->pm_op_in_progress variable not sufficient to prevent
> this deadlock? Should this code perhaps be moved from
> ufshcd_eh_host_reset_handler() into ufshcd_err_handler()?
>
> /*
> * If runtime PM sent SSU and got a timeout,
> scsi_error_handler is
> * stuck in this function waiting for flush_work(&hba-
> >eh_work). And
> * ufshcd_err_handler(eh_work) is stuck waiting for runtime
> PM. Do
> * ufshcd_link_recovery instead of eh_work to prevent
> deadlock.
> */
> if (hba->pm_op_in_progress) {
> if (ufshcd_link_recovery(hba))
> err = FAILED;
>
> return err;
> }
>
Hi Bart,
Okay, you prefer to check pm_op_in_progress before getting
runtime PM, like below patch?
If yes, I will remove this patch and check this in ufs core.
@@ -6625,6 +6625,11 @@ static void ufshcd_err_handler(struct
work_struct *work)
}
spin_unlock_irqrestore(hba->host->host_lock, flags);
+ if (hba->pm_op_in_progress) {
+ ufshcd_link_recovery(hba);
+ return;
+ }
+
ufshcd_err_handling_prepare(hba);
> > > How can ufs_mtk_suspend() be called while the error handler is in
> > > progress? ufshcd_err_handler() disables RPM before it sets the
> > > UFSHCD_EH_IN_PROGRESS flag.
> >
> > This error is triggered by ufs_mtk_auto_hibern8_disable,
> > As the comment description
> > /* May trigger EH work without exiting hibern8 error */
> > so it could happen during the suspend period.
>
> That source code comment is confusing me, especially the "without
> exiting hibern8 error" part. Do you really want to say that the
> device
> is in a hibernation error state and remains in a hibernation error
> state?
>
No, it just means that when exiting hibernate,
err = ufs_mtk_auto_hibern8_disable(hba);
err could be 0.
But the UIC error could be triggered by an interrupt.
> > > The UFSHCD_EH_IN_PROGRESS definition and also the
> > > ufshcd_set_eh_in_progress() and ufshcd_clear_eh_in_progress()
> > > definitions must remain in the UFS core private code. Please do
> > > not
> > > move
> > > these definitions into the include/ufs/ufshcd.h header file.
> >
> > Do you think we should check ufshcd_eh_in_progress in
> > __ufshcd_wl_suspend? I'm not sure, because we don't see this
> > error on all UFS hosts — the vendor suspend operations
> > (ufshcd_vops_suspend) could be different.
>
> Why is auto-hibernation disabled during suspend? As far as I know the
> UFSHCI standard allows to keep auto-hibernation enabled during
> suspend.
>
> Thanks,
>
> Bart.
This is a limitation of MediaTek’s SoC.
If auto-hibernate is triggered concurrently with manual
hibernate, it may cause errors. Therefore, we disable
auto-hibernate before issuing a manual hibernate command.
Thanks.
Peter
next prev parent reply other threads:[~2025-09-22 8:37 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-18 10:36 [PATCH v1 00/10] Enhance UFS Mediatek Driver peter.wang
2025-09-18 10:36 ` [PATCH v1 01/10] ufs: host: mediatek: Fix runtime suspend error deadlock peter.wang
2025-09-18 18:27 ` Bart Van Assche
2025-09-19 8:11 ` Peter Wang (王信友)
2025-09-19 20:57 ` Bart Van Assche
2025-09-22 8:37 ` Peter Wang (王信友) [this message]
2025-09-22 18:27 ` Bart Van Assche
2025-09-23 5:56 ` Peter Wang (王信友)
2025-09-18 10:36 ` [PATCH v1 02/10] ufs: host: mediatek: Correct clock scaling with PM QoS flow peter.wang
2025-09-18 18:30 ` Bart Van Assche
2025-09-19 8:11 ` Peter Wang (王信友)
2025-09-19 21:02 ` Bart Van Assche
2025-09-22 8:39 ` Peter Wang (王信友)
2025-09-22 19:21 ` Bart Van Assche
2025-09-23 5:58 ` Peter Wang (王信友)
2025-09-18 10:36 ` [PATCH v1 03/10] ufs: host: mediatek: Adjust clock scaling for PM flow peter.wang
2025-09-18 10:36 ` [PATCH v1 04/10] ufs: host: mediatek: Handle clock scaling for high gear in " peter.wang
2025-09-18 10:36 ` [PATCH v1 05/10] ufs: host: mediatek: Adjust sync length for FASTAUTO mode peter.wang
2025-09-18 19:28 ` Bart Van Assche
2025-09-19 8:12 ` Peter Wang (王信友)
2025-09-18 10:36 ` [PATCH v1 06/10] ufs: host: mediatek: Enable interrupts for MCQ mode peter.wang
2025-09-18 18:34 ` Bart Van Assche
2025-09-19 8:14 ` Peter Wang (王信友)
2025-09-19 21:09 ` Bart Van Assche
2025-09-22 8:41 ` Peter Wang (王信友)
2025-09-22 19:26 ` Bart Van Assche
2025-09-23 5:59 ` Peter Wang (王信友)
2025-09-18 10:36 ` [PATCH v1 07/10] ufs: host: mediatek: Fix shutdown/suspend race condition peter.wang
2025-09-18 18:39 ` Bart Van Assche
2025-09-19 8:15 ` Peter Wang (王信友)
2025-09-19 21:10 ` Bart Van Assche
2025-09-18 10:36 ` [PATCH v1 08/10] ufs: host: mediatek: Remove duplicate function peter.wang
2025-09-18 19:29 ` Bart Van Assche
2025-09-18 10:36 ` [PATCH v1 09/10] ufs: host: mediatek: Add support for new platform with MMIO_OTSD_CTR peter.wang
2025-09-18 10:36 ` [PATCH v1 10/10] ufs: host: mediatek: Support new feature for MT6991 peter.wang
2025-09-18 19:32 ` Bart Van Assche
2025-09-19 8:17 ` Peter Wang (王信友)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4f8d4f0c9efd24aa4448e6dda064b0633d253f2d.camel@mediatek.com \
--to=peter.wang@mediatek.com \
--cc=Alice.Chao@mediatek.com \
--cc=Chaotian.Jing@mediatek.com \
--cc=Chun-hung.Wu@mediatek.com \
--cc=Ed.Tsai@mediatek.com \
--cc=Lin.Gui@mediatek.com \
--cc=Naomi.Chu@mediatek.com \
--cc=Qilin.Tan@mediatek.com \
--cc=Tun-yu.Yu@mediatek.com \
--cc=Yi-fan.Peng@mediatek.com \
--cc=bvanassche@acm.org \
--cc=cc.chou@mediatek.com \
--cc=eddie.huang@mediatek.com \
--cc=jiajie.hao@mediatek.com \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=wsd_upstream@mediatek.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox