linux-usb.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alan Stern <stern@rowland.harvard.edu>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Felipe Balbi <balbi@kernel.org>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	Michal Nazarewicz <mina86@mina86.com>
Subject: Re: Virtual hub, resets etc...
Date: Fri, 5 Jul 2019 10:08:47 -0400 (EDT)	[thread overview]
Message-ID: <Pine.LNX.4.44L0.1907051005410.1606-100000@iolanthe.rowland.org> (raw)
In-Reply-To: <03595b660f319d5fb958ccbacbfe51002bff2314.camel@kernel.crashing.org>

On Fri, 5 Jul 2019, Benjamin Herrenschmidt wrote:

> > > > As for f_mass_storage, repeatedly attempting to queue an OUT transfer
> > > > is normal behavior.  The fact that one attempt gets an error doesn't
> > > > stop the driver from making more attempts; the only thing that would
> > > > stop it is being disabled by a config change, a suspend, a disconnect,
> > > > or an unbind.
> > > 
> > > Except it does that in a tight loop and locks up the machine...
> > 
> > Well, that wouldn't happen if your UDC accepted the requests, right?  
> 
> Sure but it would be nice if the mass storage dealt with -ESHUTDOWN
> properly and stopped :-) Or other errors... if the UDC HW for example
> dies for some reason, mass storage will lockup.

I suppose we could add code to check for this case and handle it, 
although I'm not sure what would be the right thing to do.  Delay for 
one second and try again?  Disable the gadget until the host does a 
reset?

> > Besides, f_mass_storage won't repeatedly try to queue an OUT transfer 
> > once it knows that it is suspended.
> 
> Not afaik. But I might have missed something. I didn't see any suspend
> callback in f_mass_storage.c...

Oops, right.  Sorry about that; my memory is slowly decaying.  I need
to upgrade my brain's RAM...

Alan Stern


  reply	other threads:[~2019-07-05 14:08 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-04  5:52 Virtual hub, resets etc Benjamin Herrenschmidt
2019-07-04  8:02 ` f_mass_storage configuration races (Was: Virtual hub, resets etc...) Benjamin Herrenschmidt
2019-07-04  8:04   ` [PATCH] usb: gadget: mass_storage: Fix races between fsg_disable and fsg_set_alt Benjamin Herrenschmidt
2019-07-04 16:13 ` Virtual hub, resets etc Alan Stern
2019-07-04 21:44   ` Benjamin Herrenschmidt
2019-07-04 21:58     ` Benjamin Herrenschmidt
2019-07-05  1:37       ` Alan Stern
2019-07-05  2:15         ` Benjamin Herrenschmidt
2019-07-05 14:20           ` Alan Stern
2019-07-05 22:06             ` Benjamin Herrenschmidt
2019-07-05  1:34     ` Alan Stern
2019-07-05  2:08       ` Benjamin Herrenschmidt
2019-07-05 14:08         ` Alan Stern [this message]
2019-07-05 22:01           ` Benjamin Herrenschmidt
2019-07-06 18:37             ` Alan Stern
2019-07-06 23:44               ` Benjamin Herrenschmidt

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=Pine.LNX.4.44L0.1907051005410.1606-100000@iolanthe.rowland.org \
    --to=stern@rowland.harvard.edu \
    --cc=balbi@kernel.org \
    --cc=benh@kernel.crashing.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mina86@mina86.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;
as well as URLs for NNTP newsgroup(s).