summaryrefslogtreecommitdiff
path: root/net/wimax
AgeCommit message (Collapse)Author
2009-06-04wimax: depend on rfkill properlyJohannes Berg
My mistake, I should have added that when cleaning up rfkill and changing wimax. Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Acked-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-06-03rfkill: rewriteJohannes Berg
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>
2009-05-28wimax: Add netlink interface to get device statePaulius Zaleckas
wimax connection manager / daemon has to know what is current state of the device. Previously it was only possible to get notification whet state has changed. Note: By mistake, the new generic netlink's number for WIMAX_GNL_OP_STATE_GET was declared inserting into the existing list of API calls, not appending; thus, it'd break existing API. Fixed by Inaky Perez-Gonzalez <inaky@linux.intel.com> by moving to the tail, where we add to the interface, not modify the interface. Thanks to Stephen Hemminger <shemminger@vyatta.com> for catching this. Signed-off-by: Paulius Zaleckas <paulius.zaleckas@teltonika.lt>
2009-05-28wimax: document why wimax_msg_*() operations can be used in any stateInaky Perez-Gonzalez
Funcion documentation for wimax_msg_alloc() and wimax_msg_send() needs to clarify that they can be used in the very early stages of a wimax_dev lifecycle. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-05-08Merge branch 'master' of ↵David S. Miller
master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6 Conflicts: include/net/tcp.h
2009-05-06wimax: oops: wimax_dev_add() is the only one that can initialize the stateInaky Perez-Gonzalez
When a new wimax_dev is created, it's state has to be __WIMAX_ST_NULL until wimax_dev_add() is succesfully called. This allows calls into the stack that happen before said time to be rejected. Until now, the state was being set (by mistake) to UNINITIALIZED, which was allowing calls such as wimax_report_rfkill_hw() to go through even when a call to wimax_dev_add() had failed; that was causing an oops when touching uninitialized data. This situation is normal when the device starts reporting state before the whole initialization has been completed. It just has to be dealt with. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-05-06wimax: fix oops if netlink fails to add attributeInaky Perez-Gonzalez
When sending a message to user space using wimax_msg(), if nla_put() fails, correctly interpret the return code from wimax_msg_alloc() as an err ptr and return the error code instead of crashing (as it is assuming than non-NULL means the pointer is ok). Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-04-22rfkill: remove user_claim stuffJohannes Berg
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>
2009-04-22rfkill: remove deprecated state constantsJohannes Berg
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>
2009-03-30trivial: fix typos/grammar errors in Kconfig textsMatt LaPlante
Signed-off-by: Matt LaPlante <kernel1@cyberdogtech.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2009-02-14Merge branch 'master' of /home/davem/src/GIT/linux-2.6/David S. Miller
Conflicts: drivers/net/wireless/iwlwifi/iwl-agn.c drivers/net/wireless/iwlwifi/iwl3945-base.c
2009-02-12wimax: fix oops in wimax_dev_get_by_genl_info() when looking up non-wimax ifaceInaky Perez-Gonzalez
When a non-wimax interface is looked up by the stack, a bad pointer is returned when the looked-up interface is not found in the list (of registered WiMAX interfaces). This causes an oops in the caller when trying to use the pointer. Fix by properly setting the pointer to NULL if we don't exit from the list_for_each() with a found entry. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-02-05netlink: change return-value logic of netlink_broadcast()Pablo Neira Ayuso
Currently, netlink_broadcast() reports errors to the caller if no messages at all were delivered: 1) If, at least, one message has been delivered correctly, returns 0. 2) Otherwise, if no messages at all were delivered due to skb_clone() failure, return -ENOBUFS. 3) Otherwise, if there are no listeners, return -ESRCH. With this patch, the caller knows if the delivery of any of the messages to the listeners have failed: 1) If it fails to deliver any message (for whatever reason), return -ENOBUFS. 2) Otherwise, if all messages were delivered OK, returns 0. 3) Otherwise, if no listeners, return -ESRCH. In the current ctnetlink code and in Netfilter in general, we can add reliable logging and connection tracking event delivery by dropping the packets whose events were not successfully delivered over Netlink. Of course, this option would be settable via /proc as this approach reduces performance (in terms of filtered connections per seconds by a stateful firewall) but providing reliable logging and event delivery (for conntrackd) in return. This patch also changes some clients of netlink_broadcast() that may report ENOBUFS errors via printk. This error handling is not of any help. Instead, the userspace daemons that are listening to those netlink messages should resync themselves with the kernel-side if they hit ENOBUFS. BTW, netlink_broadcast() clients include those that call cn_netlink_send(), nlmsg_multicast() and genlmsg_multicast() since they internally call netlink_broadcast() and return its error value. Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-01-29wimax: fix build issue when debugfs is disabledInaky Perez-Gonzalez
As reported by Toralf Förster and Randy Dunlap. - http://linuxwimax.org/pipermail/wimax/2009-January/000460.html - http://lkml.org/lkml/2009/1/29/279 The definitions needed for the wimax stack and i2400m driver debug infrastructure was, by mistake, compiled depending on CONFIG_DEBUG_FS (by them being placed in the debugfs.c files); thus the build broke in 2.6.29-rc3 when debugging was enabled (CONFIG_WIMAX_DEBUG) and DEBUG_FS was disabled. These definitions are always needed if debug is enabled at compile time (independently of DEBUG_FS being or not enabled), so moving them to a file that is always compiled fixes the issue. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-01-08wimax: testing for rfkill support should also test for CONFIG_RFKILL_MODULEInaky Perez-Gonzalez
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>
2009-01-08wimax: fix kconfig interactions with rfkill and input layersInaky Perez-Gonzalez
WiMAX can work without RFKILL, but it was missing a check to make sure RFKILL is not being made a module with wimax compiled into the kernel. This caused failed builds in s390, where CONFIG_INPUT is always off. When RFKILL is enabled, the code uses the input layer to report hardware switch changes; thus, if RFKILL is enabled, INPUT has to be too. It also needs to display some message when INPUT is disabled that explains why WiMAX is not selectable. (issues found by Randy Dunlap in the linux-next tree). Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-01-08wimax: fix '#ifndef CONFIG_BUG' layout to avoid warningInaky Perez-Gonzalez
Reported by Randy Dunlap: > Also, this warning needs to be fixed: > > linux-next-20090106/net/wimax/id-table.c:133: warning: ISO C90 > forbids mixed declarations and code Move the return on #defined(CONFIG_BUG) below the variable declarations so it doesn't violate ISO C90. On wimax_id_table_release() we want to do a debug check if CONFIG_BUG is enabled. However, we also want the debug code to be always compiled to ensure there is no bitrot. It will be optimized out by the compiler when CONFIG_BUG is disabled. Added a note to the function header stating this. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-01-07wimax: Makefile, Kconfig and docbook linkage for the stackInaky Perez-Gonzalez
This patch provides Makefile and KConfig for the WiMAX stack, integrating them into the networking stack's Makefile, Kconfig and doc-book templates. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-01-07wimax: debugfs controlsInaky Perez-Gonzalez
Expose knobs to control the stack's debug output. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-01-07wimax: basic API: kernel/user messaging, rfkill and resetInaky Perez-Gonzalez
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>
2009-01-07wimax: generic device management (registration, deregistration, lookup)Inaky Perez-Gonzalez
Implements the basic life cycles of a 'struct wimax_dev', some common generic netlink functionality for marshalling calls to user space, and the device state machine. For looking up net devices based on their generic netlink family IDs, use a low overhead method that optimizes for the case where most systems have a single WiMAX device, or at most, a very low number of WiMAX adaptors. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-01-07wimax: debug macros and debug settings for the WiMAX stackInaky Perez-Gonzalez
This file contains a simple debug framework that is used in the stack; it allows the debug level to be controlled at compile-time (so the debug code is optimized out) and at run-time (for what wasn't compiled out). This is eventually going to be moved to use dynamic_printk(). Just need to find time to do it. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-01-07wimax: internal API for the kernel space WiMAX stackInaky Perez-Gonzalez
This file contains declarations and definitions used by the different submodules of the stack. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>