Hi, this series removes the in_interrupt() usage in the orinoco driver which is the last one in drivers/net. The series preserves the current status based on the context I saw during the review. The proper way dealing with this would be to use a mutex_t as another lock and split the current usage of orinoco_lock() and push some of the callers into a worker where an immediate answer is not needed. This would allow to always block on the completion and so avoid the polling. The problem with the current approach / polling in BH context is that USB HCDs which marked with HCD_BH (EHCI/XHCI) will complete the URB in tasklet/BH context. The URB's callback (that part that completes completion which is being polled for) will obviously not be invoked if the driver polls with the orinoco_private::lock acquired which disables BH. The only way it may work is if the USB HCD does not set HCD_BH or the HCD IRQ fires on a different CPU. A lot of the "BH" usage comes from the orinoco_lock(). The other callers are fully preemtible. I didn't look how many of the callers, that disable BH via orinoco_lock(), are already in atomic context due to another lock, timer or so. I'm afraid I make it worse by missing something subtle. This might still work on a OHCI/UHCI controller. Sebastian
