Hi Oliver,
Thanks for taking a look.

What allows the assumption that mctp_usb_open() does not race
with error handling? What happens if the device is still stalled?

When ndo_open is called, we know that the delayed rx work (which
performs the usb_clear_halt) has been quiesced, so aren't racing with
the actual recovery.

The device may still be stalled; that should be okay though, as we'll
detect that through the subsequent IN urb submission, which will re-set
->clear halt and schedule the rx work to do the clear.

Unless I have missed a case there?

Cheers,


Jeremy