linux/net/rfkill/rfkill.c, branch v2.6.28

Fix logic error in rfkill_check_duplicity

2008-11-06T21:37:09Z

> I'll have a prod at why the [hso] rfkill stuff isn't working next Ok, I believe this is due to the addition of rfkill_check_duplicity in rfkill and the fact that test_bit actually returns a negative value rather than the postive one expected (which is of course equally true). So when the second WLAN device (the hso device, with the EEE PC WLAN being the first) comes along rfkill_check_duplicity returns a negative value and so rfkill_register returns an error. Patch below fixes this for me. Signed-Off-By: Jonathan McDowell Acked-by: Henrique de Moraes Holschuh Signed-off-by: John W. Linville

rfkill: update LEDs for all state changes

2008-10-06T22:14:57Z

The LED state was not being updated by rfkill_force_state(), which will cause regressions in wireless drivers that had old-style rfkill support and are updated to use rfkill_force_state(). The LED state was not being updated when a change was detected through the rfkill->get_state() hook, either. Move the LED trigger update calls into notify_rfkill_state_change(), where it should have been in the first place. This takes care of both issues above. Signed-off-by: Henrique de Moraes Holschuh Acked-by: Ivo van Doorn Cc: stable@kernel.org Signed-off-by: John W. Linville

rfkill: remove transmitter blocking on suspend

2008-09-15T20:48:25Z

Currently, rfkill would stand in the way of properly supporting wireless devices that are capable of waking the system up from sleep or hibernation when they receive a special wireless message. It would also get in the way of mesh devices that need to remain operational even during platform suspend. To avoid that, stop trying to block the transmitters on the rfkill class suspend handler. Drivers that need rfkill's older behaviour will have to implement it by themselves in their own suspend handling. Do note that rfkill *will* attempt to restore the transmitter state on resume in any situation. This happens after the driver's resume method is called by the suspend core (class devices resume after the devices they are attached to have been resumed). The following drivers need to check if they need to explicitly block their transmitters in their own suspend handlers (maintainers Cc'd): arch/arm/mach-pxa/tosa-bt.c drivers/net/usb/hso.c drivers/net/wireless/rt2x00/* (USB might need it?) drivers/net/wireless/b43/ (SSB over USB might need it?) drivers/misc/hp-wmi.c eeepc-laptop w/rfkill support (not in mainline yet) Compal laptop w/rfkill support (not in mainline yet) toshiba-acpi w/rfkill support (not in mainline yet) Signed-off-by: Henrique de Moraes Holschuh Cc: Ivo van Doorn Cc: Matthew Garrett Cc: Andrew Bird Cc: Greg Kroah-Hartman Cc: Cezary Jackiewicz Cc: Philip Langdale Signed-off-by: John W. Linville

rfkill: rename rfkill_mutex to rfkill_global_mutex

2008-08-29T20:24:11Z

rfkill_mutex and rfkill->mutex are too easy to confuse with each other. Rename rfkill_mutex to rfkill_global_mutex, so that they are easier to tell apart with just one glance. Signed-off-by: Henrique de Moraes Holschuh Acked-by: Ivo van Doorn Cc: Michael Buesch Signed-off-by: John W. Linville

rfkill: add WARN and BUG_ON paranoia (v2)

2008-08-29T20:24:10Z

BUG_ON() and WARN() the heck out of buggy drivers calling into the rfkill subsystem. Also switch from WARN_ON(1) to the new descriptive WARN(). Signed-off-by: Henrique de Moraes Holschuh Acked-by: Ivo van Doorn Cc: Johannes Berg Signed-off-by: John W. Linville

rfkill: add missing line break

2008-08-29T20:24:10Z

Trivial patch adding a missing line break on rfkill_claim_show(). Signed-off-by: Felipe Balbi Acked-by: Henrique de Moraes Holschuh Acked-by: Ivo van Doorn Signed-off-by: John W. Linville

rfkill: use strict_strtoul (v2)

2008-08-29T20:24:10Z

Switch sysfs parsing to something that actually works properly. Signed-off-by: Henrique de Moraes Holschuh Acked-by: Ivo van Doorn Signed-off-by: John W. Linville

rfkill: introduce RFKILL_STATE_MAX

2008-08-22T20:29:57Z

While it is interesting to not add last-enum-markers because it allows gcc to warn us of switch() statements missing a valid state, we really should be handling memory corruption on a rfkill state with default clauses, anyway. So add RFKILL_STATE_MAX and use it where applicable. It makes for safer code in the long run. Signed-off-by: Henrique de Moraes Holschuh Acked-by: Ivo van Doorn Signed-off-by: John W. Linville

rfkill: add __must_check annotations

2008-08-22T20:29:57Z

rfkill is not a small, mere detail in wireless support. Once it starts supporting rfkill and users start counting on that support, a wireless device is at risk of operating in dangerous conditions should rfkill support fail to properly activate. Therefore, add the required __must_check annotations on some key functions of the rfkill API, for which the wireless drivers absolutely MUST handle the failure mode safely in order to avoid a potentially dangerous situation where the wireless transmitter is left enabled when the user don't want it to. Signed-off-by: Henrique de Moraes Holschuh Acked-by: Ivo van Doorn Cc: Matthew Garrett Signed-off-by: John W. Linville

rfkill: add default global states (v2)

2008-08-22T20:29:56Z

Add a second set of global states, "rfkill_default_states", to track the state that will be used when the first rfkill class of a given type is registered, and also to save "undo" information when rfkill_epo is called. Add a new exported function, rfkill_set_default(), which can be used by platform drivers to restore radio state saved by the platform across reboots or shutdown. Also, fix rfkill_epo to properly update rfkill_states, but still preserve a copy of the state so that we can undo the effect of rfkill_epo later if we want to. Add rfkill_restore_states() to restore rfkill_states from the copy. Signed-off-by: Henrique de Moraes Holschuh Acked-by: Ivo van Doorn Signed-off-by: John W. Linville