All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ivo van Doorn <ivdoorn@gmail.com>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: Tomas Winkler <tomasw@gmail.com>,
	linville@tuxdriver.com, yi.zhu@intel.com, hmh@hmh.eng.br,
	linux-wireless@vger.kernel.org,
	Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Subject: Re: [PATCH RFC] mac80211: notify mac80211 about rfkill events
Date: Fri, 26 Sep 2008 20:18:40 +0200	[thread overview]
Message-ID: <200809262018.40777.IvDoorn@gmail.com> (raw)
In-Reply-To: <1222426905.10563.100.camel@johannes.berg>

On Friday 26 September 2008, Johannes Berg wrote:
> On Fri, 2008-09-26 at 01:05 +0300, Tomas Winkler wrote:
> 
> > > I am not sure if registring a notifier would be the best solution,
> > > persionally I was thinking of implementing the rfkill structure into ieee80211_local
> > > and make it listen to events directly.
> 
> I think I like this better.
> 
> > That's definitely other option we wanted to suggest that mac80211
> > would register itself to rfkill subsystem and will provide to driver
> > appropriate callbacks.  The question is how  drivers vary in the rfkil
> > implementation and whether it wouldn't be more complex, in that case
> > the notification is quite clean solution.
> 
> How complex does it have to be?

Not really, probably it only needs to be a wrapper around rfkill_force_state
where we can use the RFKILL_ defines to indicate the BLOCKED status.

> > > That means that the only change needed in ieee80211_ioctl_siwtxpower() is
> > > only allowing the enabling of the radio when RFKILL is not set to BLOCKED.
> > 
> > That's just complicates everything and moving the policy  decisions to
> > the driver after all even
> > form txpower off you implement it as soft rfkill.

Why does it complicate things? It means that mac80211 doesn't use
rfkill_force_state() when the user triggers a radio state change using
iw/iwconfig/ifconfig or whatever userspace tool.

mac80211 doesn't generate rfkill events because it isn't tied to any device
keys/buttons/sliders. That is what the drivers do. And they should only listen
to that key/button/slider.

> > I would suggest just remove the support for txpower off in mac80211
> > now when appropriate or sync it with soft block after all it coming
> > from user space as a software event.
> 
> I think what we should do is in mac80211 simply synthesize the
> "radio_enabled" state that the config callback has from both rfkill and
> txpower off. Anything wrong with that?

Come to think of it, there is a bug in the previous patch since it doesn't handle
the case when the interface is brought up during a BLOCKED state.

So all that has to be done is:
	* rfkill BLOCK event received in mac80211
	* set flag to indicate the BLOCKED state
	* disable radio
	* prevent radio being enabled through ifup
	* prevent radio being enabled through iwconfig txpower on

	* rfkill UNBLOCK event received from mac80211
	* clear flag to indicate UNBLOCKED state
	* restore radio to the by iwconfig/ifup configured state

Ivo

  parent reply	other threads:[~2008-09-26 18:18 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-25 15:48 [PATCH RFC] mac80211: notify mac80211 about rfkill events Tomas Winkler
2008-09-25 21:10 ` Ivo van Doorn
2008-09-25 22:05   ` Tomas Winkler
2008-09-26 11:01     ` Johannes Berg
2008-09-26 14:39       ` Dan Williams
2008-09-26 18:18       ` Ivo van Doorn [this message]
2008-09-26 23:25         ` Tomas Winkler
2008-09-27  8:12           ` Ivo van Doorn
2008-09-27 11:08             ` Tomas Winkler
2008-09-27 11:34               ` Ivo van Doorn
2008-09-28 19:49                 ` Tomas Winkler

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=200809262018.40777.IvDoorn@gmail.com \
    --to=ivdoorn@gmail.com \
    --cc=emmanuel.grumbach@intel.com \
    --cc=hmh@hmh.eng.br \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    --cc=tomasw@gmail.com \
    --cc=yi.zhu@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.