* USB: serial: ti_usb_3410_5052: Avoid goto in bulk in callback
@ 2017-12-11 11:52 Johan Hovold
0 siblings, 0 replies; 8+ messages in thread
From: Johan Hovold @ 2017-12-11 11:52 UTC (permalink / raw)
To: Ladislav Michl; +Cc: Johan Hovold, linux-usb
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@linux-mips.org>
> > > ---
> > > 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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 8+ messages in thread
* USB: serial: ti_usb_3410_5052: Avoid goto in bulk in callback
@ 2017-12-13 11:50 Johan Hovold
0 siblings, 0 replies; 8+ messages in thread
From: Johan Hovold @ 2017-12-13 11:50 UTC (permalink / raw)
To: Ladislav Michl; +Cc: Johan Hovold, linux-usb
On Wed, Dec 13, 2017 at 12:32:47PM +0100, Ladislav Michl wrote:
> On Wed, Dec 13, 2017 at 12:16:05PM +0100, Johan Hovold wrote:
> > 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).
>
> Hmm, could we make 1aba579f3cf5 a 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).
> > 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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 8+ messages in thread
* USB: serial: ti_usb_3410_5052: Avoid goto in bulk in callback
@ 2017-12-13 11:32 Ladislav Michl
0 siblings, 0 replies; 8+ messages in thread
From: Ladislav Michl @ 2017-12-13 11:32 UTC (permalink / raw)
To: Johan Hovold; +Cc: linux-usb
On Wed, Dec 13, 2017 at 12:16:05PM +0100, Johan Hovold wrote:
> 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).
Hmm, could we make 1aba579f3cf5 a bit more generic then?
> 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.
Best regards,
ladis
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 8+ messages in thread
* USB: serial: ti_usb_3410_5052: Avoid goto in bulk in callback
@ 2017-12-13 11:16 Johan Hovold
0 siblings, 0 replies; 8+ messages in thread
From: Johan Hovold @ 2017-12-13 11:16 UTC (permalink / raw)
To: Ladislav Michl; +Cc: Johan Hovold, linux-usb
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 8+ messages in thread
* USB: serial: ti_usb_3410_5052: Avoid goto in bulk in callback
@ 2017-12-11 12:44 Ladislav Michl
0 siblings, 0 replies; 8+ messages in thread
From: Ladislav Michl @ 2017-12-11 12:44 UTC (permalink / raw)
To: Johan Hovold; +Cc: linux-usb
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 :)
> > > 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.
See above.
> Johan
Best regards,
ladis
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 8+ messages in thread
* USB: serial: ti_usb_3410_5052: Avoid goto in bulk in callback
@ 2017-12-11 11:32 Ladislav Michl
0 siblings, 0 replies; 8+ messages in thread
From: Ladislav Michl @ 2017-12-11 11:32 UTC (permalink / raw)
To: Johan Hovold; +Cc: linux-usb
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@linux-mips.org>
> > ---
> > drivers/usb/serial/ti_usb_3410_5052.c | 36 ++++++++++++++---------------------
> > 1 file changed, 14 insertions(+), 22 deletions(-)
> >
> > diff --git a/drivers/usb/serial/ti_usb_3410_5052.c b/drivers/usb/serial/ti_usb_3410_5052.c
> > index 6b22857f6e52..2786ec7bbca2 100644
> > --- a/drivers/usb/serial/ti_usb_3410_5052.c
> > +++ b/drivers/usb/serial/ti_usb_3410_5052.c
> > @@ -1219,29 +1219,10 @@ static void ti_bulk_in_callback(struct urb *urb)
> >
> > switch (status) {
> > case 0:
> > - break;
> > - case -ECONNRESET:
> > - case -ENOENT:
> > - case -ESHUTDOWN:
> > - dev_dbg(dev, "%s - urb shutting down, %d\n", __func__, status);
> > - return;
> > - default:
> > - dev_err(dev, "%s - nonzero urb status, %d\n",
> > - __func__, status);
> > - }
> > -
> > - if (status == -EPIPE)
> > - goto exit;
> > -
> > - if (status) {
> > - dev_err(dev, "%s - stopping read!\n", __func__);
> > - return;
> > - }
> > -
> > - if (urb->actual_length) {
> > + if (!urb->actual_length)
> > + break;
> > usb_serial_debug_data(dev, __func__, urb->actual_length,
> > urb->transfer_buffer);
> > -
> > if (!tport->tp_is_open)
> > dev_dbg(dev, "%s - port closed, dropping data\n",
> > __func__);
> > @@ -1250,9 +1231,20 @@ static void ti_bulk_in_callback(struct urb *urb)
> > spin_lock(&tport->tp_lock);
> > port->icount.rx += urb->actual_length;
> > spin_unlock(&tport->tp_lock);
> > + break;
> > + case -ECONNRESET:
> > + case -ENOENT:
> > + case -ESHUTDOWN:
> > + dev_dbg(dev, "%s - urb shutting down, %d\n", __func__, status);
> > + return;
> > + case -EPIPE:
> > + break;
> > + default:
> > + dev_err(dev, "%s - nonzero urb status, %d\n",
> > + __func__, status);
> > + return;
>
> 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.
> 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?
> Thanks,
> Johan
Thank you,
ladis
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 8+ messages in thread
* USB: serial: ti_usb_3410_5052: Avoid goto in bulk in callback
@ 2017-12-11 10:10 Johan Hovold
0 siblings, 0 replies; 8+ messages in thread
From: Johan Hovold @ 2017-12-11 10:10 UTC (permalink / raw)
To: Ladislav Michl; +Cc: linux-usb, Johan Hovold
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@linux-mips.org>
> ---
> drivers/usb/serial/ti_usb_3410_5052.c | 36 ++++++++++++++---------------------
> 1 file changed, 14 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/usb/serial/ti_usb_3410_5052.c b/drivers/usb/serial/ti_usb_3410_5052.c
> index 6b22857f6e52..2786ec7bbca2 100644
> --- a/drivers/usb/serial/ti_usb_3410_5052.c
> +++ b/drivers/usb/serial/ti_usb_3410_5052.c
> @@ -1219,29 +1219,10 @@ static void ti_bulk_in_callback(struct urb *urb)
>
> switch (status) {
> case 0:
> - break;
> - case -ECONNRESET:
> - case -ENOENT:
> - case -ESHUTDOWN:
> - dev_dbg(dev, "%s - urb shutting down, %d\n", __func__, status);
> - return;
> - default:
> - dev_err(dev, "%s - nonzero urb status, %d\n",
> - __func__, status);
> - }
> -
> - if (status == -EPIPE)
> - goto exit;
> -
> - if (status) {
> - dev_err(dev, "%s - stopping read!\n", __func__);
> - return;
> - }
> -
> - if (urb->actual_length) {
> + if (!urb->actual_length)
> + break;
> usb_serial_debug_data(dev, __func__, urb->actual_length,
> urb->transfer_buffer);
> -
> if (!tport->tp_is_open)
> dev_dbg(dev, "%s - port closed, dropping data\n",
> __func__);
> @@ -1250,9 +1231,20 @@ static void ti_bulk_in_callback(struct urb *urb)
> spin_lock(&tport->tp_lock);
> port->icount.rx += urb->actual_length;
> spin_unlock(&tport->tp_lock);
> + break;
> + case -ECONNRESET:
> + case -ENOENT:
> + case -ESHUTDOWN:
> + dev_dbg(dev, "%s - urb shutting down, %d\n", __func__, status);
> + return;
> + case -EPIPE:
> + break;
> + default:
> + dev_err(dev, "%s - nonzero urb status, %d\n",
> + __func__, status);
> + return;
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.
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.
Thanks,
Johan
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 8+ messages in thread
* USB: serial: ti_usb_3410_5052: Avoid goto in bulk in callback
@ 2017-12-10 23:09 Ladislav Michl
0 siblings, 0 replies; 8+ messages in thread
From: Ladislav Michl @ 2017-12-10 23:09 UTC (permalink / raw)
To: linux-usb; +Cc: Johan Hovold
Make status handling in bulk in callback function more compact,
which renders goto pointless.
Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
---
drivers/usb/serial/ti_usb_3410_5052.c | 36 ++++++++++++++---------------------
1 file changed, 14 insertions(+), 22 deletions(-)
diff --git a/drivers/usb/serial/ti_usb_3410_5052.c b/drivers/usb/serial/ti_usb_3410_5052.c
index 6b22857f6e52..2786ec7bbca2 100644
--- a/drivers/usb/serial/ti_usb_3410_5052.c
+++ b/drivers/usb/serial/ti_usb_3410_5052.c
@@ -1219,29 +1219,10 @@ static void ti_bulk_in_callback(struct urb *urb)
switch (status) {
case 0:
- break;
- case -ECONNRESET:
- case -ENOENT:
- case -ESHUTDOWN:
- dev_dbg(dev, "%s - urb shutting down, %d\n", __func__, status);
- return;
- default:
- dev_err(dev, "%s - nonzero urb status, %d\n",
- __func__, status);
- }
-
- if (status == -EPIPE)
- goto exit;
-
- if (status) {
- dev_err(dev, "%s - stopping read!\n", __func__);
- return;
- }
-
- if (urb->actual_length) {
+ if (!urb->actual_length)
+ break;
usb_serial_debug_data(dev, __func__, urb->actual_length,
urb->transfer_buffer);
-
if (!tport->tp_is_open)
dev_dbg(dev, "%s - port closed, dropping data\n",
__func__);
@@ -1250,9 +1231,20 @@ static void ti_bulk_in_callback(struct urb *urb)
spin_lock(&tport->tp_lock);
port->icount.rx += urb->actual_length;
spin_unlock(&tport->tp_lock);
+ break;
+ case -ECONNRESET:
+ case -ENOENT:
+ case -ESHUTDOWN:
+ dev_dbg(dev, "%s - urb shutting down, %d\n", __func__, status);
+ return;
+ case -EPIPE:
+ break;
+ default:
+ dev_err(dev, "%s - nonzero urb status, %d\n",
+ __func__, status);
+ return;
}
-exit:
/* continue to read unless stopping */
spin_lock(&tport->tp_lock);
if (tport->tp_read_urb_state == TI_READ_URB_RUNNING)
^ permalink raw reply related [flat|nested] 8+ messages in thread
end of thread, other threads:[~2017-12-13 11:50 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-12-11 11:52 USB: serial: ti_usb_3410_5052: Avoid goto in bulk in callback Johan Hovold
-- strict thread matches above, loose matches on Subject: below --
2017-12-13 11:50 Johan Hovold
2017-12-13 11:32 Ladislav Michl
2017-12-13 11:16 Johan Hovold
2017-12-11 12:44 Ladislav Michl
2017-12-11 11:32 Ladislav Michl
2017-12-11 10:10 Johan Hovold
2017-12-10 23:09 Ladislav Michl
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.