On Thu, 18 Sep 2008, Ivo van Doorn wrote: > > rfkill_announce_softstate(OPEN/BLOCKED) > > rfkill_announce_hardstate(OPEN/BLOCKED) We could, but it wouldn't help much. WHEN you are allowed to call these (well, mostly rfkill_announce_softstat) is the real problem. And if you are forced to give both soft and hard states at once when you update the rfkill core state, you guard yourself against stuff messing with the rfkill state of your hardware behind your driver's back. > > and all the other junk happens there. And make sure this can be called > > from interrupts. > > I think that limitation came from the notifier_block functions, but > Henrique knows more about those details. No, it would not be that trivial, but it would be doable. Were that the only problem, I would have done that already. The problem is in the locking of rfkill->state, that is, rfkill->mutex. Changing rfkill->mutex to a spinlock would work, but the issue here is how much time rfkill->mutex spends locked. It can stay locked for a while, the longest path in the rfkill core includes a call to rfkill->get_state() plus a call to rfkill->toggle_radio(). And we have no idea what get_state() and toggle_radio() might need to do, or how much time would they take to do it. If someone could help with it, it would be really nice if we could somehow make unlocked access to rfkill->state safe... -- "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
