- 08 Feb, 2012 6 commits
-
-
Gertjan van Wingerde authored
Align with v2.5.0.0 Ralink RT3572 driver for 2.4GHz band channel switch. Signed-off-by:
Gertjan van Wingerde <gwingerde@gmail.com> Acked-by:
Stanislaw Gruszka <sgruszka@redhat.com> Acked-by:
Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Gertjan van Wingerde authored
This brings the rt2800 channel switching code for RT3572 closer to the v2.5.0.0 Ralink RT3572 driver. Signed-off-by:
-
Gertjan van Wingerde authored
The comment states that the field is only used for rt61pci and rt73usb. However, it is now used by rt2800pci and rt2800usb as well, so the comment is not correct anymore. Update the comment to not state any low-level drivers anymore. Signed-off-by:
-
Gertjan van Wingerde authored
Start using the struct rt2x00_dev driver data in rt2800 for the calibration data. Signed-off-by:
-
Gertjan van Wingerde authored
We are getting more and more fields in struct rt2x00_dev that are specific to one or two of the low-level drivers. Instead of putting these fields inside the main structure and thus clobbering all low-level drivers with these fields, introduce the concept of driver data inside struct rt2x00_dev, whose size is indicated by the low-level driver and which can be populated by the low-level driver. Signed-off-by:
-
David Gibson authored
The two orinoco mailing lists on sourceforge were set up many years ago and are now more or less moribund. I'd like to shut them down, so I don't have to keep filtering the spam from them (which is most of what comes through now). In preparation, this patch removes the reference to them from the MAINTAINERS file. Any remaining discussion of this approaching obsolete driver can go to the linux-wireless list. Signed-off-by:
David Gibson <hermes@gibson.dropbear.id.au> Acked-by:
Pavel Roskin <proski@gnu.org> Signed-off-by:
-
- 06 Feb, 2012 34 commits
-
-
Johannes Berg authored
There are situations where we don't have the necessary rate control information yet for station entries, e.g. when associating. This currently doesn't really happen due to the dummy station handling; explicitly disabling rate control when it's not initialised will allow us to remove dummy stations. Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Stanislaw Gruszka authored
We do not need that callback, settings parameters can be done locally. Signed-off-by:
-
Stanislaw Gruszka authored
It's just wrapper to sk_buff pointers ... Signed-off-by:
-
Stanislaw Gruszka authored
Signed-off-by:
-
Stanislaw Gruszka authored
Signed-off-by:
-
Stanislaw Gruszka authored
Signed-off-by:
-
Stanislaw Gruszka authored
Signed-off-by:
-
Stanislaw Gruszka authored
Signed-off-by:
-
Stanislaw Gruszka authored
Signed-off-by:
-
Stanislaw Gruszka authored
Signed-off-by:
-
Stanislaw Gruszka authored
Signed-off-by:
-
Stanislaw Gruszka authored
Signed-off-by:
-
Stanislaw Gruszka authored
Signed-off-by:
-
Stanislaw Gruszka authored
Signed-off-by:
-
Stanislaw Gruszka authored
Signed-off-by:
-
Stanislaw Gruszka authored
Signed-off-by:
-
Stanislaw Gruszka authored
Signed-off-by:
-
Stanislaw Gruszka authored
Signed-off-by:
-
Stanislaw Gruszka authored
Signed-off-by:
-
Stanislaw Gruszka authored
Signed-off-by:
-
Stanislaw Gruszka authored
Signed-off-by:
-
Stanislaw Gruszka authored
Signed-off-by:
-
Stanislaw Gruszka authored
Signed-off-by:
-
Stanislaw Gruszka authored
Signed-off-by:
-
Stanislaw Gruszka authored
Signed-off-by:
-
Stanislaw Gruszka authored
Signed-off-by:
-
Amitkumar Karwar authored
Earlier we were using dtim period extracted from scan response buffer provided by FW in scan operation. But it is observed that sometimes the buffer doesn't contain dtim period tlv, and wrong value (0) was sent to user space. After association FW will start listening to beacon frames of connected AP and store dtim period. Therefore we can get it from FW in dump_station() instead of using wrong value obtained in scanning. Redundant code after adapting new approach for dtim period is also removed in this patch. Signed-off-by:
Amitkumar Karwar <akarwar@marvell.com> Signed-off-by:
Bing Zhao <bzhao@marvell.com> Signed-off-by:
-
Amitkumar Karwar authored
1) Remove unnecessary switch case usage. 2) Replace "X=cpu_to_le16(le16_to_cpu(X) + Y)" by "le16_add_cpu(X, Y)" 3) Declare "ul_temp" variable as u16 instead of u32 to avoid unnecessary typecasting Signed-off-by:
-
Tim Gardner authored
Memory allocated by ieee80211_alloc_hw() will get orphaned if any subsequent initializations fail. Also don't pci_set_drvdata(pdev, NULL) until just before disabling the PCI device. Functions called by rtl_deinit_core(hw) may eventually need the context (when its actually implemented). Cc: Larry Finger <Larry.Finger@lwfinger.net> Cc: Chaoming Li <chaoming_li@realsil.com.cn> Cc: John W. Linville <linville@tuxdriver.com> Cc: linux-wireless@vger.kernel.org Cc: netdev@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by:
Tim Gardner <tim.gardner@canonical.com> Acked-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
-
Eliad Peller authored
Currently, mac80211 goes to idle-off before starting a scan. However, some devices that implement hw scan might not need going idle-off in order to perform a hw scan, and thus saving some energy and simplifying their state machine. (Note that this is also the case for sched scan - it currently doesn't make mac80211 go idle-off) Add a new flag to indicate support for hw scan while idle. Signed-off-by:
Eliad Peller <eliad@wizery.com> Signed-off-by:
-
Amitkumar Karwar authored
This patch sets default adapter channel_type as HT. Hence the device will opearate in HT mode. Signed-off-by:
-
Amitkumar Karwar authored
In set_channel() callback handler, "priv" pointer is derived from net_device. Sometimes net_device pointer coming from the stack is NULL which causes kernel crash. This patch fixes the problem by deriving "priv" from wiphy when net_device pointer is NULL. Signed-off-by:
-
Yogesh Ashok Powar authored
Using command DEL_MAC_ADDR, remove the mac address of the BSS when it is stopped i.e the corresponding vif is removed. Without this, the stale bss entry will still be maintained in the firmware which causes issues when the BSS's are recreated. Signed-off-by:
Nishant Sarmukadam <nishants@marvell.com> Signed-off-by:
Yogesh Ashok Powar <yogeshp@marvell.com> Signed-off-by:
-
Dan Carpenter authored
If the firmware was over 2G, it would cause memory corruption and the system would die here. Obviously we all know the firmware isn't going to be that large but static checkers get upset. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
