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.
There is no rush, or deadline, here at all. It will be merged when it
is acceptable.
thanks,
greg k-h
