I tried to figure out if the URB-completion handler uses any locking and
stumbled here.
i2400m_pm_notifier() is called from process context. This function
invokes i2400m_fw_cache() + i2400m_fw_uncache(). Both functions do
spin_lock(&i2400m->rx_lock);
while in other places (say i2400mu_rxd()) it does
spin_lock_irqsave(&i2400m->rx_lock, flags);
So what do I miss? Is this lock never used in interrupt context and
lockdep didn't complain or did nobody try suspend with this driver
before?
>From what I can tell i2400m_dev_bootstrap() has the same locking
problem.
While here, I noticed that i2400m_fw_cache() does use GFP_ATOMIC which
should be GFP_KERNEL since the context can't be atomic at this point
(there is even request_firmware() later on).
I am also curious why there is NULL and ~0 because it does not seem to
make a difference in i2400m_fw_uncache() but I'm more interested in
the locking bits :)
Sebastian
