On Wednesday 02 July 2008, Henrique de Moraes Holschuh wrote: > On Wed, 02 Jul 2008, Zhu Yi wrote: > > On Tue, 2008-07-01 at 13:56 -0300, Henrique de Moraes Holschuh wrote: > > > On Tue, 01 Jul 2008, Adel Gadllah wrote: > > > > The calls to iwl|iwl3945_rfkill_set_hw_state() had to be moved > > > because rfkill_force_state() cannot be called from an atomic context. > > > > Yes, but what your patch changed is not in the atomic context. It is > > just inside the driver's priv->mutex. I don't see any problem if you > > call rfkill_force_state() inside it. > > > > > Yeah, the joys of mutexes. If this is going to be a severe annoyance > > > to drivers, I don't see why rfkill could not be changed to use some > > > other locking primitive that does work on atomic contexes. > > > > Allowing rfkill_force_state() to be called in the atomic context would > > be useful especially for hardware rfkill. Devices (i.e iwl4965) receive > > an interrupt when the hw-rfkill state changes. It's natural to update > > the rfkill state in this context. > > > > How about protect the rfkill->state by a spinlock and put the > > notifier_call_chain() into a workqueue in the rfkill subsystem? > > That shouldn't be a problem. What are the spinlock primitives I should be > using on rfkill_force_state so that it would be compatible with most drivers > (and not cause issues when called in task context instead of interrupt > context)? Well actually it isn't that easy, the lock would also be used for the state change callback function toward the driver. And if that is done under a spinlock, USB drivers will start complaining since they can't access the hardware under atomic context... Ivo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
