From: Sergey Senozhatsky <senozhatsky@chromium.org>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Oliver Neukum <oneukum@suse.com>,
Alan Stern <stern@rowland.harvard.edu>,
linux-usb@vger.kernel.org, linux-scsi@vger.kernel.org,
usb-storage@lists.one-eyed-alien.net,
linux-kernel@vger.kernel.org, Tomasz Figa <tfiga@chromium.org>,
Sergey Senozhatsky <senozhatsky@chromium.org>
Subject: Re: [RFC PATCH] usb: storage: uas: limit consecutive device resets in error handling
Date: Wed, 1 Jul 2026 15:01:37 +0900 [thread overview]
Message-ID: <akSsw_iDneYb_4gQ@google.com> (raw)
In-Reply-To: <akSqd7HkrZI78_L_@google.com>
On (26/07/01 14:57), Sergey Senozhatsky wrote:
> On (26/07/01 07:38), Greg KH wrote:
> > > +static int uas_reset_limit = 3;
>
> This obviously wanted to be 0 by default (just a side note).
>
> > > +module_param_named(reset_limit, uas_reset_limit, int, 0644);
> > > +MODULE_PARM_DESC(reset_limit, "Maximum number of consecutive device resets during error handling before failing");
> >
> > This is not the 1990's, we do not add module parameters for issues that
> > should be properly solved either automatically, or on a per-device
> > basis.
> >
> > There's no way that ChromeOs wants to attempt to track this module
> > parameter as a bootline config option, right?
>
> Can you please elaborate on "properly solved either automatically,
> or on a per-device basis". I don't know how to break that endless
> reset loop otherwise. I'm open to any suggestions, the patch is RFC
> for a reason.
I can imagine uas_reset_limit being auto-calculated based on SCSI
timeout (30 seconds) and HUNG_TASK_TIMEOUT (if set). Will that
work? I don't know if all those timeouts can be clearly exposed
to the UAS driver (or should they be in the first place).
next prev parent reply other threads:[~2026-07-01 6:01 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-01 4:03 [RFC PATCH] usb: storage: uas: limit consecutive device resets in error handling Sergey Senozhatsky
2026-07-01 4:17 ` sashiko-bot
2026-07-01 4:31 ` Sergey Senozhatsky
2026-07-01 5:38 ` Greg KH
2026-07-01 5:57 ` Sergey Senozhatsky
2026-07-01 6:01 ` Sergey Senozhatsky [this message]
2026-07-01 8:28 ` [usb-storage] " Oliver Neukum
2026-07-02 2:25 ` Sergey Senozhatsky
2026-07-02 8:08 ` Oliver Neukum
2026-07-02 8:21 ` Sergey Senozhatsky
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=akSsw_iDneYb_4gQ@google.com \
--to=senozhatsky@chromium.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=oneukum@suse.com \
--cc=stern@rowland.harvard.edu \
--cc=tfiga@chromium.org \
--cc=usb-storage@lists.one-eyed-alien.net \
/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.