summaryrefslogtreecommitdiffstats
path: root/net/wimax/op-rfkill.c
Commit message (Collapse)AuthorAgeFilesLines
* Fix typos in commentsThomas Weber2010-03-161-1/+1
| | | | | | | | | | | [Ss]ytem => [Ss]ystem udpate => update paramters => parameters orginal => original Signed-off-by: Thomas Weber <swirl@gmx.li> Acked-by: Randy Dunlap <rdunlap@xenotime.net> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* const: struct nla_policyAlexey Dobriyan2010-02-181-2/+1
| | | | | | | | Make remaining netlink policies as const. Fixup coding style where needed. Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: Move && and || to end of previous lineJoe Perches2009-11-291-4/+4
| | | | | | | | | | | Not including net/atm/ Compiled tested x86 allyesconfig only Added a > 80 column line or two, which I ignored. Existing checkpatch plaints willfully, cheerfully ignored. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* wimax: allow WIMAX_RF_QUERY calls when state is still uninitializedInaky Perez-Gonzalez2009-10-191-1/+8
| | | | | | | | | | | | | | | | | | | | Until now, calls to wimax_rfkill() will be blocked until the device is at least past the WIMAX_ST_UNINITIALIZED state, return -ENOMEDIUM when the device is in the WIMAX_ST_DOWN state. In parallel, wimax-tools would issue a wimax_rfkill(WIMAX_RF_QUERY) call right after opening a handle with wimaxll_open() as means to verify if the interface is really a WiMAX interface [newer kernel version will have a call specifically for this]. The combination of these two facts is that in some cases, before the driver has finalized initializing its device's firmware, a wimaxll_open() call would fail, when it should not. Thus, change the wimax_rfkill() code to allow queries when the device is in WIMAX_ST_UNINITIALIZED state. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
* wimax: indicate initial SW rfkill state is "blocked"Inaky Perez-Gonzalez2009-10-191-0/+1
| | | | | | | | | | | | The WiMAX stack assumes that all WiMAX devices are SW OFF when they are initialized. The recent changes in the RFKILL stack thus cause an initial call after rfkill_register(), because by default, rfkill considers devices to be SW ON upon registration. So call rfkill_init_sw_state() to set it to SW OFF so rfkill_register() doesn't do that unnecessary step. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
* wimax: fix warning caused by not checking retval of rfkill_set_hw_state()Inaky Perez-Gonzalez2009-06-111-1/+2
| | | | | | | Caused by an API update. The return value can be safely ignored, as there is notthing we can do with it. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
* rfkill: rewriteJohannes Berg2009-06-031-97/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* rfkill: remove user_claim stuffJohannes Berg2009-04-221-1/+0
| | | | | | | | | | | 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>
* rfkill: remove deprecated state constantsJohannes Berg2009-04-221-4/+4
| | | | | | | | | | | I only did superficial review, but these constants are stupid to have and without proper warnings nobody will review the code anyway, no amount of shouting will help. Also fix wimax to use correct states. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* wimax: testing for rfkill support should also test for CONFIG_RFKILL_MODULEInaky Perez-Gonzalez2009-01-081-1/+1
| | | | | | | | | Current WiMAX rfkill code is missing the case where rfkill is compiled in as modules and works only when rfkill is compiled in. This is not correct. Fixed to test for CONFIG_RFKILL or CONFIG_RKILL_MODULE. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* wimax: basic API: kernel/user messaging, rfkill and resetInaky Perez-Gonzalez2009-01-071-0/+532
Implements the three basic operations provided by the stack's control interface to WiMAX devices: - Messaging channel between user space and driver/device This implements a direct communication channel between user space and the driver/device, by which free form messages can be sent back and forth. This is intended for device-specific features, vendor quirks, etc. - RF-kill framework integration Provide most of the RF-Kill integration for WiMAX drivers so that all device drivers have to do is after wimax_dev_add() is call wimax_report_rfkill_{hw,sw}() to update initial state and then every time it changes. Provides wimax_rfkill() for the kernel to call to set software RF-Kill status and/or query current hardware and software switch status. Exports wimax_rfkill() over generic netlink to user space. - Reset a WiMAX device Provides wimax_reset() for the kernel to reset a wimax device as needed and exports it over generic netlink to user space. This API is clearly limited, as it still provides no way to do the basic scan, connect and disconnect in a hardware independent way. The WiMAX case is more complex than WiFi due to the way networks are discovered and provisioned. The next developments are to add the basic operations so they can be offerent by different drivers. However, we'd like to get more vendors to jump in and provide feedback of how the user/kernel API/abstraction layer should be. The user space code for the i2400m, as of now, uses the messaging channel, but that will change as the API evolves. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
OpenPOWER on IntegriCloud