mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Bart Van Assche <bvanassche@acm.org>
To: Peter Wang <peter.wang@mediatek.com>,
	Stanley Jhu <stanleyjhu@google.com>
Cc: "Martin K. Petersen" <mkp@kernel.org>,
	"James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>,
	Alim Akhtar <alim.akhtar@samsung.com>,
	Avri Altman <avri.altman@sandisk.com>,
	Bean Huo <beanhuo@micron.com>, Can Guo <can.guo@oss.qualcomm.com>,
	Manivannan Sadhasivam <mani@kernel.org>,
	linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] scsi: ufs: core: Release command resources instead of force-completing
Date: Tue, 22 Sep 2026 09:34:48 -0700	[thread overview]
Message-ID: <89e1ae39-dc01-46c6-b126-a7175847910d@acm.org> (raw)
In-Reply-To: <6288ff21af758e0f3739edb6c33abe3bfbdba3dd.camel@mediatek.com>

On 9/21/26 8:03 PM, Peter Wang wrote:
> It appears unreasonable to wait for the entire 30 second timeout,
> as many UIC errors recover promptly. The resulting 30 second stall
> would manifest as a noticeable UI freeze. Maybe we shouldn’t let
> eh_host_reset_handler call the EH handler at all?
The default SCSI disk timeout is 30 seconds. That default timeout was
chosen when hard disks were the most widely used persistent storage
medium and before NAND storage became widespread. Isn't that default
timeout too big for UFS devices?

As mentioned in another email, .eh_host_reset_handler() must abort
all pending commands and must terminate all ongoing task management
functions. This implies resetting both the UFS device and the UFS
host controller. I'm not sure how to do that without calling
ufshcd_host_reset_and_restore()?

Thanks,

Bart.

  reply	other threads:[~2026-09-22 16:34 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-20 14:33 [PATCH 0/2] scsi: ufs: core: Fix SCSI EH command ownership and remove force_compl Stanley Jhu
2026-09-20 14:33 ` [PATCH 1/2] scsi: ufs: core: Release command resources instead of force-completing Stanley Jhu
2026-09-21  0:41   ` Bart Van Assche
2026-09-21  4:37     ` Stanley Jhu
2026-09-21 16:51       ` Bart Van Assche
2026-09-22  3:03         ` Peter Wang
2026-09-22 16:34           ` Bart Van Assche [this message]
2026-09-20 14:33 ` [PATCH 2/2] scsi: ufs: core: Remove unused force_compl parameter and MCQ helper Stanley Jhu

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=89e1ae39-dc01-46c6-b126-a7175847910d@acm.org \
    --to=bvanassche@acm.org \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=alim.akhtar@samsung.com \
    --cc=avri.altman@sandisk.com \
    --cc=beanhuo@micron.com \
    --cc=can.guo@oss.qualcomm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=mani@kernel.org \
    --cc=mkp@kernel.org \
    --cc=peter.wang@mediatek.com \
    --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 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®