linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
To: Dmitry Baryshkov <dbaryshkov@gmail.com>
Cc: linux-wireless@vger.kernel.org
Subject: Re: [PATCH 04/13] rfkill: add parameter to disable radios by default
Date: Tue, 24 Jun 2008 14:07:55 -0300	[thread overview]
Message-ID: <20080624170755.GA17576@khazad-dum.debian.net> (raw)
In-Reply-To: <g3quvb$8sa$1@ger.gmane.org>

On Tue, 24 Jun 2008, Dmitry Baryshkov wrote:
> Henrique de Moraes Holschuh wrote:
> > Currently, radios are always enabled when their rfkill interface is
> > registered.  This is not optimal, the safest state for a radio is to be
> > offline unless the user turns it on.
> > 
> > Add a module parameter that causes all radios to be disabled when their
> > rfkill interface is registered.  The module default is not changed so
> > unless the parameter is used, radios will still be forced to their
> > enabled state when they are registered.
> > 
> > The new rfkill module parameter is called "default_state".
> 
> Why not add the possibility for each rfkill-enabled radio to supply it's 
> default state?

The radios already can, and should, inform rfkill of their power-up state
(set rfkill->state before calling rfkill_register), but if it is different
from the global state, rfkill will try to adjust it to match the rest of the
system.

When you implement rfkill support on your wireless driver, you transfer all
policy decisions about rfkill state to the rfkill system.

That's how it is supposed to work.  If you have all radios blocked,
hotplugging a new one will cause it to be blocked by rfkill soon after it
registers itsef.  If you have bluetooth unblocked, when you hotplug a new
bluetooth radio, rfkill will unblock it when it registers itself.

If you mean you'd like to be able to use kernel parameters to set the
default state for each radio type separately, the first version of the patch
did just that, but it was vetoed and I was asked to use a single parameter.

This doesn't mean the system doesn't control the radios on a per-type basis,
it does.  It is just that you can only tell it to start with every radio
BLOCKED by default, or to start with every radio UNBLOCKED by default,
regardless of type.

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

  parent reply	other threads:[~2008-06-24 17:08 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-23 20:22 [GIT PATCH] rfkill rework for 2.6.27 (v3) Henrique de Moraes Holschuh
2008-06-23 20:22 ` [PATCH 01/13] rfkill: clarify meaning of rfkill states Henrique de Moraes Holschuh
2008-06-23 20:22 ` [PATCH 02/13] rfkill: fix minor typo in kernel doc Henrique de Moraes Holschuh
2008-06-23 20:22 ` [PATCH 03/13] rfkill: handle SW_RFKILL_ALL events Henrique de Moraes Holschuh
2008-06-23 20:22 ` [PATCH 04/13] rfkill: add parameter to disable radios by default Henrique de Moraes Holschuh
2008-06-24 14:05   ` Dmitry Baryshkov
2008-06-24 17:06     ` Fabien Crespel
2008-06-24 17:56       ` Dan Williams
2008-06-24 20:29         ` Fabien Crespel
2008-06-24 21:49           ` Dan Williams
2008-06-25  7:23             ` Fabien Crespel
2008-06-24 23:17       ` Henrique de Moraes Holschuh
2008-06-25  8:11         ` Fabien Crespel
2008-06-25 14:02           ` Henrique de Moraes Holschuh
2008-06-24 17:07     ` Henrique de Moraes Holschuh [this message]
2008-06-23 20:23 ` [PATCH 05/13] rfkill: add read-write rfkill switch support Henrique de Moraes Holschuh
2008-06-23 20:23 ` [PATCH 06/13] rfkill: add the WWAN radio type Henrique de Moraes Holschuh
2008-06-23 20:23 ` [PATCH 07/13] rfkill: rework suspend and resume handlers Henrique de Moraes Holschuh
2008-06-23 20:23 ` [PATCH 08/13] rfkill: add notifier chains support Henrique de Moraes Holschuh
2008-06-23 20:23 ` [PATCH 09/13] rfkill: add type string helper Henrique de Moraes Holschuh
2008-06-23 20:23 ` [PATCH 10/13] rfkill: add uevent notifications Henrique de Moraes Holschuh
2008-06-23 20:23 ` [PATCH 11/13] rfkill: drop current_state from tasks in rfkill-input Henrique de Moraes Holschuh
2008-06-23 20:49   ` Ivo van Doorn
2008-06-23 20:23 ` [PATCH 12/13] rfkill: do not allow userspace to override ALL RADIOS OFF Henrique de Moraes Holschuh
2008-06-23 20:23 ` [PATCH 13/13] rfkill: document rw rfkill switches and clarify input subsystem interactions Henrique de Moraes Holschuh
2008-06-26 13:13 ` [GIT PATCH] rfkill rework for 2.6.27 (v3) Dmitry Baryshkov

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=20080624170755.GA17576@khazad-dum.debian.net \
    --to=hmh@hmh.eng.br \
    --cc=dbaryshkov@gmail.com \
    --cc=linux-wireless@vger.kernel.org \
    /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 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).