LKML Archive on
help / color / mirror / Atom feed
From: Henrique de Moraes Holschuh <>
To: Alan Jenkins <>
Cc: Matthew Garrett <>,
	linux-kernel <>,
	linux acpi <>
Subject: Re: eeepc-laptop rfkill, stupid question #4 and 5
Date: Sun, 2 Nov 2008 02:00:08 -0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Fri, 31 Oct 2008, Alan Jenkins wrote:
> > Documentation/rfkill.txt implied otherwise

Then we need to make it more clear.

> >     You should:
> >         - rfkill_allocate()
> >         - modify rfkill fields (flags, name)
> >         - modify state to the current hardware state (THIS IS THE ONLY TIME
> >           YOU CAN ACCESS state DIRECTLY)
> >         - rfkill_register()

At which point rfkill core will KICK your device to the state it wants it to
be, so if you lied on the state, you are screwed. I mean it.

You want rfkill_set_default(), and only because it is a platform driver
storing state across shutdown.

> > Admittedly it doesn't say "and I promise not to gratuitously override
> > the state on registration".  Buti t seems weird though, to override the
> > value on registration 

No, it is EXACTLY what it should do.  It is setting policy for a class of
switches (actually, controllers. Call it a switch and you confuse it with
input devices).  It is not "enabling the radio" by default, it is setting
the radio rfkill controllers to the same state that all other rfkill
controllers on radios of that type currently are at.

And there is rfkill_set_default() for *platform* drivers to influence that,
when the platform has a better idea of the proper initial radio rfkill

> Ah, I see.  Wrong end - of course the *rfkill device* doesn't have
> useful state.  The persistent state belongs to the *rfkill switch* - it
> could even be a physical switch.

Of course it has useful state. Set it to whatever the rfkill controller
state really IS at that point.  And it HAS persistent state, but the core
will govern it to match the system-wide policy.

> And now it's clear what was missing from the conversion to rfkill:
>     2. Input device switches (sources of EV_SW events) DO store their
>     current state
>     (so you *must* initialize it by issuing a gratuitous input layer
>     event on
>     driver start-up and also when resuming from sleep)


You *ARE* to send gratuitous input layer events for SWITCHES quite often,
e.g. on every call to the switche's connect() handler, and also often after
system-wide stuff like resume (when state could have changed without you
being able to notice it) because you *HAVE* to tell the input layer which is
the initial/real state of the switch.  If this is not clear, the input layer
needs some doc tweaking. Please feel free to send a patch to Dmitry.

But that has nothing to do with the rfkill core.  You MUST NEVER try to
change rfkill core state through the input layer from inside the kernel.

rfkill_input is NOT part of the rfkill core, and rfkill_input is the ONLY
thing that cares about input events that match one of the "rfkill" input
events.  And it *is* optional.

  "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

  reply	other threads:[~2008-11-02  4:00 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-31 17:09 Alan Jenkins
2008-10-31 17:11 ` Matthew Garrett
2008-10-31 17:27   ` Alan Jenkins
2008-10-31 20:54     ` Alan Jenkins
2008-11-02  4:00       ` Henrique de Moraes Holschuh [this message]
2008-11-02 11:17         ` eeepc-laptop rfkill, stupid question #4 Alan Jenkins
2008-11-02 13:06           ` Matthew Garrett
2008-11-02 13:25             ` Alan Jenkins
2008-11-02 13:26               ` Matthew Garrett
2008-11-03 14:47               ` Henrique de Moraes Holschuh
2008-11-03 14:16             ` Henrique de Moraes Holschuh
2008-11-03 14:18               ` Matthew Garrett
2008-11-03 14:29                 ` Alan Jenkins
2008-11-03 14:51                   ` Henrique de Moraes Holschuh
2008-11-03 14:55                     ` Matthew Garrett
2008-11-03 15:02                       ` Henrique de Moraes Holschuh
2008-11-03 15:08                         ` Matthew Garrett
2008-11-03 16:33                           ` Henrique de Moraes Holschuh
2008-11-03 18:00                             ` rfkill, stupid question #6 Alan Jenkins
2008-11-03 19:06                               ` Henrique de Moraes Holschuh
2008-11-04 15:48                             ` eeepc-laptop rfkill, stupid question #4 Luiz Fernando N. Capitulino
2008-11-04 15:57                               ` Alan Jenkins
2008-11-02  3:46   ` eeepc-laptop rfkill, stupid question #4 and 5 Henrique de Moraes Holschuh
2008-11-02  9:21     ` Matthew Garrett

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \
    --subject='Re: eeepc-laptop rfkill, stupid question #4 and 5' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).