USB: serial: ti_usb_3410_5052: Avoid goto in bulk in callback
Quoted 24 lines · Ladislav Michl
Quoted 23 lines · Johan Hovold
Quoted 21 lines · Ladislav Michl
Quoted 2 lines · Johan Hovold
Quoted 1 line · Ladislav Michl
On Mon, Dec 11, 2017 at 11:10:35AM +0100, Johan Hovold wrote:
[snip]
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
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.Quoted 6 lines
Quoted 2 lines
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 :)
Quoted 5 lines
Quoted 3 lines
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).
Hmm, could we make
1aba579f3cf5a bit more generic then?
I'm not sure this is worth the complexity it adds, or that it really solves anything as the fundamental problem remains; simply clearing the Halt is not sufficient unless the underlying reason for the condition triggering the stall has first been removed (and that is going to be device specific).
Quoted 7 lines
Quoted 3 lines
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.
Because embedded people tend to power cycle stuck device on timeout. That involves project specific hacks in userspace, which could be probably handled better.
I haven't seen any reports of this being an issue (and your stalled CDC device was really due to a hardware/power issue IIRC) so again, I'm not convinced this gives us anything.
Johan
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html