On 05.09.23 04:20, Wu, Wentong wrote:
Hi,
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.
It is, however, in the context of a kernel thread. We can wait, but not for
arbitrary periods.
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;
I'd say you'd break suspend() by such a change.
You cannot complete in the interrupt handler, unless you can determine
why the URB is killed.
+ }
+ 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.
That would be a solution.
Regards
Oliver
