From: HOYOUNG SEO <hy50.seo@samsung.com>
To: linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org,
bvanassche@acm.org, mkp@kernel.org, martin.petersen@oracle.com,
stanleyjhu@google.com, alim.akhtar@samsung.com,
kwangwon.min@samsung.com, kwmad.kim@samsung.com,
cpgs@samsung.com, h10.kim@samsung.com
Cc: HOYOUNG SEO <hy50.seo@samsung.com>
Subject: [PATCH v5 0/2] scsi: ufs: core: Avoid redundant link recovery from the error handler during system PM
Date: Thu, 5 Nov 2026 16:56:34 +0900 [thread overview]
Message-ID: <cover.1793865172.git.hy50.seo@samsung.com> (raw)
In-Reply-To: CGME20261105080058epcas2p33d17a4cc3163920fd24a3c378f21e3ae@epcas2p3.samsung.com
If a LINERESET is reported and the hibern8 exit fails during system
resume, both ufshcd_err_handler() and __ufshcd_wl_resume() call
ufshcd_link_recovery(), and the two recoveries are not serialized.
Patch 1 makes ufshcd_link_recovery() clear the saved errors like
ufshcd_reset_and_restore() does, so the error handler does not act on
errors that have already been recovered.
Patch 2 skips the early link recovery in ufshcd_err_handler(), which
does not hold host_sem, while a system PM operation is in progress. The
system PM callbacks hold host_sem, so the error handler now waits for
them.
The early link recovery is kept for runtime PM, shutdown and poweroff,
which do not hold host_sem. During runtime resume it can still run
concurrently with __ufshcd_wl_resume(). Removing it there needs a closer
look at the deadlock that it avoids.
Changes in v5:
- Patch 2: track system PM (hba->system_pm_in_progress) instead of
runtime PM, so that the early link recovery is only skipped where
host_sem is held. ufshcd_wl_poweroff() holds neither host_sem nor sets
hba->shutting_down, so poweroff keeps the early link recovery as
before (Sashiko review).
Changes in v4 (as suggested by Bart Van Assche):
- Replace the is_sys_suspended check of v3 patch 2 with a flag set in
__ufshcd_wl_suspend() and __ufshcd_wl_resume(), which also covers a
system suspend failure.
- Add Fixes: tags.
- Do not serialize ufshcd_link_recovery() with a mutex: it calls
ufshcd_probe_hba(), and a device command timing out inside it ends up
in ufshcd_eh_timed_out(), which calls ufshcd_link_recovery() again.
Changes in v3:
- Patch 2: reword the commit message only, no code change. The error
handler does not always run a full recovery after a failed system
resume; it stops according to ufshcd_err_handling_should_stop() (e.g.
in UFSHCD_STATE_ERROR). Describe this behavior and refer to the commit
that added the early link recovery (Sashiko review).
- Patch 1: no change.
Changes in v2:
- Add patch 1. As pointed out by the Sashiko review, saved_err and
saved_uic_err are still set after the resume path recovered the link,
so with v1 alone ufshcd_err_handler() would run a redundant recovery
once host_sem is released.
- Patch 2: describe the race and the system/runtime PM difference in
the commit message, and add a comment.
v4: https://lore.kernel.org/linux-scsi/cover.1793851432.git.hy50.seo@samsung.com/
v3: https://lore.kernel.org/linux-scsi/cover.1792989286.git.hy50.seo@samsung.com/
v2: https://lore.kernel.org/linux-scsi/cover.1792755091.git.hy50.seo@samsung.com/
HOYOUNG SEO (2):
scsi: ufs: core: Clear saved errors in ufshcd_link_recovery
scsi: ufs: core: Do not recover the link early in the error handler
during system PM
drivers/ufs/core/ufshcd.c | 25 +++++++++++++++++++++++--
include/ufs/ufshcd.h | 2 ++
2 files changed, 25 insertions(+), 2 deletions(-)
--
2.34.1
next parent reply other threads:[~2026-11-05 8:01 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20261105080058epcas2p33d17a4cc3163920fd24a3c378f21e3ae@epcas2p3.samsung.com>
2026-11-05 7:56 ` HOYOUNG SEO [this message]
2026-11-05 7:56 ` [PATCH v5 1/2] scsi: ufs: core: Clear saved errors in ufshcd_link_recovery HOYOUNG SEO
2026-11-05 7:56 ` [PATCH v5 2/2] scsi: ufs: core: Do not recover the link early in the error handler during system PM HOYOUNG SEO
2026-11-05 8:14 ` sashiko-bot
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=cover.1793865172.git.hy50.seo@samsung.com \
--to=hy50.seo@samsung.com \
--cc=alim.akhtar@samsung.com \
--cc=bvanassche@acm.org \
--cc=cpgs@samsung.com \
--cc=h10.kim@samsung.com \
--cc=kwangwon.min@samsung.com \
--cc=kwmad.kim@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=mkp@kernel.org \
--cc=stanleyjhu@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.