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)? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- 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
