On Wed, 02 Jul 2008, Ivo van Doorn wrote: > 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... Would it be worth it to use a hybrid scheme? Callbacks and the notify chain would remain in task context, while the locking is changed to spinlocks so that it can also work in interrupt context when needed. We document better (in the text documentation, include files and kernel-doc) the contextes so that people don't get confused by the code and think that a spinlock means atomic context is OK for these handlers. For rfkill_force_state(), we'd either add a flags parameter that can take, e.g., GFP_ATOMIC, to tell us whether it is being called from an interrupt handler or a task context, or we could simply add rfkill_force_state_atomic(). This would be safer (because the state would still be updated synchronously when one calls rfkill_force_state(_atomic)?) than adding a rfkill_schedule_force_state() for drivers to call in interrupt context. So far, the only function I can see that would have to work in interrupt/atomic context would be rfkill_force_state_atomic. -- "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
