Messages in this thread | | | Subject | Re: [PATCH] rfkill: clarify usage of rfkill_force_state() and rfkill->get_state() | Date | Thu, 18 Sep 2008 19:32:58 +0200 | From | Ivo van Doorn <> |
| |
On Thursday 18 September 2008, Johannes Berg wrote: > On Thu, 2008-09-18 at 13:43 -0300, Henrique de Moraes Holschuh wrote: > > > Now it must do something like this in pseudo-code: > > > > 1. if (the bit is disabled (i.e. SW rfkill is NOT ACTIVE)) { > > rfkill-SW-status = disabled; > > } else if (the bit is enabled (i.e. SW rfkill is ACTIVE)) { > > if (tx power off is NOT ACTIVE) > > rfkill-SW-status = enabled; > > else > > rfkill-SW-status = whatever the user asked > > } > > > > THEN, it should use rfkill-sw-status, along with the hw rfkill line status, > > to synthesize the state it must pass to rfkill_force_status(). > > > > ICK. Of course, if the driver has another way to implement txpower off that > > does not clash with sw rfkill, the above is unneeded. > > Why are we not handling soft-rfkill in mac80211 entirely?
Ideal situation would indeed be that mac80211 registers a rfkill structure and listens to rfkill events. This would help drivers by only needing to register a rfkill structure for state-change events without any need for listeners.
I was considering such a patch some time ago, but needed to figure out how to work with the state-override capabilities (HW_BLOCK and SOFT_BLOCK) and didn't work on it any further since.
Ivo
| |