> This makes it hard to use for USB drivers. The need to hold a mutex > was the precise reason the sierra driver got the opened flag protected > with a spinlock. The problem is that it isn't a meaningful question to ask in many ways because you can get an IRQ while opening while closing, or indeed if a CPU is stalled by something a close and reopen on one CPU while the other handles the IRQ event. The same in many ways is true of ASYNCB_INITIALIZED - a valid answer to the mid IRQ question of "are we open at the moment" is "yes, no, yes, no, yes, no" - so there has to be serialization or it has to be handled in a more logical place. > down call usb_kill_urb() is used which prevents a resubmission. If a completion > handler submits another URB, as at least one driver does, things get hairy. > It seems to me that you best set a flag for an ongoing closure for these > drivers. You have to clean them up anyway because they can be issued as a port goes open to closed or closed to open. > In fact for the common case it would be simplest but brutal to unconditionally > resubmit and be prepared to deal with -EPERM returned from usb_submit_urb() I suspect that is the way to handle it for all the cases. You need to lock the list of URBS that are live for the complex ones but that is true anyway or you don't know what to usb_kill_urb() on -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
