- 18 Apr, 2012 1 commit
-
-
Emmanuel Grumbach authored
The driver layer now holds a pointer to the transport, and shrd->drv is not needed any more, so kill it. Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
- 17 Apr, 2012 13 commits
-
-
Amitkumar Karwar authored
We get two timing related fields for each bss from firmware in scan results. 1) timestamp - Actual timestamp information in probe response/beacon 2) network_tsf - firmware's TSF value at the time the beacon or probe response was received. Both are needed while associating by firmware. The patch takes care of following things. 1) We should pass "timestamp" to cfg80211_inform_bss(), but currently "network_tsf" is being provided. This error is corrected here. 2) Rename "network_tsf" to "fw_tsf" 3) Make use of u64 variable instead of an array of u8/u32 to save parsed "timestamp" information. 4) Use timestamp provided to stack in scan results using cfg80211_inform_bss() while associating. (bss->tsf) 5) Allocate space to save fw_tsf in "priv" of cfg80211_bss and retrieve it while associating. 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>
-
Amitkumar Karwar authored
Rearrange some code to save extra parameters to the functions. Signed-off-by:
-
Daniel Drake authored
Signed-off-by:
Daniel Drake <dsd@laptop.org> Acked-by:
Dan Williams <dcbw@redhat.com> Signed-off-by:
-
Daniel Drake authored
Signed-off-by:
-
Daniel Drake authored
As described at http://article.gmane.org/gmane.linux.kernel.wireless.general/86084 libertas is taking a long time to load because it loads firmware during module loading. Add a new API for interface drivers to load their firmware asynchronously. The same semantics of the firmware table are followed like before. Interface drivers will be converted in follow-up patches, then we can remove the old, synchronous firmware loading function. Signed-off-by:
-
Daniel Drake authored
These simple sanity check avoids extra complexity in error paths when moving to asynchronous firmware loading (which means the device may fail to init some time after its creation). Signed-off-by:
-
Daniel Drake authored
Remove the ability to pass module parameters with firmware filenames for USB and SDIO interfaces. Remove the ability to pass custom "user" filenames to lbs_get_firmware(). Remove the ability to reprogram internal device memory with a different firmware from the USB driver (we don't know of any users), and simplify the OLPC firmware loading quirk to simply placing the OLPC firmware at the top of the list (we don't know of any users other than OLPC). Move lbs_get_firmware() into its own file. These simplifications should have no real-life effect but make the upcoming transition to asynchronous firmware loading considerably less painful. Signed-off-by:
-
Andreas Hartmann authored
There are connection stalls or very poor throughputs with rt2800 hardware using 802.11n in AP mode since patch "mac80211: retry sending failed BAR frames later instead of tearing down aggr"[1][2]. Since rt2800 hardware is not able to correctly report the tx status of BAR frames, this patch removes as workaround the existing error handling on AP side, which lets mac80211 send a BAR when an AMPDU subframe fails. As a result, most wifi clients (aside from Intel STAs on Windows) instead will timeout now the reorder buffer and request the lost frame again. The correct solution would be, to tear down BA session on AP side. This patch was born on the basis of "[RFT] rt2x00: Tear down BA session on QoS frame failure"[3]. Thanks to Helmut Schaa for his support! [1] http://thread.gmane.org/gmane.linux.kernel.wireless.general/83297/focus=83304 [2] http://git.kernel.org/?p=linux/kernel/git/linville/wireless-testing.git;a=commit;h=f0425beda4d404a6e751439b562100b902ba9c98 [3] http://thread.gmane.org/gmane.linux.drivers.rt2x00.user/569Signed-off-by:
Andreas Hartmann <andihartmann@01019freenet.de> Acked-by:
Helmut Schaa <helmut.schaa@googlemail.com> Signed-off-by:
-
Gabor Juhos authored
The FBIN2FREQ macro and the ath9k_hw_fbin2freq function does the same thing. Remove the macro, and use the inline function instead. Signed-off-by:
Gabor Juhos <juhosg@openwrt.org> Signed-off-by:
-
Gabor Juhos authored
Both eeprom.c and ar9003_eeprom.c has an indentical 'ath9k_hw_fbin2freq' function. Move the function to a common place and remove the duplicates. Signed-off-by:
-
Gabor Juhos authored
Signed-off-by:
-
Gabor Juhos authored
The existing constants are used for reduction/increase tx power level on devices with 2x2 and 3x3 chainmask. Both reduction and increase must use the same value, so it makes no sense to use separate constants for them. Signed-off-by:
-
Julia Lawall authored
Add a corresponding leave call on error failure. Signed-off-by:
Julia Lawall <Julia.Lawall@lip6.fr> Acked-by:
-
- 16 Apr, 2012 26 commits
-
-
Johannes Berg authored
The command strings are needed through the layers for debug and error messages, but can differ with opmode. As a result, we need to give the command names to the transport layer as configuration. Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Johannes Berg authored
Having a u32 before a potential 64-bit value is not very efficient, move it last. Signed-off-by:
-
David Spinadel authored
To support hybrid state of MVM op_mode, most of the functioanallity will be done using DVM functions. When MVM will have independant live, the declarations will be removed and the functions will be static back. Signed-off-by:
David Spinadel <david.spinadel@intel.com> Signed-off-by:
-
David Spinadel authored
Implement mapping of channel to TX power channel group, for sending channel specific data before add context. Signed-off-by:
-
Dor Shaish authored
Add a variable for disabling specific calibrations. Merged old variables for calibrations disabling. Signed-off-by:
Dor Shaish <dor.shaish@intel.com> Signed-off-by:
-
Emmanuel Grumbach authored
Signed-off-by:
-
David Spinadel authored
Signed-off-by:
-
David Spinadel authored
Set size of firmware section in mvm bundle format. Signed-off-by:
-
Johannes Berg authored
The declaration isn't needed as the struct is only used in code that includes the right header file. Signed-off-by:
-
Don Fry authored
The code has been changed, move the definitions to the proper file being used by the code. Signed-off-by:
Don Fry <donald.h.fry@intel.com> Signed-off-by:
-
Amit Beka authored
This register is used to enable some debug mechanisms. Signed-off-by:
Amit Beka <amit.beka@intel.com> Signed-off-by:
-
Don Fry authored
The HCMD_ACTIVE bit is only used in trans. Signed-off-by:
-
Don Fry authored
When WiMax takes over the RF, inform the op_mode. Signed-off-by:
-
Johannes Berg authored
It doesn't even exist as a module parameter, so just remove the item from the struct. Signed-off-by:
-
Johannes Berg authored
We've never released firmware using the alternatives mechanism and our build process makes that difficult anyway. This means that in every file we have ever built (except maybe by hand for testing) the listed alternative was 0. Make the alternative field in the TLVs part of the TLV number (thus expanding that to 32 bits); this gives us more TLV numbers (not really needed) and more importantly protects against rogue firmware files that actually do use the alternatives mechanism -- those will now be rejected since they don't contain any valid TLVs. Signed-off-by:
-
Johannes Berg authored
My original idea with this was to adjust the sleep pattern of the uCode based on the maximum network latency userspace asked for. Due to nobody wanting to test it, this logic was disabled by default. It seems the time has come to remove it, since it's not only always disabled but there also don't seem to be any applications that actually request a max network latency. Signed-off-by:
-
Xose Vazquez Perez authored
RT539x devices: (0x1814, 0x5362) (0x1814, 0x5392) Taken from ralink driver 2011_0406_RT5390_RT5392_Linux_STA_V2.5.0.3_DPO Signed-off-by:
Xose Vazquez Perez <xose.vazquez@gmail.com> Acked-by:
Gertjan van Wingerde <gwingerde@gmail.com> Signed-off-by:
-
Xose Vazquez Perez authored
put back 0x050d,0x7050 to rt73usb, same usb_id for two chips: K7SF5D7050A ver 2xxx is rt2500 K7SF5D7050B ver 3xxx is rt73 <http://en-us-support.belkin.com/app/answers/detail/a_id/297/kw/K7SF5D7050> Signed-off-by:
-
Gabor Juhos authored
Signed-off-by:
-
Gabor Juhos authored
The computation of the scaled power value in various eeprom files uses identical code. Move that code into a helper function and use that instead of code duplication. Signed-off-by:
-
Gabor Juhos authored
The REDUCE_SCALED_POWER_BY_THREE_CHAIN symbol is defined in different eeprom files, and the value varies between the different files. In eeprom_def.c and in ar9003_eeprom.c the value of the symbol is 9, however the comments in these files indicates the value should be 10*log10(3)*2 which is 9.54242509439325. Replace the the value to 10 in these files. Also add comments to eeprom_9287.c. Signed-off-by:
-
Gabor Juhos authored
We have a helper function for updating the max_power_level value. Use that and remove the duplicated code. Signed-off-by:
-
Axel Lin authored
This patch converts the drivers in drivers/net/wireless/* to use module_pci_driver() macro which makes the code smaller and a bit simpler. Signed-off-by:
Axel Lin <axel.lin@gmail.com> Cc: "John W. Linville" <linville@tuxdriver.com> Cc: Jiri Slaby <jirislaby@gmail.com> Cc: Nick Kossifidis <mickflemm@gmail.com> Cc: "Luis R. Rodriguez" <mcgrof@qca.qualcomm.com> Cc: Simon Kelley <simon@thekelleys.org.uk> Cc: Jouni Malinen <j@w1.fi> Cc: Lennert Buytenhek <buytenh@wantstofly.org> Cc: Christian Lamparter <chunkeey@googlemail.com> Cc: Ivo van Doorn <IvDoorn@gmail.com> Cc: Larry Finger <Larry.Finger@lwfinger.net> Cc: linux-wireless@vger.kernel.org Acked-by:
Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by:
-
Wey-Yi Guy authored
Add utility function to provide the average rssi per vif Signed-off-by:
-
Larry Finger authored
When rtl8192ce is in operation, kmemleak indicates a number of leaks, yet when the driver is removed all are gone. These false positives happen in two locations: unreferenced object 0xffff880041124000 (size 9536): comm "work_for_cpu", pid 9295, jiffies 4295037203 (age 20596.320s) hex dump (first 32 bytes): 33 00 00 01 01 6d 00 00 00 00 b1 0e 21 0b 00 00 3....m......!... 01 01 6d 00 00 00 00 8b 20 c0 e9 00 00 01 01 6d ..m..... ......m backtrace: [<ffffffff8137a1b1>] kmemleak_alloc+0x21/0x50 [<ffffffff8138d01f>] kmalloc_large_node+0x9a/0xa6 [<ffffffff811335a5>] __kmalloc_node_track_caller+0x175/0x3b0 [<ffffffff812ddfe3>] __alloc_skb+0x73/0x230 [<ffffffff812de1b8>] dev_alloc_skb+0x18/0x30 [<ffffffffa091a3b7>] rtl_pci_probe+0x10e0/0x17d2 [rtlwifi] -- snip -- unreferenced object 0xffff8800b4d3f600 (size 256): comm "kworker/u:2", pid 13221, jiffies 4297830173 (age 9424.568s) hex dump (first 32 bytes): 1c d6 45 b1 00 88 ff ff 1c d6 45 b1 00 88 ff ff ..E.......E..... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff8137a1b1>] kmemleak_alloc+0x21/0x50 [<ffffffff81130f43>] kmem_cache_alloc_node+0x153/0x270 [<ffffffff812ddfb6>] __alloc_skb+0x46/0x230 [<ffffffff812de1b8>] dev_alloc_skb+0x18/0x30 [<ffffffffa093264a>] rtl92c_set_fw_rsvdpagepkt+0x22a/0x5c0 [rtl8192c_common] -- snip -- Signed-off-by:Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
-
Yoshinori Sato authored
This device works fine of ath5k. Details bellow 05:00.0 0200: 168c:ff1b (rev 01) 05:00.0 Ethernet controller: Atheros Communications Inc. Device ff1b (rev 01) Flags: bus master, fast devsel, latency 0, IRQ 19 Memory at febf0000 (64-bit, non-prefetchable) [size=64K] Capabilities: <access denied> Kernel driver in use: ath5k ath5k 0000:05:00.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19 ath5k 0000:05:00.0: setting latency timer to 64 ath5k 0000:05:00.0: registered as 'phy0' ath: EEPROM regdomain: 0x67 ath: EEPROM indicates we should expect a direct regpair map ath: Country alpha2 being used: 00 ath: Regpair used: 0x67 ieee80211 phy0: Selected rate control algorithm 'minstrel_ht' ath5k phy0: Atheros AR2425 chip found (MAC: 0xe2, PHY: 0x70) Signed-off-by:
Yoshinori Sato <ysato@users.sourceforge.jp> Signed-off-by:
-
