On Mon, Dec 11, 2017 at 01:44:57PM +0100, Ladislav Michl wrote: > On Mon, Dec 11, 2017 at 12:52:46PM +0100, Johan Hovold wrote: > > 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: > [snip] > > > > 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. > > I just do not see this in code. I would expect pending tty I/O operation > would fail once USB device errors out with -EPIPE, so tty side consumer gets > notified about error. Either it is not there or I did not look hard enough :) No, we do not provide any error notification besides logging an error when an endpoint has been stalled (i.e. in case of a read, you would not receive any more data before the halt condition has been cleared). Given that there's been no reports about this being an issue (for the past ten years and that I can recall), this crude handling appears to suffice. 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
