> From: gregkh@xxxxxxxxxxxxxxxxxxx <gregkh@xxxxxxxxxxxxxxxxxxx>
> On Tue, Sep 05, 2023 at 08:53:43AM +0000, Wu, Wentong wrote:
> > > 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?
>
> Please relax, we can't do anything until after -rc1 is out, and for me, that
> includes reviewing the code.
Thanks for your review.
>
> There is no rush, or deadline, here at all. It will be merged when it is acceptable.
Understood, thanks
BR,
Wentong
>
> thanks,
>
> greg k-h
