lkml.org 
[lkml]   [2008]   [Sep]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] rfkill: clarify usage of rfkill_force_state() and rfkill->get_state()
Date
From
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


\
 
 \ /
  Last update: 2008-09-18 19:35    [W:0.037 / U:1.212 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site