- 15 Mar, 2012 8 commits
-
-
Stanislaw Gruszka authored
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Acked-by: Gertjan van Wingerde <gwingerde@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Sujith Manoharan authored
mac80211 provides short preamble information and ERP protection information on a per-BSS basis, which can be used. Remove flags stored in the driver, which was incorrect since they were being used in a global manner. Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Sujith Manoharan authored
SC_OP_TXAGGR and SC_OP_RXAGGR are not really needed. The HT capabilities of the station and HW can be used instead. Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Sujith Manoharan authored
The logic to determine whether to use FCC is a bit convoluted. Use a small helper function to decide whether FCC is to be used. Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Sujith Manoharan authored
It is not needed and will not be used anyway since unsupported interfaces are not allowed to be created. 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
There is no need to mask out SWBA/BMISS from the interrupt mask in start(). Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Helmut Schaa authored
rt2800 already reports the tx ack status of each frame back to mac80211. Advertise this by setting IEEE80211_HW_REPORTS_TX_ACK_STATUS for rt2800. This allows some mac80211 features like frame loss notifications to work with rt2800. Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
- 14 Mar, 2012 10 commits
-
-
Amitkumar Karwar authored
"hscfg" is declared as struct mwifiex_ds_hs_cfg. Use same structure name for calculating it's size. 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>
-
Yogesh Ashok Powar authored
For files sta_rx.c, sta_tx.c, txrx.c, util.c and wmm.c Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Yogesh Ashok Powar authored
For files sta_event.c and sta_ioctl.c Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Yogesh Ashok Powar authored
For sta_cmd.c and sta_cmdresp.c Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Yogesh Ashok Powar authored
For file sdio.c Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Yogesh Ashok Powar authored
For file scan.c Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Yogesh Ashok Powar authored
For files main.c, main.h and pcie.c Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Yogesh Ashok Powar authored
For files fw.h, init.c and join.c Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Yogesh Ashok Powar authored
For files cfg80211.c, cfp.c, and cmdevt.c Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Yogesh Ashok Powar authored
For files 11n.c, 11n.h, 11n_aggr.c, 11n_rxreorder.c Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
- 13 Mar, 2012 21 commits
-
-
Paul Stewart authored
When regulatory information changes our HT behavior (e.g, when we get a country code from the AP we have just associated with), we should use this information to change the power with which we transmit, and what channels we transmit. Sometimes the channel parameters we derive from regulatory information contradicts the parameters we used in association. For example, we could have associated specifying HT40, but the regulatory rules we apply may forbid HT40 operation. In the situation above, we should reconfigure ourselves to transmit in HT20 only, however it makes no sense for us to disable receive in HT40, since if we associated with these parameters, the AP has every reason to expect we can and will receive packets this way. The code in mac80211 does not have the capability of sending the appropriate action frames to signal a change in HT behaviour so the AP has no clue we can no longer receive frames encoded this way. In some broken AP implementations, this can leave us effectively deaf if the AP never retries in lower HT rates. This change breaks up the channel_type parameter in the ieee80211_enable_ht function into a separate receive and transmit part. It honors the channel flags set by regulatory in order to configure the rate control algorithm, but uses the capability flags to configure the channel on the radio, since these were used in association to set the AP's transmit rate. Signed-off-by: Paul Stewart <pstew@chromium.org> Cc: Sam Leffler <sleffler@chromium.org> Cc: Johannes Berg <johannes@sipsolutions.net> Reviewed-by: Luis R Rodriguez <mcgrof@frijolero.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
This value is not really very useful by itself, yet some drivers (including iwlwifi until I can figure out what it should do) use it. At least rename it to "last_tsf" to indicate the meaning and add a note that it may be really old. I suspect the value may become useful combined with the rx_status->mactime, but we don't (yet) store that value and pass it to the driver. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
This is intended to be the timestamp sent by the peer in the beacon/probe response, not any form of host timestamp. Clarify the documentation and variable names. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
The cfg80211_inform_bss() timestamp argument is intended to be the TSF, not any form of host timestamp. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Yegor Yefremov authored
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Yogesh Ashok Powar authored
Renaming the long fuctions and variable names from 11n_rxreoder.c file to shorter ones for better readability. Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Yogesh Ashok Powar authored
This adds better readability. Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Yogesh Ashok Powar authored
For the delay of 10 uSec or more usleep_range is prefered. Unlike udelay, sleep_range avoids large number of undesired interrupts. Ref Documentation/timers/timers-howto.txt Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Yogesh Ashok Powar authored
There exist different functions with very long names to derive the channel frequency and power tripplet based on band and channel/freq. Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Yogesh Ashok Powar authored
Fixing coding style by rearranging the switch statement Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Yogesh Ashok Powar authored
This saves some space and adds better readability. Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
Not linearizing every SKB will help actually pass non-linear SKBs all the way up when on an encrypted connection. For now, linearize TKIP completely as it is lower performance and I don't quite grok all the details. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
This is better done inside the WEP decrypt function where it doesn't have to check all the conditions any more since they've been tested already. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Larry Finger authored
Recent changes in udev are causing problems for drivers that load firmware from the probe routine. As b43 has such a structure, it must be changed. As this driver loads more than 1 firmware file, changing to the asynchronous routine request_firmware_nowait() would be complicated. In this implementation, the probe routine starts a queue that calls the firmware loading routines. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Larry Finger authored
Recent changes in udev are causing problems for drivers that load firmware from the probe routine. As b43legacy has such a structure, it must be changed. As this driver loads 3 or 4 firmware files, changing to the asynchronous routine request_firmware_nowait() would be complicated. In this implementation, the probe routine starts a work queue that calls the firmware loading routines. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
-
Kalle Valo authored
Commit 7504a3e1 ("ath6kl: add padding to firmware log records") accidentally changed debug.c mode from 100644 to 100755. Revert that back to original. Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
-
Kalle Valo authored
ath6kl/cfg80211.c:589: WARNING: max() should probably be max_t(u16, vif->listen_intvl_t, ATH6KL_MAX_WOW_LISTEN_INTL) Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
-
Kalle Valo authored
ath6kl/sdio.c:875: CHECK: Alignment should match open parenthesis Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
-
Kalle Valo authored
Recommended by checkpatch. Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
-
Kalle Valo authored
My patch 24fc32b3 ("ath6kl: add ath6kl_bmi_write_hi32()") caused a regression in ath6kl_upload_board_file() and the board_address variable was not properly initialised in some cases: ath6kl/init.c:1068:6: warning: ‘board_address’ may be used uninitialized in this function Most likely this broke ar6004 support but I can't test that right now. Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
-
- 12 Mar, 2012 1 commit
-
-
Johannes Berg authored
The authentication and association handshake already happens in the context of the new BSS, and the basic rates are needed at least for the ACK response frame to the authentication or association response frames. Therefore the basic rates should already be configured into the driver when those frames are sent. Change the logic to set up the basic rates in the connection preparation that happens for authentication and association (if needed). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-