aboutsummaryrefslogtreecommitdiffstats
path: root/net/rfkill
Commit message (Collapse)AuthorAge
* headers: remove sched.h from poll.hAlexey Dobriyan2009-10-04
| | | | | Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* rfkill: add the GPS radio typeTomas Winkler2009-08-04
| | | | | | | | | | | | | | Althoug GPS is a technology w/o transmitting radio and thus not a primary candidate for rfkill switch, rfkill gives unified interface point for devices with wireless technology. The input key is not supplied as it is too be deprecated. Cc: johannes@sipsolutions.net Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* Merge branch 'master' of ↵David S. Miller2009-07-23
|\ | | | | | | | | | | | | | | master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6 Conflicts: drivers/net/wireless/iwmc3200wifi/netdev.c net/wireless/scan.c
| * rfkill: fix rfkill_set_states() to set the hw stateAlan Jenkins2009-07-21
| | | | | | | | | | | | | | | | | | | | The point of this function is to set the software and hardware state at the same time. When I tried to use it, I found it was only setting the software state. Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Reviewed-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * rfkill: allow toggling soft state in sysfs againJohannes Berg2009-07-21
| | | | | | | | | | | | | | | | | | | | | | | | Apparently there actually _are_ tools that try to set this in sysfs even though it wasn't supposed to be used this way without claiming first. Guess what: now that I've cleaned it all up it doesn't matter and we can simply allow setting the soft-block state in sysfs. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Tested-By: Darren Salt <linux@youmustbejoking.demon.co.uk> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | rfkill: prep for rfkill API changesJohannes Berg2009-07-10
|/ | | | | | | | | | | | | | | | | | | | | | | | We've designed the /dev/rfkill API in a way that we can increase the event struct by adding members at the end, should it become necessary. To validate the events, userspace and the kernel need to have the proper event size to check for -- when reading from the other end they need to verify that it's at least version 1 of the event API, with the current struct size, so define a constant for that and make the code a little more 'future proof'. Not that I expect that we'll have to change the event size any time soon, but it's better to write the code in a way that lends itself to extending. Due to the current size of the event struct, the code is currently equivalent, but should the event struct ever need to be increased the new code might not need changing. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* rfkill: export persistent attribute in sysfsAlan Jenkins2009-06-19
| | | | | | | | | | | | | | | | This information allows userspace to implement a hybrid policy where it can store the rfkill soft-blocked state in platform non-volatile storage if available, and if not then file-based storage can be used. Some users prefer platform non-volatile storage because of the behaviour when dual-booting multiple versions of Linux, or if the rfkill setting is changed in the BIOS setting screens, or if the BIOS responds to wireless-toggle hotkeys itself before the relevant platform driver has been loaded. Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* rfkill: don't restore software blocked state on persistent devicesAlan Jenkins2009-06-19
| | | | | | | | | | | | | | | | | | | | | | | | | The setting of the "persistent" flag is also made more explicit using a new rfkill_init_sw_state() function, instead of special-casing rfkill_set_sw_state() when it is called before registration. Suspend is a bit of a corner case so we try to get away without adding another hack to rfkill-input - it's going to be removed soon. If the state does change over suspend, users will simply have to prod rfkill-input twice in order to toggle the state. Userspace policy agents will be able to implement a more consistent user experience. For example, they can avoid the above problem if they toggle devices individually. Then there would be no "global state" to get out of sync. Currently there are only two rfkill drivers with persistent soft-blocked state. thinkpad-acpi already checks the software state on resume. eeepc-laptop will require modification. Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> CC: Marcel Holtmann <marcel@holtmann.org> Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* rfkill: rfkill_set_block() when suspended nitpickAlan Jenkins2009-06-19
| | | | | | | | | | | | | | If we return after fiddling with the state, userspace will see the wrong state and rfkill_set_sw_state() won't work until the next call to rfkill_set_block(). At the moment rfkill_set_block() will always be called from rfkill_resume(), but this will change in future. Also, presumably the point of this test is to avoid bothering devices which may be suspended. If we don't want to call set_block(), we probably don't want to call query() either :-). Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* rfkill: don't impose global states on resume (just restore the previous states)Alan Jenkins2009-06-10
| | | | | | | | | | | Once rfkill-input is disabled, the "global" states will only be used as default initial states. Since the states will always be the same after resume, we shouldn't generate events on resume. Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* rfkill: remove set_global_sw_stateAlan Jenkins2009-06-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | rfkill_set_global_sw_state() (previously rfkill_set_default()) will no longer be exported by the rewritten rfkill core. Instead, platform drivers which can provide persistent soft-rfkill state across power-down/reboot should indicate their initial state by calling rfkill_set_sw_state() before registration. Otherwise, they will be initialized to a default value during registration by a set_block call. We remove existing calls to rfkill_set_sw_state() which happen before registration, since these had no effect in the old model. If these drivers do have persistent state, the calls can be put back (subject to testing :-). This affects hp-wmi and acer-wmi. Drivers with persistent state will affect the global state only if rfkill-input is enabled. This is required, otherwise booting with wireless soft-blocked and pressing the wireless-toggle key once would have no apparent effect. This special case will be removed in future along with rfkill-input, in favour of a more flexible userspace daemon (see Documentation/feature-removal-schedule.txt). Now rfkill_global_states[n].def is only used to preserve global states over EPO, it is renamed to ".sav". Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* rfkill: remove input KconfigJohannes Berg2009-06-10
| | | | | | | | | | Now that we added the ioctl, there's no need to ask the user to configure this. We will keep it enabled for now, and eventually swap the default to n. Also let embedded users select it only if they need it. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* rfkill: print events when input handler is disabled/enabledJohannes Berg2009-06-10
| | | | | | | | | It is useful for debugging when we know if something disabled the in-kernel rfkill input handler. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* rfkill: always init poll delayed workJohannes Berg2009-06-03
| | | | | | | | | | | | | The rfkill core didn't initialise the poll delayed work because it assumed that polling was always done by specifying the poll function. cfg80211, however, would like to start polling only later, which is a valid use case and easy to support, so change rfkill to always initialise the poll delayed work and thus allow starting polling by calling the rfkill_resume_polling() function after registration. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* rfkill: add function to query stateJohannes Berg2009-06-03
| | | | | | | | | | | Sometimes it is necessary to know how the state is, and it is easier to query rfkill than keep track of it somewhere else, so add a function for that. This could later be expanded to return hard/soft block, but so far that isn't necessary. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* rfkill: create useful userspace interfaceJohannes Berg2009-06-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The new code added by this patch will make rfkill create a misc character device /dev/rfkill that userspace can use to control rfkill soft blocks and get status of devices as well as events when the status changes. Using it is very simple -- when you open it you can read a number of times to get the initial state, and every further read blocks (you can poll) on getting the next event from the kernel. The same structure you read is also used when writing to it to change the soft block of a given device, all devices of a given type, or all devices. This also makes CONFIG_RFKILL_INPUT selectable again in order to be able to test without it present since its functionality can now be replaced by userspace entirely and distros and users may not want the input part of rfkill interfering with their userspace code. We will also write a userspace daemon to handle all that and consequently add the input code to the feature removal schedule. In order to have rfkilld support both kernels with and without CONFIG_RFKILL_INPUT (or new kernels after its eventual removal) we also add an ioctl (that only exists if rfkill-input is present) to disable rfkill-input. It is not very efficient, but at least gives the correct behaviour in all cases. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* rfkill: rewriteJohannes Berg2009-06-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch completely rewrites the rfkill core to address the following deficiencies: * all rfkill drivers need to implement polling where necessary rather than having one central implementation * updating the rfkill state cannot be done from arbitrary contexts, forcing drivers to use schedule_work and requiring lots of code * rfkill drivers need to keep track of soft/hard blocked internally -- the core should do this * the rfkill API has many unexpected quirks, for example being asymmetric wrt. alloc/free and register/unregister * rfkill can call back into a driver from within a function the driver called -- this is prone to deadlocks and generally should be avoided * rfkill-input pointlessly is a separate module * drivers need to #ifdef rfkill functions (unless they want to depend on or select RFKILL) -- rfkill should provide inlines that do nothing if it isn't compiled in * the rfkill structure is not opaque -- drivers need to initialise it correctly (lots of sanity checking code required) -- instead force drivers to pass the right variables to rfkill_alloc() * the documentation is hard to read because it always assumes the reader is completely clueless and contains way TOO MANY CAPS * the rfkill code needlessly uses a lot of locks and atomic operations in locked sections * fix LED trigger to actually change the LED when the radio state changes -- this wasn't done before Tested-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> [thinkpad] Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* net/rfkill/rfkill.c: fix build with CONFIG_RFKILL_LEDS=nAndrew Morton2009-05-06
| | | | | | | | | | | | | | | | | | | | | net/rfkill/rfkill.c: In function 'update_rfkill_state': net/rfkill/rfkill.c:99: error: implicit declaration of function 'rfkill_led_trigger' Caused by : commit 492301fb5d12e4a77a1010ad2b6f1ed306014123 : Author: Larry Finger <Larry.Finger@lwfinger.net> : Date: Thu Apr 9 22:14:19 2009 -0500 : : rfkill: Fix broken rfkill LED in 2.6.30-rc1 Cc: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: Ivo van Doorn <IvDoorn@gmail.com> Cc: Michael Buesch <mb@bu3sch.de> Cc: David S. Miller <davem@davemloft.net> Cc: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* rfkill: Fix broken rfkill LED in 2.6.30-rc1Larry Finger2009-04-22
| | | | | | | | The rfkill system fails to issue a LED trigger event when the rfkill state changes. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* rfkill-input: remove unused codeJohannes Berg2009-04-22
| | | | | | | | | There's a lot of rfkill-input code that cannot ever be compiled and is useless until somebody needs and tests it -- therefore remove it. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* rfkill: remove user_claim stuffJohannes Berg2009-04-22
| | | | | | | | | | | Almost all drivers do not support user_claim, so remove it completely and always report -EOPNOTSUPP to userspace. Since userspace cannot really drive rfkill _anyway_ (due to the odd restrictions imposed by the documentation) having this code is just pointless. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* net/rfkill/rfkill.c: fix unused rfkill_led_trigger() warningSimon Holm Thøgersen2009-01-04
| | | | | | | | | | | | | commit 4dec9b807be757780ca3611a959ac22c28d292a7 ("rfkill: strip pointless notifier chain") removed the only user of rfkill_led_trigger() that was not guarded by #ifdef CONFIG_RFKILL_LEDS. Therefore, move rfkill_led_trigger() completely inside #ifdef CONFIG_RFKILL_LEDS and avoid the compile time warning: net/rfkill/rfkill.c:59: warning: 'rfkill_led_trigger' defined but not used Signed-off-by: Simon Holm Thøgersen <odie@cs.aau.dk> Signed-off-by: David S. Miller <davem@davemloft.net>
* rfkill: strip pointless notifier chainJohannes Berg2008-12-12
| | | | | | | | No users, so no reason to have it. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* rfkill: always call get_state() hook on resumeHenrique de Moraes Holschuh2008-11-26
| | | | | | | | | | | | | | | | | | We "optimize" away the get_state() hook call on rfkill_toggle_radio when doing a forced state change. This means the resume path is not calling get_state() as it should. Call it manually on the resume handler, as we don't want to mess with the EPO path by removing the optimization. This has the added benefit of making it explicit that rfkill->state could have been modified before we hit the rfkill_toggle_radio() call in the class resume handler. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* rfkill: preserve state across suspendHenrique de Moraes Holschuh2008-11-26
| | | | | | | | | | | | | | | | | | | | The rfkill class API requires that the driver connected to a class call rfkill_force_state() on resume to update the real state of the rfkill controller, OR that it provides a get_state() hook. This means there is potentially a hidden call in the resume code flow that changes rfkill->state (i.e. rfkill_force_state()), so the previous state of the transmitter was being lost. The simplest and most future-proof way to fix this is to explicitly store the pre-sleep state on the rfkill structure, and restore from that on resume. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* net: struct device - replace bus_id with dev_name(), dev_set_name()Kay Sievers2008-11-10
| | | | | | | Acked-by: Marcel Holtmann <marcel@holtmann.org> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* Merge branch 'master' of ↵David S. Miller2008-11-07
|\ | | | | | | | | | | | | | | | | master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6 Conflicts: drivers/net/wireless/ath5k/base.c net/8021q/vlan_core.c
| * Fix logic error in rfkill_check_duplicityJonathan McDowell2008-11-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | > 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 <noodles@earth.li> Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | rfkill: rate-limit rfkill-input workqueue usage (v3)Henrique de Moraes Holschuh2008-10-31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Limit the number of "expensive" rfkill workqueue operations per second, in order to not hog system resources too much when faced with a rogue source of rfkill input events. The old rfkill-input code (before it was refactored) had such a limit in place. It used to drop new events that were past the rate limit. This behaviour was not implemented as an anti-DoS measure, but rather as an attempt to work around deficiencies in input device drivers which would issue multiple KEY_FOO events too soon for a given key FOO (i.e. ones that do not implement mechanical debouncing properly). However, we can't really expect such issues to be worked around by every input handler out there, and also by every userspace client of input devices. It is the input device driver's responsability to do debouncing instead of spamming the input layer with bogus events. The new limiter code is focused only on anti-DoS behaviour, and tries to not lose events (instead, it coalesces them when possible). The transmitters are updated once every 200ms, maximum. Care is taken not to delay a request to _enter_ rfkill transmitter Emergency Power Off (EPO) mode. If mistriggered (e.g. by a jiffies counter wrap), the code delays processing *once* by 200ms. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: Ivo van Doorn <IvDoorn@gmail.com> Cc: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | rfkill: honour EPO state when resuming a rfkill controllerHenrique de Moraes Holschuh2008-10-31
| | | | | | | | | | | | | | | | | | | | | | | | | | rfkill_resume() would always restore the rfkill controller state to its pre-suspend state. Now that we know when we are under EPO, kick the rfkill controller to SOFT_BLOCKED state instead of to its pre-suspend state when it is resumed while EPO mode is active. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | rfkill: add master_switch_mode and EPO lock to rfkill and rfkill-inputHenrique de Moraes Holschuh2008-10-31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add of software-based sanity to rfkill and rfkill-input so that it can reproduce what hardware-based EPO switches do, blocking all transmitters and locking down any further attempts to unblock them until the switch is deactivated. rfkill-input is responsible for issuing the EPO control requests, like before. While an rfkill EPO is active, all transmitters are locked to one of the BLOCKED states and all attempts to change that through the rfkill API (userspace and kernel) will be either ignored or return -EPERM errors. The lock will be released upon receipt of EV_SW SW_RFKILL_ALL ON by rfkill-input, or should modular rfkill-input be unloaded. This makes rfkill and rfkill-input extend the operation of an existing wireless master kill switch to all wireless devices in the system, even those that are not under hardware or firmware control. Since the above is the expected operational behavior for the master rfkill switch, the EPO lock functionality is not optional. Also, extend rfkill-input to allow for three different behaviors when it receives an EV_SW SW_RFKILL_ALL ON input event. The user can set which behavior he wants through the master_switch_mode parameter: master_switch_mode = 0: EV_SW SW_RFKILL_ALL ON just unlocks rfkill controller state changes (so that the rfkill userspace and kernel APIs can now be used to change rfkill controller states again), but doesn't change any of their states (so they will all remain blocked). This is the safest mode of operation, as it requires explicit operator action to re-enable a transmitter. master_switch_mode = 1: EV_SW SW_RFKILL_ALL ON causes rfkill-input to attempt to restore the system to the state before the last EV_SW SW_RFKILL_ALL OFF event, or to the default global states if no EV_SW SW_RFKILL_ALL OFF ever happened. This is the recommended mode of operation for laptops. master_switch_mode = 2: tries to unblock all rfkill controllers (i.e. enable all transmitters) when an EV_SW SW_RFKILL_ALL ON event is received. This is the default mode of operation, as it mimics the previous behavior of rfkill-input. In order to implement these features in a clean way, the entire event handling of rfkill-input was refactored into a single worker function. Protection against input event DoS (repeatedly firing rfkill events for rfkill-input to process) was removed during the code refactoring. It will be added back in a future patch. Note that with these changes, rfkill-input doesn't need to explicitly handle any radio types for which KEY_<radio type> or SW_<radio type> events do not exist yet. Code to handle EV_SW SW_{WLAN,WWAN,BLUETOOTH,WIMAX,...} was added as it might be needed in the future (and its implementation is not that obvious), but is currently #ifdef'd out to avoid wasting resources. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: Ivo van Doorn <IvDoorn@gmail.com> Cc: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | rfkill: export global states to rfkill-inputHenrique de Moraes Holschuh2008-10-31
| | | | | | | | | | | | | | | | | | Export the the global switch states to rfkill-input. This is needed to properly implement KEY_* handling without disregarding the initial state. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | rfkill: use killable locks instead of interruptibleHenrique de Moraes Holschuh2008-10-31
|/ | | | | | | | | | | | Apparently, many applications don't expect to get EAGAIN from fd read/write operations, since POSIX doesn't mandate it. Use mutex_lock_killable instead of mutex_lock_interruptible, which won't cause issues. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* RFKILL: fix input layer initialisationDmitry Baryshkov2008-10-27
| | | | | | | | | Initialise correctly last fields, so tasks can be actually executed. On some architectures the initial jiffies value is not zero, so later all rfkill incorrectly decides that rfkill_*.last is in future. Signed-off-by: Dmitry Baryshkov <dbaryshkov@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* net/rfkill/rfkill-input.c needs <linux/sched.h>Geert Uytterhoeven2008-10-14
| | | | | | | | | | | | | For some m68k configs, I get: | net/rfkill/rfkill-input.c: In function 'rfkill_start': | net/rfkill/rfkill-input.c:208: error: dereferencing pointer to incomplete type As the incomplete type is `struct task_struct', including <linux/sched.h> fixes it. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* rfkill: update LEDs for all state changesHenrique de Moraes Holschuh2008-10-06
| | | | | | | | | | | | | | | | | | 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 <hmh@hmh.eng.br> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Cc: stable@kernel.org Signed-off-by: John W. Linville <linville@tuxdriver.com>
* rfkill: remove transmitter blocking on suspendHenrique de Moraes Holschuh2008-09-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <hmh@hmh.eng.br> Cc: Ivo van Doorn <IvDoorn@gmail.com> Cc: Matthew Garrett <mjg@redhat.com> Cc: Andrew Bird <ajb@spheresystems.co.uk> Cc: Greg Kroah-Hartman <gregkh@suse.de> Cc: Cezary Jackiewicz <cezary.jackiewicz@gmail.com> Cc: Philip Langdale <philipl@overt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* rfkill: rename rfkill_mutex to rfkill_global_mutexHenrique de Moraes Holschuh2008-08-29
| | | | | | | | | | | | 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 <hmh@hmh.eng.br> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Cc: Michael Buesch <mb@bu3sch.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* rfkill: add WARN and BUG_ON paranoia (v2)Henrique de Moraes Holschuh2008-08-29
| | | | | | | | | | | | 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 <hmh@hmh.eng.br> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Cc: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* rfkill: add missing line breakFelipe Balbi2008-08-29
| | | | | | | | | | Trivial patch adding a missing line break on rfkill_claim_show(). Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com> Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Acked-by: Ivo van Doorn <IvDoorn@gmail.co> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* rfkill: use strict_strtoul (v2)Henrique de Moraes Holschuh2008-08-29
| | | | | | | | Switch sysfs parsing to something that actually works properly. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* rfkill: introduce RFKILL_STATE_MAXHenrique de Moraes Holschuh2008-08-22
| | | | | | | | | | | | | | 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 <hmh@hmh.eng.br> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* rfkill: add __must_check annotationsHenrique de Moraes Holschuh2008-08-22
| | | | | | | | | | | | | | | | | | 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 <hmh@hmh.eng.br> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Cc: Matthew Garrett <mjg@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* rfkill: add default global states (v2)Henrique de Moraes Holschuh2008-08-22
| | | | | | | | | | | | | | | | | | | 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 <hmh@hmh.eng.br> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* rfkill: detect bogus double-registering (v2)Henrique de Moraes Holschuh2008-08-22
| | | | | | | | | | | | | Detect and abort with -EEXIST if rfkill_register is called twice on the same rfkill struct. And WARN_ON(it) for good measure. While at it, flag when we are adding the first switch of a type, we will need that information later. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Cc: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* rfkill: protect suspended rfkill controllersHenrique de Moraes Holschuh2008-08-18
| | | | | | | | | Guard rfkill controllers attached to a rfkill class against state changes after class suspend has been issued. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* RFKILL: set the status of the leds on activation.Dmitry Baryshkov2008-08-01
| | | | | | | | | | Provide default activate function to set the state of the led when the led becomes bound to the trigger Signed-off-by: Dmitry Baryshkov <dbaryshkov@gmail.com> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* RFKILL: allow one to specify led trigger nameDmitry Baryshkov2008-08-01
| | | | | | | | | | Allow the rfkill driver to specify led trigger name. By default it still defaults to the name of rfkill switch. Signed-off-by: Dmitry Baryshkov <dbaryshkov@gmail.com> Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* rfkill: query EV_SW states when rfkill-input (re)?connects to a input deviceHenrique de Moraes Holschuh2008-08-01
| | | | | | | | | | | | | | | | Every time a new input device that is capable of one of the rfkill EV_SW events (currently only SW_RFKILL_ALL) is connected to rfkill-input, we must check the states of the input EV_SW switches and take action. Otherwise, we will ignore the initial switch state. We also need to re-check the states of the EV_SW switches after a device that was under an exclusive grab is released back to us, since we got no input events from that device while it was grabbed. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Cc: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* rfkill: yet more minor kernel-doc fixesHenrique de Moraes Holschuh2008-07-29
| | | | | | | | | | For some stupid reason, I sent and old version of the patch minor kernel doc-fix patch, and it got merged before I noticed the problem. This is an incremental fix on top. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
generated by cgit v1.2.2 (git 2.25.0) at 2024-12-23 17:24:05 -0500