On Fri, 2019-07-05 at 10:08 -0400, Alan Stern wrote: > 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? I think just stop it until the next reset yes. > > > 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... Haha, I wish I didn't have that problem too :) Cheers, Ben.
