Re: rfkill get_state

[Johannes Berg <johannes@sipsolutions.net>]

[-- 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 --]