> From: Oliver Neukum <oneukum@xxxxxxxx>
>
> 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.
AFAIK, this is very common.
>
> > 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.
With below status field in ljca_adapter to determine if it's killed by disconnect().
If this is preferred, I could cook the patch for review.
If this is fixed, could you please help merge this usb-ljca driver so that it won't
block others which depends on this driver?
BR,
Wentong
>
> > + }
> > + 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
