Date:	Tue, 27 May 2008 20:13:33 +0200
From:	Ivo van Doorn <ivdoorn@...il.com>
To:	"Henrique de Moraes Holschuh" <hmh@....eng.br>
Cc:	linux-kernel@...r.kernel.org, "Thomas Renninger" <trenn@...e.de>,
	"Dmitry Torokhov" <dtor@...l.ru>
Subject: Re: [PATCH 14/15] rfkill: do not allow userspace to override ALL RADIOS OFF

On Tuesday 27 May 2008, Henrique de Moraes Holschuh wrote:
> On Tue, 27 May 2008 16:38:04 +0200, "Ivo van Doorn" <ivdoorn@...il.com> said:
> > > So yes, I do feel RFKILL_ALL is different, and it warrants EPO semanthics in
> > > the kernel, while all other rfkill events, such as KEY_WLAN, don't.
> > > 
> > > I don't feel strongly about not giving EPO semanthics to other rfkill events,
> > > but I recommend against giving anything else EPO semanthics in rfkill.
> > 
> > You just made my 2 laptops very happy because apparently they
> > don't behave like most keys do. ;)
> > 
> > Laptop 1)
> > 	- Key to control WLAN (Broadcom)
> > 	- Key to control Bluetooth (Broadcom??)
> > Laptop 2)
> > 	- Key to control WLAN (Intel)
> 
> You don't have a SW_RFKILL_ALL switch :-)   It is the same as my ThinkPad T43,
> it does *NOT* have a SW_RFKILL_ALL switch, and it has a wireless config hotkey,
> which is handled in firmware.  The firmware can wire-kill the Intel WLAN card,
> and it can also unplug(!) the internal Bluetooth device from the internal USB
> bus.
> 
> You'd typically assign KEY_WLAN or something else to those keys, but NOT a 
> (fictitious) KEY_RFKILL_ALL.

Exactly the point I wanted to make. ;)

> > With my first laptop, the broadcom WLAN driver will register the key, but
> > it doesn't know if it is alone or if Bluetooth hardware is also present. So
> > it cannot know if it is a master switch or not.
> 
> Correct.
> 
> This is *explicitly* documented by the patches.  The broadcomm driver has to assume
> it is a slave rfkill device, and NEVER report any input events.  It has no knowledge
> of which platform the broadcomm chip was installed into, after all.  OTOH, it *will*
> report the status change through the rfkill notify chain and also through the rfkill
> uevents, and either a platform module for your laptop, or HAL (in userspace) can
> trap those, and issue the relevant input events.

And that is exactly how things should work in rfkill. ;)

> > > But of course, you have to make sure the master switch WILL bloody well stay off
> > > when off by design.  You engineer it so that all possible failure modes will
> > > cause it to go to the off state.
> > > 
> > > I would really appreciate that the rfkill class would abide to this UI notion for
> > > the master rfkill events (*_RFKILL_ALL).
> > 
> > Such a thing would indeed be nice, as long as you can positively identify
> > a master switch,
> > but as long as that is not possible/implemented it will only be confusing
> > for driver developers,
> > userspace developers and the users.
> 
> We document it *throughoutly*, and add a big fat warning about the misuse of
> RFKILL_ALL.   It should be enough.   Will you consider ACKing a new version of
> the patchset which documents better the *_RFKILL_ALL events?

Ok, with some additional documentation it should be sufficient for now.
We can later see if minor adjustments need to be made based on userspace
implementation (which with he current rfkill implementation is still very limited).

Ivo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists