- 09 Dec, 2013 22 commits
-
-
Sujith Manoharan authored
* Update radio/baseband/gain tables. * Mark ar9331_modes_high_power_tx_gain_1p1 as a duplicate * ar9331_1p1_mac_postamble is not a duplicate. Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Sujith Manoharan authored
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Sujith Manoharan authored
Enable the ALWAYS_KEYSEARCH bit in the initvals. Currently this is done in the driver, but adding this to the initvals makes it easier to be in sync with the INI files given by the systems engineering team. Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Sujith Manoharan authored
Certain baseband registers require different values to be programmed when operating in a DFS channel to ensure that radar detection works correctly. This is required for AR9300, AR9340 and AR9580. Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Sujith Manoharan authored
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Larry Finger authored
Sparse reports the following: CHECK drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c:570:34: warning: dubious: !x & y There should be a parens around the expression. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Chun-Yeow Yeoh authored
Enable the beaconing in wnc36xx by tweaking the tim offset and force the use of AP-style beaconing. Otherwise, beaconing is not working. The tim offset is set to 256. Otherwise, this will overwrite mesh beacon submitted by mac80211. Signed-off-by: Chun-Yeow Yeoh <yeohchunyeow@cozybit.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Chun-Yeow Yeoh authored
Signed-off-by: Chun-Yeow Yeoh <yeohchunyeow@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Ujjal Roy authored
When TX data URB reaches high water mark the message "data: -ENOSR is returned" is printed. This is not an error case, so change it to debug print. Signed-off-by: Ujjal Roy <royujjal@gmail.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Amitkumar Karwar authored
The check for 'priv' pointer is redundant. 'priv' won't be used later in this routine. 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>
-
Ujjal Roy authored
The bridged packets are updated to statistics on both TX and RX paths. Also fix a typo in the comment. Signed-off-by: Ujjal Roy <royujjal@gmail.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Ujjal Roy authored
The skb is modified in sending the TX packet. Save the original packet length to a variable so that we can get the correct statistics update. Signed-off-by: Ujjal Roy <royujjal@gmail.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Ujjal Roy authored
The skb is modified in processing the RX packet. Save the original packet length to a variable so that we can get the correct statistics update. Signed-off-by: Ujjal Roy <royujjal@gmail.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Ujjal Roy authored
RX packets are handled in different paths. Not all paths have decrement of rx_pending counter. This patch fixes the counter imbalance. Signed-off-by: Ujjal Roy <royujjal@gmail.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Bing Zhao authored
eth_hdr is defined in kernel. Use a different variable name in our functions. Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Amitkumar Karwar authored
SNAP/LLC header in the AARP packet is being stripped off while preparing an EthernetII header. Annex M, Table M.3 in 802.11 spec says that some header (ex. AppleTalk AARP(2)) should pass through untouched. This patch modifies the check to exclude/include EthernetII header translation for special cases. 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
Use 'rfc1042_header' available in net/wireless/util.c 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
Actually we are updating snap_type with h_proto (__be16 variable) in ethernet frame header. Hence endianness conversion is not required. 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>
-
Ujjal Roy authored
The firmware expects the command structure members in little endianness. Signed-off-by: Ujjal Roy <royujjal@gmail.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Jingoo Han authored
Don't use DEFINE_PCI_DEVICE_TABLE macro, because this macro is not preferred. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
John W. Linville authored
Merge branch 'for-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next
-
git://github.com/kvalo/athJohn W. Linville authored
Conflicts: drivers/net/wireless/ath/ath10k/htc.c drivers/net/wireless/ath/ath10k/mac.c
-
- 06 Dec, 2013 1 commit
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wirelessJohn W. Linville authored
Conflicts: drivers/net/wireless/brcm80211/Kconfig net/mac80211/util.c
-
- 05 Dec, 2013 17 commits
-
-
Luis R. Rodriguez authored
As it stands dynamic user regulatory domain support is only possible for a few programmed regulatory domains as a few countries do not allow for this. The existing code however only would take advantage of the feature if a custom world regulatory domain is used though as that's when we clear beconing flags. We need to lift this restriction as otherwise this feature is pointless. Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
This will be used later. Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
This will be used later. Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
freq_reg_info() expects KHz and not MHz, fix this. In this case we'll now be getting the no-ir flags cleared on channels for any channel when the country IE trusts that channel. @@ struct ieee80211_channel *ch; struct wiphy *wiphy; const struct ieee80211_reg_rule *rule; @@ -rule = freq_reg_info(wiphy, ch->center_freq); +rule = freq_reg_info(wiphy, MHZ_TO_KHZ(ch->center_freq)); Generated-by: Coccinelle SmPL Cc: Julia Lawall <julia.lawall@lip6.fr> Cc: Peter Senna Tschudin <peter.senna@gmail.com> Reported-by: Mihir Shete <smihir@qti.qualcomm.com> Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
While at it convert this into a switch statement, this makes it easier and manage. Cc: smihir@qti.qualcomm.com Cc: tushnimb@qca.qualcomm.com Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
Simplify ath_reg_apply_beaconing_flags() by making use of thew new no-ir helper. Cc: smihir@qti.qualcomm.com Cc: tushnimb@qca.qualcomm.com Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
This also applies the no-ibss flag to the channels or clears it. The idea here is to clarify no initiated radiation should be allowed on these channels. Cc: smihir@qti.qualcomm.com Cc: tushnimb@qca.qualcomm.com Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
The routine ath_reg_apply_active_scan_flags() can be a bit hard to read, this cleans it up by adding helpers for the two cases of clearing IR flags or adding them. This approach also makes no assumptions on the index of channels 12 and 13 so it should be portable accross different drivers. Cc: smihir@qti.qualcomm.com Cc: tushnimb@qca.qualcomm.com Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
The existing logic removes the passive scan flag from channels 12 and 13 when a regulatory hint coming from something other than a country IE has been passed. This is incorrect, the original intention was to ensure we always have passive scan enabled for these two channels for a specific set of custom world regulatory domains. Cc: smihir@qti.qualcomm.com Cc: tushnimb@qca.qualcomm.com Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Chun-Yeow Yeoh authored
Signed-off-by: Chun-Yeow Yeoh <yeohchunyeow@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Larry Finger authored
The static analyser "cppcheck" shows the following typo: drivers/net/wireless/rtlwifi/rtl8188ee/dm.c:1081]: (style) Same expression on both sides of '!='. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Reported-by: David Binderman <dcb314@hotmail.com> Cc: David Binderman <dcb314@hotmail.com> Cc: Stable <stable@vger.kernel.org> [3.10+] Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Jingoo Han authored
The driver core clears the driver data to NULL after device_release or on probe failure. Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Jingoo Han authored
The driver core clears the driver data to NULL after device_release or on probe failure. Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Jingoo Han authored
The driver core clears the driver data to NULL after device_release or on probe failure. Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Acked-by: Gertjan van Wingerde <gwingerde@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Jingoo Han authored
The driver core clears the driver data to NULL after device_release or on probe failure. Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Jingoo Han authored
The driver core clears the driver data to NULL after device_release or on probe failure. Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Hauke Mehrtens authored
There is no code in brcmsmac that uses a function from CRC8 or CRC_CCITT any more. Building brcmsmac with these two disabled works without any problems. This was probably only used by the bus code which was replaced by bcma some time ago. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Acked-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-