Hardware button support for Wireless cards

Hardware button support for Wireless cards

[Mark Wallis]

Hi everyone,

During our development of the rt2x00 wireless driver we have come across an
interesting issue that we want to get comment on from the netdev-community.

Some laptops with our Ralink cards build-in also include a hardware button
that is meant to enable/disable the wireless card. We are wondering how we
should handle this.

Currently, in our rt2x00 (using the devicescape stack) we are firing off an
ACPI event so that the hardware button can be handled in userspace. This
allows the user to basically do whatever they want when this button is
pressed - including bringing down the wireless interface. The problem here
is no distro's currently contain scripts to run from this event so for many
users it just "doesn't work" without them manually having to write scripts
to handle the ACPI even themselves.

Some people are saying that instead of throwing and ACPI event we should be
either use hotplug or internally just disable the radio and somehow inform
the dscape stack that the radio has been disabled.

What are peoples thoughts here, should we 

A. be handling this within our drivers and doing "what the user expects" and
disabling the hardware radio, or 

B. should we be firing an ACPI event and getting the distro's to add scripts
so when this event is fired they bring down all the wireless interfaces.

Regards,
Mark Wallis
Project Admin
http://rt2x00.serialmonkey.com
mwallis@serialmonkey.com

Re: Hardware button support for Wireless cards

[Jiri Benc]

On Mon, 15 May 2006 22:57:12 +1000, Mark Wallis wrote:
> Currently, in our rt2x00 (using the devicescape stack) we are firing off an
> ACPI event so that the hardware button can be handled in userspace. This
> allows the user to basically do whatever they want when this button is
> pressed - including bringing down the wireless interface. The problem here
> is no distro's currently contain scripts to run from this event so for many
> users it just "doesn't work" without them manually having to write scripts
> to handle the ACPI even themselves.

Distributions will need to accommodate to the way d80211 stack works
anyway, so I see no problem with this.

> B. should we be firing an ACPI event and getting the distro's to add scripts
> so when this event is fired they bring down all the wireless interfaces.

Voting for this. It brings more flexibility.

This is not a problem of your card only. Is there a standard ACPI
rf-kill event?

 Jiri

-- 
Jiri Benc
SUSE Labs

Re: Hardware button support for Wireless cards

[Ivo van Doorn]

[-- Attachment #1: Type: text/plain, Size: 1295 bytes --]

On Monday 15 May 2006 15:25, Jiri Benc wrote:
> On Mon, 15 May 2006 22:57:12 +1000, Mark Wallis wrote:
> > Currently, in our rt2x00 (using the devicescape stack) we are firing off an
> > ACPI event so that the hardware button can be handled in userspace. This
> > allows the user to basically do whatever they want when this button is
> > pressed - including bringing down the wireless interface. The problem here
> > is no distro's currently contain scripts to run from this event so for many
> > users it just "doesn't work" without them manually having to write scripts
> > to handle the ACPI even themselves.
> 
> Distributions will need to accommodate to the way d80211 stack works
> anyway, so I see no problem with this.
> 
> > B. should we be firing an ACPI event and getting the distro's to add scripts
> > so when this event is fired they bring down all the wireless interfaces.
> 
> Voting for this. It brings more flexibility.
> 
> This is not a problem of your card only. Is there a standard ACPI
> rf-kill event?

Not sure actually. the approach rt2x00 takes is sending an event ACPI_TYPE_EVENT
with as argument a 0 or 1 depending on the new state of the button.
But I don't know if there is another event that would be more suitable for a hardware button.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Hardware button support for Wireless cards

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 1051 bytes --]

On Mon, 15 May 2006 22:57:12 +1000 Mark Wallis wrote:

> What are peoples thoughts here, should we 
> 
> A. be handling this within our drivers and doing "what the user expects" and
> disabling the hardware radio, or 
> 
> B. should we be firing an ACPI event and getting the distro's to add scripts
> so when this event is fired they bring down all the wireless interfaces.

Using ACPI events for this purpose seems wrong:

- ACPI is not available on all architectures supported by Linux,
  therefore it cannot be an universal solution;

- even if ACPI is available, it may be turned off for some reason.

In fact, many people consider the separate /proc/acpi/event interface
for ACPI events to be a mistake, and there is some movement to make ACPI
use the input layer instead:

  http://lkml.org/lkml/2006/4/19/275

There is even a KEY_RADIO defined in <linux/input.h> (however, it was
probably intended to be used for a remote control key, like
TV/VCR/CD/Tape/... defined near it, so I'm not sure whether it would be
the proper event to use here).

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Hardware button support for Wireless cards

[Dan Williams]

On Mon, 2006-05-15 at 22:57 +1000, Mark Wallis wrote:
> Hi everyone,
> 
> Currently, in our rt2x00 (using the devicescape stack) we are firing off an
> ACPI event so that the hardware button can be handled in userspace. This
> allows the user to basically do whatever they want when this button is
> pressed - including bringing down the wireless interface. The problem here
> is no distro's currently contain scripts to run from this event so for many
> users it just "doesn't work" without them manually having to write scripts
> to handle the ACPI even themselves.
> 
> Some people are saying that instead of throwing and ACPI event we should be
> either use hotplug or internally just disable the radio and somehow inform
> the dscape stack that the radio has been disabled.
> 
> What are peoples thoughts here, should we 
> 
> A. be handling this within our drivers and doing "what the user expects" and
> disabling the hardware radio, or 

> B. should we be firing an ACPI event and getting the distro's to add scripts
> so when this event is fired they bring down all the wireless interfaces.

(had this issue in the back of my head for a while already...)

Isn't the rf-kill switch specific to the manufacturer lots of times?  Is
the switch connected directly to the card, or is it incumbent on the
driver to notice the event and disable the card via software?  We need
to handle this for Bluetooth too, in situations where there's both a
bluetooth and an 802.11 card in the box.  Does the rf-kill apply to
both?  Or just to one?

WRT to disabling the radio, I'm not sure it makes a difference either
way.  Hitting a button generally means "do this _NOW_", so it makes
sense for the driver to disable the radio and then send out the event.
Apps need to be able to deal with these resources going out from
underneath them, and I'm not sure it makes sense to wait around for some
scripts to run that just might possibly at some future point disable it,
but you're never sure.

In the end, an ACPI event is probably fine.  I must stress that we NEED
to have a common event structure for this, such that every driver and
card presents the same interface.  I don't want to have to write stuff
for each of 3 or 4 different cards to notice the rf-kill stuff.  Witness
all the extra binaries that each driver has already for this sort of
thing.  What interface does the ipw[2|3]xxx driver and hardware present?
What common bits can be drawn out from both?

Ideally, here's what would happen:  the driver/card/whatever generates
an ACPI event, which is noticed by HAL.  HAL sets a property on the
_exact_ device which the event is for, and propagates the signal out
over dbus.  Any interested application can listen for, and respond to,
the rf-kill signal.  (or, the event can be handled by acpid and the
distro can run scripts for it.  01dsk001.  whatever)

But this means a few things.  We need:

1) common interface/signal for _all_ cards and drivers
2) Enough information to identify which specific pci/pcmcia/etc device
the event is for (or system-wide?)

Dan

Re: Hardware button support for Wireless cards

[Ivo van Doorn]

[-- Attachment #1: Type: text/plain, Size: 4546 bytes --]

On Monday 15 May 2006 16:37, Dan Williams wrote:
> On Mon, 2006-05-15 at 22:57 +1000, Mark Wallis wrote:
> > Hi everyone,
> > 
> > Currently, in our rt2x00 (using the devicescape stack) we are firing off an
> > ACPI event so that the hardware button can be handled in userspace. This
> > allows the user to basically do whatever they want when this button is
> > pressed - including bringing down the wireless interface. The problem here
> > is no distro's currently contain scripts to run from this event so for many
> > users it just "doesn't work" without them manually having to write scripts
> > to handle the ACPI even themselves.
> > 
> > Some people are saying that instead of throwing and ACPI event we should be
> > either use hotplug or internally just disable the radio and somehow inform
> > the dscape stack that the radio has been disabled.
> > 
> > What are peoples thoughts here, should we 
> > 
> > A. be handling this within our drivers and doing "what the user expects" and
> > disabling the hardware radio, or 
> 
> > B. should we be firing an ACPI event and getting the distro's to add scripts
> > so when this event is fired they bring down all the wireless interfaces.
> 
> (had this issue in the back of my head for a while already...)
> 
> Isn't the rf-kill switch specific to the manufacturer lots of times?  Is
> the switch connected directly to the card, or is it incumbent on the
> driver to notice the event and disable the card via software?  We need
> to handle this for Bluetooth too, in situations where there's both a
> bluetooth and an 802.11 card in the box.  Does the rf-kill apply to
> both?  Or just to one?

The rt2x00 device itself does nothing when the button is pressed, it only
updates certain fields in a register to indicate the button is pressed.
The driver should read from the EEPROM if a hardware button is available,
after that it should poll the register to see if the button has been pressed,
and it is up to the driver what to do.

> WRT to disabling the radio, I'm not sure it makes a difference either
> way.  Hitting a button generally means "do this _NOW_", so it makes
> sense for the driver to disable the radio and then send out the event.
> Apps need to be able to deal with these resources going out from
> underneath them, and I'm not sure it makes sense to wait around for some
> scripts to run that just might possibly at some future point disable it,
> but you're never sure.

Well I would think it is cleaner to inform userspace that the button is pressed
and let userspace sort out what exactly should happen.
But I doubt it will be a good idea when the driver is sending and event _and_
disabled the radio. It could be that the user wants something to be done
before the radio is being disabled.

> In the end, an ACPI event is probably fine.  I must stress that we NEED
> to have a common event structure for this, such that every driver and
> card presents the same interface.  I don't want to have to write stuff
> for each of 3 or 4 different cards to notice the rf-kill stuff.  Witness
> all the extra binaries that each driver has already for this sort of
> thing.  What interface does the ipw[2|3]xxx driver and hardware present?
> What common bits can be drawn out from both?
> 
> Ideally, here's what would happen:  the driver/card/whatever generates
> an ACPI event, which is noticed by HAL.  HAL sets a property on the
> _exact_ device which the event is for, and propagates the signal out
> over dbus.  Any interested application can listen for, and respond to,
> the rf-kill signal.  (or, the event can be handled by acpid and the
> distro can run scripts for it.  01dsk001.  whatever)

This idea sounds good, but is ACPI the thing to be used.
Escpially since ACPI is a bit architectures dependent.
And the solution should be supported on various architectures.

> But this means a few things.  We need:
> 
> 1) common interface/signal for _all_ cards and drivers
> 2) Enough information to identify which specific pci/pcmcia/etc device
> the event is for (or system-wide?)

system-wide would not be a good idea, we need something to determine which
driver exactly has triggered the event. Some laptops have several hardware buttons
1 for Bluetooth and 1 for Wifi for example.

So we could just pass the name the driver has created for that button to userspace.
At least that is a similar approach to ACPI where the class, bid and name fields
are all names set by the driver.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Hardware button support for Wireless cards

[Jason Lunz]

mwallis@serialmonkey.com said:
> Some people are saying that instead of throwing and ACPI event we should be
> either use hotplug or internally just disable the radio and somehow inform
> the dscape stack that the radio has been disabled.
>
> What are peoples thoughts here, should we 
>
> A. be handling this within our drivers and doing "what the user expects" and
> disabling the hardware radio, or 

On my HP laptop with bcm43xx wireless, the button disables the radio in
HARDWARE, and afaict the driver has no idea about it. The driver notices
that it's not connected and happily starts scanning again, unaware that
anything is wrong.

This is actually quite nice for testing roaming setups. You can "roam"
in and out of range by toggling the button.

The other laptop in the house has a physical _switch_, which implies
that it too cuts off the radio in hardware (though I haven't
investigated this, so I'm only speculating).

So if there's any desire for consistency of wireless button support,
then I think the software-controlled ones should always shut off the
radio, and optionally inform userspace or the wireless stack using some
event mechanism.

What is the purpose of these switches anyway? Power saving? Or is it for
situations like an airplane or hospital where you want to be sure your
wireless won't cause any interference? If the latter, than that also
argues for always shutting off the radio immediately.

Jason

Re: Hardware button support for Wireless cards

[Michael Buesch]

On Monday 15 May 2006 17:27, you wrote:
> mwallis@serialmonkey.com said:
> > Some people are saying that instead of throwing and ACPI event we should be
> > either use hotplug or internally just disable the radio and somehow inform
> > the dscape stack that the radio has been disabled.
> >
> > What are peoples thoughts here, should we 
> >
> > A. be handling this within our drivers and doing "what the user expects" and
> > disabling the hardware radio, or 
> 
> On my HP laptop with bcm43xx wireless, the button disables the radio in
> HARDWARE, and afaict the driver has no idea about it. The driver notices
> that it's not connected and happily starts scanning again, unaware that
> anything is wrong.

There are registers on the bcm43xx chip (0x158 and 0x49A) that indicate
some "Radio is hardware-disabled" state. We currently don't use that flag
correctly in the driver. Could you please assist me on testing if your switch
actually toggles the bit?
I think best place for this would be on irc.freenode.net #bcm-users

Re: Hardware button support for Wireless cards

[David Zeuthen]

On Mon, 2006-05-15 at 10:37 -0400, Dan Williams wrote:
> Ideally, here's what would happen:  the driver/card/whatever generates
> an ACPI event, which is noticed by HAL.  HAL sets a property on the
> _exact_ device which the event is for, and propagates the signal out
> over dbus.  Any interested application can listen for, and respond to,
> the rf-kill signal.  (or, the event can be handled by acpid and the
> distro can run scripts for it.  01dsk001.  whatever)

Yes, I agree this needs to happen in user space partly because it's
policy even though I can only come up with crack reasons on why you
wouldn't want to turn off the radio when the button is pressed.

However, I suppose we need to do it in user space for some laptops
anyway since I'm not sure the "RF Kill Switch" button and the networking
hardware may be related; see below.

> 
> But this means a few things.  We need:
> 
> 1) common interface/signal for _all_ cards and drivers

Right, this would be nice. This is sorta like the mess that is hotkeys
on laptops. We sorta deal with those in HAL but it's a lot of ugly code
to present a sane abstract interface to user space.

> 2) Enough information to identify which specific pci/pcmcia/etc device
> the event is for (or system-wide?)

No, I'm not really sure we need to know exactly what device this is
triggered for and I'm not even sure that the kernel can figure this out
anyway: the RF Kill buttons may be implemented as a USB HID device for
example which may have little relation to the hardware. Another example
is where the user is using a USB or PC Card Wifi adapter instead of the
built-in Wifi. We want to turn off the radio on the USB or PC Card in
these cases too.

So what we need from user space is basically just an event saying "RF
Kill button pressed" perhaps with some detail such as 'bluetooth' or
'wifi' depending on the graphics of the button (no, I'm not kidding). 

It would also be nice with some way to query state, e.g. "is the button
pressed or not" if the hardware supports this. So, I think perhaps it
may make sense to model this as an input device. Then we can simply
query this input device from user space (in HAL) and emit the right
events and provide an interface to query whether the button is pressed
or not [1]. Specifically, on startup, NetworkManager would just ask HAL
whether the button is pressed or not (if the hardware supports it) and
do the right thing, e.g. selectively suspend all networking devices with
a radio via the power/state file in sysfs which will turn off the radio.
When the user presses the button, NetworkManager enables / disables the
device [2] and so on.

Hope this helps.

    David

[1] : we do the same thing for other buttons in HAL; e.g. the power
button on some Powerbooks.

[2] : this raises another problem. What happens to class devices when a
bus device is turned off (e.g. selective suspend). For example, does the
class device /sys/class/net/eth0 go away when I put the physical to
sleep via the /sys/class/net/eth0/device/power/state file?

Maybe off topic, but what happens in general? For example what happens
when I selectively suspend a USB harddisk enclosure, does /sys/block/sda
go away? If it doesn't, does '# touch /dev/sda' wake it up? (it probably
shouldn't)... 

This kind of stuff needs to be precisely defined, yes? Is it already
defined?

Re: Hardware button support for Wireless cards

[Jouni Malinen]

On Mon, May 15, 2006 at 05:12:20PM +0200, Ivo van Doorn wrote:

> Well I would think it is cleaner to inform userspace that the button is pressed
> and let userspace sort out what exactly should happen.
> But I doubt it will be a good idea when the driver is sending and event _and_
> disabled the radio. It could be that the user wants something to be done
> before the radio is being disabled.

Some hardware designs disable the radio in hardware, some don't.. In
other words, the behavior would not be consistent between hardware
designs unless the radio would be disabled unconditionally in
software-processed case. I would like to be able to trust on the
rfkill to really kill the radio regardless of whether the user space
mechanism is in place or not, i.e., I see this as a function that can be
used to disable radio in environments were use of wireless devices is
not allowed for some reason.

Sending an event to user space would be a good additional indication
that the radio was disabled. If user space wants to do something first,
I would think that doing this with full software control (i.e., not
depending on any particular hardware button and just having a UI
mechanism for triggering this) would allow more consistent behavior.

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: Hardware button support for Wireless cards

[Dan Williams]

On Mon, 2006-05-15 at 18:01 +0200, Michael Buesch wrote:
> On Monday 15 May 2006 17:27, you wrote:
> > mwallis@serialmonkey.com said:
> > > Some people are saying that instead of throwing and ACPI event we should be
> > > either use hotplug or internally just disable the radio and somehow inform
> > > the dscape stack that the radio has been disabled.
> > >
> > > What are peoples thoughts here, should we 
> > >
> > > A. be handling this within our drivers and doing "what the user expects" and
> > > disabling the hardware radio, or 
> > 
> > On my HP laptop with bcm43xx wireless, the button disables the radio in
> > HARDWARE, and afaict the driver has no idea about it. The driver notices
> > that it's not connected and happily starts scanning again, unaware that
> > anything is wrong.
> 
> There are registers on the bcm43xx chip (0x158 and 0x49A) that indicate
> some "Radio is hardware-disabled" state. We currently don't use that flag
> correctly in the driver. Could you please assist me on testing if your switch
> actually toggles the bit?
> I think best place for this would be on irc.freenode.net #bcm-users

When those bits get set in the register, is the radio already disabled?
ie, for the bcm43xx chip, is it really force-disabled by the button, or
does the driver have some control?

Dan

Re: Hardware button support for Wireless cards

[Michael Buesch]

On Monday 15 May 2006 21:12, you wrote:
> > There are registers on the bcm43xx chip (0x158 and 0x49A) that indicate
> > some "Radio is hardware-disabled" state. We currently don't use that flag
> > correctly in the driver. Could you please assist me on testing if your switch
> > actually toggles the bit?
> > I think best place for this would be on irc.freenode.net #bcm-users
> 
> When those bits get set in the register, is the radio already disabled?
> ie, for the bcm43xx chip, is it really force-disabled by the button, or
> does the driver have some control?

Hm, actually, We don't know what the bit means. Could be some
completely different meaning. That is what I am trying to find
out. But it seems to have something to do with the power control
of the chip.

Re: Hardware button support for Wireless cards

[Jason Lunz]

On Mon, May 15, 2006 at 03:12:50PM -0400, Dan Williams wrote:
> When those bits get set in the register, is the radio already disabled?
> ie, for the bcm43xx chip, is it really force-disabled by the button, or
> does the driver have some control?

I assume it disables the radio without any help from the driver, because
it definitely turns off my radio, but the bcm43xx driver i'm using (in
2.6.17-rc4) currently doesn't pay any attention to those registers
afaik.

Jason

Re: Hardware button support for Wireless cards

[John W. Linville]

On Mon, May 15, 2006 at 03:27:54PM +0000, Jason Lunz wrote:

> So if there's any desire for consistency of wireless button support,
> then I think the software-controlled ones should always shut off the
> radio, and optionally inform userspace or the wireless stack using some
> event mechanism.

FWIW, I think this position makes the most sense...

John
-- 
John W. Linville
linville@tuxdriver.com

Re: Hardware button support for Wireless cards

[Ivo van Doorn]

[-- Attachment #1: Type: text/plain, Size: 892 bytes --]

On Monday 15 May 2006 21:46, Jason Lunz wrote:
> On Mon, May 15, 2006 at 03:12:50PM -0400, Dan Williams wrote:
> > When those bits get set in the register, is the radio already disabled?
> > ie, for the bcm43xx chip, is it really force-disabled by the button, or
> > does the driver have some control?
> 
> I assume it disables the radio without any help from the driver, because
> it definitely turns off my radio, but the bcm43xx driver i'm using (in
> 2.6.17-rc4) currently doesn't pay any attention to those registers
> afaik.

Correct, my laptop with an integrated BCM43xx chip works this was as well.
I can use the button to enable and disable the device (led is switching on and off)
without a bcm43xx driver installed. Hardware detection just picks it up when
I enable the device with the button as new device. So the hardware button works
directly with the hardware.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

RE: Hardware button support for Wireless cards

[Mark Wallis]

On Tue, May 16, 2006, Jouni Malinen wrote:

> Some hardware designs disable the radio in hardware, some 
> don't.. In other words, the behavior would not be consistent 
> between hardware designs unless the radio would be disabled 
> unconditionally in software-processed case. I would like to 
> be able to trust on the rfkill to really kill the radio 
> regardless of whether the user space mechanism is in place or 
> not, i.e., I see this as a function that can be used to 
> disable radio in environments were use of wireless devices is 
> not allowed for some reason.
> 
> Sending an event to user space would be a good additional 
> indication that the radio was disabled. If user space wants 
> to do something first, I would think that doing this with 
> full software control (i.e., not depending on any particular 
> hardware button and just having a UI mechanism for triggering 
> this) would allow more consistent behavior.

Sounds like this is the popular option - I agree that immediate
radio-off is the "safe" way to go here as at least the driver
can guarantee that the radio is disabled no matter the userspace
config.

Does someone want to put their hand up and specify the userspace
interface here and now so we all keep to a standard ? Working
as an input device as David suggested seems to give us the most
flexibility.

Regards,

Mark Wallis
E: mwallis@serialmonkey.com

[RFC PATCH 0/2] Hardware button support for Wireless cards

[Ivo van Doorn]

[-- Attachment #1: Type: text/plain, Size: 914 bytes --]

Hi,

As discussed previously on this list hardware button support
for wireless cards and Bluetooth devices could use a seperate
generalized driver.

I have made a first attempt to do this with the suggestions from the
discussion. This means that in all cases the hardware will be requested
to enable or disable the radio (if this command needs to be issued from
software) and it will send a signal to the input device created for the button.

At the moment a input device will be created for each registered button,
not sure if this is the desired situation, but thats why this is a RFC patch. ;)

I am also not sure where to place this driver so at the moment I have placed
it in /drivers/input/misc

The second patch is an example of the implementation in rt2x00.
That is just an example since that already contained a similar approach with
hardware button support.

All hints/tips/comments are welcome. :)

Ivo

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]