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? Thanks, -yi -- 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
