Locking in carl9170

[Sebastian Andrzej Siewior <bigeasy@linutronix.de>]

I've been locking at the USB completion handler and stumbled upon this
driver. The code path:
 carl9170_usb_rx_irq_complete()
 -> carl9170_handle_command_response()
  -> carl9170_cmd_callback()
     spin_lock(&ar->cmd_lock);

  -> carl9170_update_beacon()
      spin_lock_bh(&ar->beacon_lock);

  -> carl9170_tx_process_status()
   -> __carl9170_tx_process_status()
    -> carl9170_get_queued_skb()
       spin_lock_bh(&queue->lock);

      -> carl9170_release_dev_space()
         spin_lock_bh(&ar->mem_lock);
…

I planned to make all locks use spin_lock_irqsave().
carl9170_usb_rx_irq_complete() is called by HCD's completion handler
which is invoked mostly in IRQ context except for EHCI/DWC2 which invoke
the completion callback in tasklet/BH context. Currently there is a
local_irq_save() before invoking the ->complete callback which I plan to
remove, therefore the push-down. The _irqsave() would reflect the
current status. 
The locks I mentioned use only the _bh() suffix in other places. I
*think* lockdep is not complaining about this on EHCI but should
complain on other controllers which really complete in IRQ-context.
Could you please check if this is the case?

Sebastian