Hi Oliver,
Thanks for your review
> From: Oliver Neukum <oneukum@xxxxxxxx>
> On 04.09.23 15:52, Wu, Wentong wrote:
> >> From: Oliver Neukum <oneukum@xxxxxxxx>
>
> >> And we execute this. rx_urb is killed and does nothing.
> >> I see nothing that terminates the waiting if you hit the wrong window.
> >
> > I think the auxiliary_device_delete will trigger the remove function
> > of ljca client in his own sub system, and the delete() or remove() of
> > every subsystem will not return until the ongoing transfer(probably
> > blocked by above
> > cmd_completion) complete. And that also makes sure no more transfers
> > comes to there.
>
> Sure, you will not free used memory. But what allows you to be sure that you make any progress at all?
>
> That is that you will hang arbitrarily long in disconnect?
This routine isn't called in an interrupt context, and it allows sleep or wait
something before the real shutdown like many drivers' remove() or
disconnect() do.
If we want to speed up the disconnect(), below changes is to complete the
cmd_completion if usb_kill_urb() has been called, but there is still possibility
ljca client init one more transfer before auxiliary_device_delete()
@@ -206,7 +206,11 @@ static void ljca_recv(struct urb *urb)
if (urb->status) {
/* sync/async unlink faults aren't errors */
- if (urb->status == -ENOENT || urb->status == -ECONNRESET ||
+ if (urb->status == -ENOENT) {
+ complete(&adap->cmd_completion);
+ return;
+ }
+ if (urb->status == -ECONNRESET ||
urb->status == -ESHUTDOWN)
return;
perhaps we could add one more 'status' field in ljca_adapter to represent
disconnect() happen or not, and it will be checked in the beginning of
ljca_send() to avoid any new transfer.
BR,
Wentong
>
> Regards
> Oliver
