- 02 Feb, 2012 7 commits
-
-
Emmanuel Grumbach authored
All the bus configuration is now done in the transport allocation fucntion. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
Emmanuel Grumbach authored
Change the way we alloc the transport on the way. Since the transport is allocated from a bus specific area, we can give the bus specific parameters (i.e. pci_dev for PCI) to the transport. This will be useful when the bus layer will be killed. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
Emmanuel Grumbach authored
Allocating the shrd area dynamically will allow more agility while revamping the flows. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
Emmanuel Grumbach authored
There is no link between the two. Ensure that the NIC is on outside the code of the EEPROM handling. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
Gregory Greenman authored
This patch connects IDI transport to driver. It does so by using a number of ifdefs at this stage. IDI is a new transport that is under development. Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
Emmanuel Grumbach authored
Define a new handler in the transport layer API: fw_alive. Move iwl_reset_ict to this new handler, and move the content of tx_start to this handler. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
Wey-Yi Guy authored
Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next into wireless-next
-
- 30 Jan, 2012 17 commits
-
-
Larry Finger authored
This patch addresses a kernel bugzilla report and two recent mail threads. The kernel bugzilla report is https://bugzilla.kernel.org/show_bug.cgi?id=42632, which reports a udev timeout on boot. The first mail thread, which was on LKML (http://lkml.indiana.edu/hypermail/ linux/kernel/1112.3/00965.html) was for a WARNING that occurs after a suspend/resume cycle for rtl8192cu. The scond mail thread (http://marc.info/?l=linux-wireless&m=132655490826766&w=2) concerned changes in udev that break drivers that delay while firmware is loaded on modprobe. This patch converts all rtlwifi-based drivers to use the asynchronous firmware loading mechanism. Drivers rtl8192ce, rtl8192cu and rtl8192de share a common callback routine. Driver rtl8192se needs different handling of the firmware, thus it has its own code. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Cc: Stable <stable@vger.kernel.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Sujith Manoharan authored
channelFlags doesn't contain the operating HT mode. Use IS_CHAN_HT40 to determine if the current channel is in HT40 mode. Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Sujith Manoharan authored
This patch modifies ath9k_htc to load the needed firmware in an asynchronous manner, fixing timeouts that were introduced with the new udev changes. Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Rafał Miłecki authored
Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
Whenever the PAN (P2P) context is active, it has timers in the uCode that prevent sleep, so scanning can't be out of channel for more than the beacon interval programmed into the device. Before this patch, a full scan including any passive channels when P2P was active would stall forever because it wouldn't find time to execute the passive requests (for default beacon intervals of 100 TU.) Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Wey-Yi Guy authored
Led has no use for some platform. Add additional module parameter option to disable LED Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
Fix multiple bugs in event tracing: 1) If you enable uCode tracing with the device down, it will still attempt to access the device and continuously log "MAC is in deep sleep!" errors. Fix this by only starting logging when the device is actually alive. 2) Now you can set the flag when the device is down, but logging doesn't happen when you bring it up. To fix that, start logging when the device comes alive. This means we don't log before -- we could do that but I don't need it right now. 3) For some reason we read the error instead of the event log -- use the right pointer. 4) Optimise SRAM reading of event log header. 5) Fix reading write pointer == capacity, which can happen due to racy SRAM access 6) Most importantly: fix an error where we would try to read WAY too many events (like 2^32-300) when we read the wrap counter before it is updated by the uCode -- this does happen in practice and will cause the driver to hang the machine. 7) Finally, change the timer to 10ms instead of 100ms as 100ms is too slow to capture all data with a normal event log and with 100ms the log will wrap multiple times before we have a chance to read it. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Wey-Yi Guy authored
Fix few places of typo Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Helmut Schaa authored
Unted the assumption that the sta struct is still accessible before the synchronize_rcu call we should move the num_sta_ps counter decrement after synchronize_rcu to avoid incorrect decrements if num_sta_ps. Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Simon Wunderlich authored
* Handle MCS masks set by the user. * Match rates provided by the rate control algorithm to the mask set, also in HT mode, and switch back to legacy mode if necessary. * add debugfs files to observate the rate selection Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de> Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Simon Wunderlich authored
Allow to set mcs masks through nl80211. We also allow to set MCS rates but no legacy rates (and vice versa). Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de> Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Larry Finger authored
Although the rtlwifi family of devices contains 11 copies of the pr_fmt macro, the macro is not defined for all routines that need it. By moving the macro to wifi.h, a single copy is available for all routines. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Helmut Schaa authored
If the driver blocked this specific STA with the help of ieee80211_sta_block_awake we won't clear WLAN_STA_PS_STA later but still decrement num_sta_ps. Hence, the next data frame from this STA will trigger ap_sta_ps_end again and also decrement num_sta_ps again leading to an incorrect num_sta_ps counter. This can result in problems with powersaving clients not waking up from PS because the TIM calculation might be skipped due to the incorrect num_sta_ps counter. Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Helmut Schaa authored
When WLAN_STA_PS_DRIVER is set by ieee80211_sta_block_awake the num_sta_ps counter is not incremented. Hence, we shouldn't decrement it in __sta_info_destroy if only WLAN_STA_PS_DRIVER is set. This could result in an incorrect num_sta_ps counter leading to strange side effects with associated powersaving clients. Fix this by only decrementing num_sta_ps when WLAN_STA_PS_STA was set before. Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
In the future, when we start notifying drivers, state transitions could potentially fail. To make it easier to distinguish between programming bugs and driver failures: * rename sta_info_move_state() to sta_info_pre_move_state() which can only be called before the station is inserted (and check this with a new station flag). * rename sta_info_move_state_checked() to just plain sta_info_move_state(), as it will be the regular function that can fail for more than just one reason (bad transition or an error from the driver) This makes the programming model easier -- one of the functions can only be called before insertion and can't fail, the other can fail. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
John W. Linville authored
This reverts commit f1e3be15. Johannes Berg <johannes@sipsolutions.net> thinks that this patch is incorrect. I'll defer to his judgment. Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
John W. Linville authored
The device seems to survive the issue, so no need to flood the logs about it... Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
- 28 Jan, 2012 5 commits
-
-
Johannes Berg authored
Whenever the PAN (P2P) context is active, it has timers in the uCode that prevent sleep, so scanning can't be out of channel for more than the beacon interval programmed into the device. Before this patch, a full scan including any passive channels when P2P was active would stall forever because it wouldn't find time to execute the passive requests (for default beacon intervals of 100 TU.) Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
Wey-Yi Guy authored
Led has no use for some platform. Add additional module parameter option to disable LED Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
Johannes Berg authored
Fix multiple bugs in event tracing: 1) If you enable uCode tracing with the device down, it will still attempt to access the device and continuously log "MAC is in deep sleep!" errors. Fix this by only starting logging when the device is actually alive. 2) Now you can set the flag when the device is down, but logging doesn't happen when you bring it up. To fix that, start logging when the device comes alive. This means we don't log before -- we could do that but I don't need it right now. 3) For some reason we read the error instead of the event log -- use the right pointer. 4) Optimise SRAM reading of event log header. 5) Fix reading write pointer == capacity, which can happen due to racy SRAM access 6) Most importantly: fix an error where we would try to read WAY too many events (like 2^32-300) when we read the wrap counter before it is updated by the uCode -- this does happen in practice and will cause the driver to hang the machine. 7) Finally, change the timer to 10ms instead of 100ms as 100ms is too slow to capture all data with a normal event log and with 100ms the log will wrap multiple times before we have a chance to read it. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
Wey-Yi Guy authored
Fix few places of typo Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
Wey-Yi Guy authored
Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next into wireless-next
-
- 27 Jan, 2012 11 commits
-
-
Yogesh Ashok Powar authored
While configuring the broadcast key in the hardware, in multi-BSS environment, BSSes other than first were incorrectly configured with the MAC address of first BSS. Fixing it with correct MAC addresses. Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Nicolas Cavallari authored
Currently, when we are on an IBSS network with no active station, we would scan for other BSSID, even if fixed_bssid is on, due to a bug in ibss.c, where fixed_channel would be checked instead of fixed_bssid. This would trigger useless scans where scan results would not be used anyway. This patch also reverts commit 39d02a7d, which assumed that the ifibss->fixed_channel check was legitimate to disable single-channel scans. IBSS single-channel scan should now be fixed. Signed-off-by: Nicolas Cavallari <cavallar@lri.fr> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Eliad Peller authored
The sta might be in psm against the ap (e.g. because this was the before a hw restart), so we explicitly send a null packet in order to make sure it'll sync against the ap (and get out of psm). Signed-off-by: Eliad Peller <eliad@wizery.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Dan Carpenter authored
This is a pointer so it should be NULL instead of zero. Sparse complains about this stuff: net/nfc/nci/core.c:447:37: warning: Using plain integer as NULL pointer Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Amitkumar Karwar authored
This enables user to check beacon interval, DTIM period, short slot time and short preamble information using "iw dev mlan0 link" command when station is in connected state. Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Avinash Patil authored
Pass mwifiex_private pointer directly to wmm_add_buf_txqueue() instead of passing adapter and then deriving priv again in mwifiex_get_priv_by_id(). This reduces a 'for' loop in TX path. Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Stanislaw Gruszka authored
This seems to be only needed as workaround for hardware problem on PCI devices. Acked-by: Helmut Schaa <helmut.schaa@googlemail.com> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Stanislaw Gruszka authored
Zero all other bits than RESET_CSR and RESET_BBP when want to do the reset, that the vendor driver behaviour. Acked-by: Helmut Schaa <helmut.schaa@googlemail.com> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Stanislaw Gruszka authored
We can receive frames just after firmware load with current code, so disable DMA just after firmware is loaded, not before. Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Stanislaw Gruszka authored
Ralink USB driver initialize H2M_INT_SRC to 0 after firmware load, and never touch this register later. It is not touched at all by Ralink PCI driver. Acked-by: Helmut Schaa <helmut.schaa@googlemail.com> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Randy Dunlap authored
Fix new kernel-doc warnings: Warning(include/net/cfg80211.h:1165): No description found for parameter 'channel_type' Warning(include/net/cfg80211.h:2090): No description found for parameter 'probe_resp_offload' Signed-off-by: Randy Dunlap <rdunlap@xenotime.net> Cc: Johannes Berg <johannes@sipsolutions.net> Cc: linux-wireless@vger.kernel.org Signed-off-by: John W. Linville <linville@tuxdriver.com>
-