On Mon, Dec 11, 2017 at 12:32:49PM +0100, Ladislav Michl wrote: > On Mon, Dec 11, 2017 at 11:10:35AM +0100, Johan Hovold wrote: > > On Mon, Dec 11, 2017 at 12:09:19AM +0100, Ladislav Michl wrote: > > > Make status handling in bulk in callback function more compact, > > > which renders goto pointless. > > > > > > Signed-off-by: Ladislav Michl <ladis@xxxxxxxxxxxxxx> > > > --- > > > drivers/usb/serial/ti_usb_3410_5052.c | 36 ++++++++++++++--------------------- > > > 1 file changed, 14 insertions(+), 22 deletions(-) > > I'm afraid I don't consider this an improvement. I prefer using gotos > > for error paths, while keeping the success path out of the status > > switch. > > > > Furthermore, this isn't functionally equivalent as we'd not longer log > > an error for -EPIPE. > > Yes, you are right... Now, shouldn't we react somehow to stalled endpoint? > Tty side seems to be unaware of it. Recovering from a stalled endpoint is a bit involved, so for now we typically just log an error an bail out (forcing the user to reopen the port). This seems to work well enough as this condition should be rare. > > In fact, that -EPIPE is already on my TODO list as we really should not > > be resubmitting URBs for a stalled endpoint in the first place. That in > > turn should allow for some clean up of this callback. > > Out of curiosity, how would be stalled endpoint reported? Simply logging that the urb has been stopped along with the URB status (-EPIPE) should be enough. Johan -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
