rfkill get_state

rfkill get_state

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 260 bytes --]

When you implement get_state but don't do force_state, how does
get_state ever get called?

It seems to me it'll only get called 
 * when you read sysfs
 * on resume
 * on epo

How do we ever react to a button press then to make a uevent?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: rfkill get_state

[Henrique de Moraes Holschuh]

On Fri, 27 Mar 2009, Johannes Berg wrote:
> When you implement get_state but don't do force_state, how does
> get_state ever get called?
> 
> It seems to me it'll only get called 
>  * when you read sysfs
>  * on resume
>  * on epo

Yes.  It is mostly something that the rfkill core uses to get an up-to-date
state when it knows it needs one, and it is not good for anything else.

> How do we ever react to a button press then to make a uevent?

rfkill-related uevents exist to signal change in state of the rfkill
switches, REGARDLESS of the reason.  So they are NOT related to button
presses, except in-so-far that a button press might have changed a rfkill
switch state.

So, the short answer is: rfkill_force_state().  Call it when the radio
rfkill state changed, and the core will generate uevents.

The core doesn't have any helpers for this, so if you need polling, for
example, you do it in your driver and call rfkill_force_state() as needed.


Where does the button press enters the picture in your driver?  Knowing
that, I can illustrate how it would plug to rfkill core, or to the input
device core (I am yet to see a case where it should be plugged to both).

-- 
  "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

Re: rfkill get_state

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1793 bytes --]

On Fri, 2009-03-27 at 12:08 -0300, Henrique de Moraes Holschuh wrote:

> > It seems to me it'll only get called 
> >  * when you read sysfs
> >  * on resume
> >  * on epo
> 
> Yes.  It is mostly something that the rfkill core uses to get an up-to-date
> state when it knows it needs one, and it is not good for anything else.

Ouch, ok.

> > How do we ever react to a button press then to make a uevent?
> 
> rfkill-related uevents exist to signal change in state of the rfkill
> switches, REGARDLESS of the reason.  So they are NOT related to button
> presses, except in-so-far that a button press might have changed a rfkill
> switch state.

STOP WRITING ALL CAPS PLEASE. Look, I know that rfkill is related to the
button press, if that button affects the hw kill state.

> So, the short answer is: rfkill_force_state().  Call it when the radio
> rfkill state changed, and the core will generate uevents.

You do realise though that none of the platform drivers actually call
that, right?

> The core doesn't have any helpers for this, so if you need polling, for
> example, you do it in your driver and call rfkill_force_state() as needed.

OK -- IMHO the only reasonable thing is to actually add polling if
get_state is assigned -- anything else is pointless. I also don't see
how get_state is actually needed, drivers can just use force_state after
suspend/resume etc.

> Where does the button press enters the picture in your driver?  Knowing
> that, I can illustrate how it would plug to rfkill core, or to the input
> device core (I am yet to see a case where it should be plugged to both).

I'm not actually interested in a driver. I need to integrate rfkill into
mac80211, and for that I need to rewrite it to have a usable API.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]