- Apr 17, 2012
-
-
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 <juhosg@openwrt.org> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
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:
Wey-Yi Guy <wey-yi.w.guy@intel.com> 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:
-
Rajkumar Manoharan authored
The tx interrupt for beacon queue is configured only for edma chips. As the edma chip does not support per descriptor interrupt, no need to set INTREQ for every beacon descriptor. And also clear ps filter for beacon frame. Signed-off-by:
Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by:
-
Rajkumar Manoharan authored
Whenever the reset work is queued up, do not generate beacon. And also clear the beacon miss count once the beacon stuck was observed. Signed-off-by:
-
Rajkumar Manoharan authored
After the chip reset, the noise immunity levels are restored with history values. If the immunity levels are lower than the defaults, lets start with the optimal values. Signed-off-by:
-
Rajkumar Manoharan authored
The background scan completion takes more time when the station is having heavy uplink traffic. The scan state machine decides to fall back to home channel on every off-channel visit when there are pending frames in tx queue. bgscan completion took ~30sec on dual band US regulatory card. scan period = (20 active channels * probe timeout) + (12 passive channels * passive probe timeout) + (32 * timeout on home channel) + (32 * flush timeout) Signed-off-by: -
Rajkumar Manoharan authored
Sync-up ibss beacon timer with the beacon frame's timestamp. When the node acts as joiner, it has to sync with the received beacon timestamp instead of reading tsf from hw. As the hw tsf wont wont be update till bssid is configured. This patch programs hw tsf with the received beacon timestamp if beacon timers are yet to be configured. Signed-off-by:
-
Rajkumar Manoharan authored
Update AR9462 initval to fix unbalance beacon distribution in Ad-Hoc network. Signed-off-by:
-
Matt Renzelmann authored
The driver is allocating memory during initialization with GFP_ATOMIC even though GFP_KERNEL is sufficient. This patch fixes it. Signed-off-by:
Matt Renzelmann <mjr@cs.wisc.edu> Signed-off-by:
-
Javier Cardona authored
When testing mesh synchronization we observed a global TSF slowdown that was dependent on the number of synchronized mesh stations. This seems to be caused by the TSF adjustment (read/write) latency. Adding a small margin to the Toffset setpoint solved the problem. Signed-off-by:
Shinichi Hotori <hotorinn@gmail.com> Signed-off-by:
Yu Niiro <yu.niiro@gmail.com> Signed-off-by:
Javier Cardona <javier@cozybit.com> Signed-off-by:
-
Javier Cardona authored
Signed-off-by:
-
Javier Cardona authored
Last patch I sent failed to take into account the offset of each phy. Signed-off-by:
-
Javier Cardona authored
Per sections 8.4.2.100.2 and 8.4.2.100.3 of Std 802.11-2012 Reported-by:
-
Felix Fietkau authored
Since it's only called when beacons are stuck, move it to the SWBA handler tasklet, to avoid doing redundant checks on every single interrupt. Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
-
Felix Fietkau authored
LED support is typically handled via system GPIO on these platforms. Signed-off-by:
-
Felix Fietkau authored
Also tweak beacon response times for better stability with the shorter timer intervals. Signed-off-by:
-
Jonathan Bither authored
Following Felix's recent patchset as an example I have replaced memcmp with compare_ether_addr. "Because of the constant size and guaranteed 16 bit alignment, the inline compare_ether_addr function is much cheaper than calling memcmp." Signed-off-by:
Jonathan Bither <jonbither@gmail.com> Signed-off-by:
-
Ben Greear authored
Report all defined sync_cause errors in debugfs to aid with debugging. Use a macro to print out the interrupts file contents to decrease code duplication. Signed-off-by:
Ben Greear <greearb@candelatech.com> Signed-off-by:
-
Ben Greear authored
This hides some repetitive code, and will help if the column widths ever need to change. Signed-off-by:
-
Luciano Coelho authored
Commit 3a25a8c8 (mac80211: add improved HW queue control) introduced a bug when running in AP mode without the IEEE80211_HW_QUEUE_CONTROL flag set. The ieee80211_check_queues() function always returns -EINVAL, preventing AP mode from starting. To fix this, check whether this flag is set before checking if cab_queue is set properly. Signed-off-by:
Luciano Coelho <coelho@ti.com> Signed-off-by:
-
Johannes Berg authored
My grand plan to allow drivers to gradually move over to advertising virtual interface combinations and only enforce with drivers that do want it enforced doesn't seem to be working out, only Christian ever added the advertising (to carl9170), nobody else did. Begin enforcing combinations in cfg80211 so that users can rely on the information reported about a device. Cc: "Luis R. Rodriguez" <mcgrof@qca.qualcomm.com> Cc: Jouni Malinen <jouni@qca.qualcomm.com> Cc: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com> Cc: Senthil Balasubramanian <senthilb@qca.qualcomm.com> Cc: Kalle Valo <kvalo@qca.qualcomm.com> Cc: Jiri Slaby <jirislaby@gmail.com> Cc: Nick Kossifidis <mickflemm@gmail.com> Cc: Bob Copeland <me@bobcopeland.com> Cc: Bing Zhao <bzhao@marvell.com> Cc: Lennert Buytenhek <buytenh@wantstofly.org> Cc: Ivo van Doorn <IvDoorn@gmail.com> Cc: Gertjan van Wingerde <gwingerde@gmail.com> Cc: Helmut Schaa <helmut.schaa@googlemail.com> Cc: Luciano Coelho <coelho@ti.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
-
- Apr 14, 2012
-
-
Arend van Spriel authored
The driver provides a regulatory hint to cfg80211 as obtained from the SPROM. Mostly, this will be a two-letter ISO country code. However, it may obtain special country code similar to the world regulatory domain as used in cfg80211. This patch avoids setting these special codes as the hint is lost to cfg80211. Reviewed-by:
Pieter-Paul Giesberts <pieterpg@broadcom.com> Reviewed-by:
Brett Rudley <brudley@broadcom.com> Signed-off-by:
Arend van Spriel <arend@broadcom.com> Signed-off-by:
-
Arend van Spriel authored
The brcmsmac driver provides the country code from sprom as a regulatory hint to cfg80211. When brcmsmac does not find a country code entry in the sprom it passes 'US' as regulatory hint. Better approach is to rely on the world regulatory domain in cfg80211/crda. Reviewed-by:
-
Franky Lin authored
Remove unsupported chip ID and rearrange the list in alphabetical order Reviewed-by:
Franky Lin <frankyl@broadcom.com> Signed-off-by:
-
Franky Lin authored
BRCMF_C_UP is the command that asks the firmware to enable RF of dongle. Some firmware initialization steps must be performed during RF is down. Postpone BRCMF_C_UP firing until brcmf_netdev_open get called to ensure firmware have enough time to finish initialization. Reviewed-by:
-
Franky Lin authored
A header extension is introduced in the received frame to provide extra space for dongle information. This won't affect current supported chipset since the data_offset is 0. But it's necessary for adding support for future chipset. Reviewed-by:
-
Arend van Spriel authored
The primary net device was registered with a primary mac address and upon IFUP it was set to match the actual mac address from the device. This patch changes that and moves the brcmf_add_if() call to the common part of the driver. Reviewed-by:
-
Arend van Spriel authored
The mac address for the primary interface was handled different from the other interfaces. The code has been restructured such that the brcmf_net_attach function treats the interfaces equal. Reviewed-by:
-
Arend van Spriel authored
The function brcmf_net_attach() is only used within dhd_linux.c so it does not need to be extern. This patch makes the function static. Reviewed-by:
-
Mohammed Shafi Shajakhan authored
its not used where, while we directly obtain ieee80211_bss's pointer in ibss.c by calling cfg80211_get_bss Signed-off-by:
Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com> Signed-off-by:
-
Sujith Manoharan authored
Reported-by:
Ryan Roper <ryan.roper@gmail.com> Signed-off-by:
Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by:
-
Michal Kazior authored
Removes hw.conf.channel usage from the following functions: * ieee80211_mandatory_rates * ieee80211_sta_get_rates * ieee80211_frame_duration * ieee80211_rts_duration * ieee80211_ctstoself_duration This is in preparation for multi-channel operation. Signed-off-by:
Michal Kazior <michal.kazior@tieto.com> Signed-off-by:
-
Sujith Manoharan authored
The MAX_TXPWR table for BTCOEX is not needed for AR9462. Programming these values to the HW results in undesirable behavior - for example, large number of delimiter/data underruns are seen in AES-CCMP mode. Also, registers like AR_PCU_MISC_MODE2 return 0xdeadbeef after the BTCOEX_MAX power table is programmed to the HW, and frames being transmitted end up being looped back to the RX engine, an example being beacon frames in IBSS mode. Remove this table for now - this fixes CCMP performance and general IBSS usage. Signed-off-by:
-
Lorenzo Bianconi authored
I noticed a possible issue in the status count field management of the ieee80211_tx_info data structure. In particular, when the AGGR processing is employed, status.rates[].count is set just for the first frame and not for others belonging to the same burst, leading to wrong statistic data in the mac80211 debug file system. Signed-off-by:
Lorenzo Bianconi <lorenzo.bianconi83@gmail.com> Signed-off-by:
-
