aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2014-05-06iwlwifi: pcie: get rid of q->n_bdJohannes Berg
This variable always tracks a constant value (256) so there's no need to have it. Removing it simplifies code generation, reducing the .text size (by about 240 bytes on x86-64.) Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
2014-05-06iwlwifi: pcie: use bool for iwl_pcie_txq_build_tfd() argumentJohannes Berg
The 'reset' argument is clearly a boolean, so use bool instead of u8 with 0/1 values. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
2014-05-06iwlwifi: make LED support optionalJohannes Berg
If there's no LED on the system, it doesn't make a lot of sense to include close to 4k of LED-related code (mostly in mac80211), so instead of forcing LED support into the kernel, don't build iwlwifi/mac80211 LED support if there's no LED class support. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reviewed-by: EliadX Peller <eliad@wizery.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
2014-05-06iwlwifi: mvm: fix bug in parse_nvm_sectionsEran Harary
The old code checks if hw_section_num is valid while the right thing to do is to check if section[hw_section_num].data is valid. Signed-off-by: Eran Harary <eran.harary@intel.com> Reviewed-by: Liad Kaufman <liad.kaufman@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
2014-05-06iwlwifi: mvm: select the MAC address according to priorityEran Harary
For family 8000 products, the driver should take the MAC address from the mac_override section and only if this section is empty it should take it from the HW section. Signed-off-by: Eran Harary <eran.harary@intel.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
2014-05-06iwlwifi: mvm: Prioritize external nvm values on top of the OTP valuesEran Harary
Read first the nvm sections from the OTP, then read the nvm sections from the external file and override the OTP values (if there were any values in the OTP). Signed-off-by: Eran Harary <eran.harary@intel.com> Reviewed-by: Dor Shaish <dor.shaish@intel.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
2014-05-06iwlwifi: mvm: prevent nic to powered up at driver loadEran Harary
A few devices aren't allowed to be powered up at driver load time. Add "power_up_nic_in_init" flag to iwl_cfg structure to customize the load flow according to the device. Signed-off-by: Eran Harary <eran.harary@intel.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
2014-05-06iwlwifi: mvm: fix bug with OTP memory sizeEran Harary
OTP size changed in family 7000 and in family 8000. Signed-off-by: Eran Harary <eran.harary@intel.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
2014-05-06iwlwifi: mvm: remove useless variableJohannes Berg
There's no need to use a variable just to return the result of another function call at the end of a function, remove it. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
2014-05-06iwlwifi: mvm: rs: choose correct expected tpt tableEyal Shapira
The expected throughput table used when estimating a new column depends on the channel bandwidth. When switching from legacy to siso or mimo the wrong expected throughput table was used as it was chosen based on the the channel bandwidth in legacy which is always 20Mhz. Instead it should be chosen based on the current sta bandwidth which could be also 40Mhz or 80Mhz. When enabling MCS9 this bug leads to a problem where the max expected throughput of the siso or mimo column is 0 as MCS9 isn't supported in 20Mhz. This in turns prevents switching to siso or mimo. Fix this by using the sta bandwidth when deciding which table to choose. Signed-off-by: Eyal Shapira <eyalx.shapira@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
2014-05-06iwlwifi: mvm: rs: avoid TPC while in search cycleEyal Shapira
TPC is a power optimization which should only be attempted when we're in the "stay in column" state after we've locked onto an optimal rate. Signed-off-by: Eyal Shapira <eyalx.shapira@intel.com> Reviewed-by: Eliad Peller <eliad@wizery.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
2014-05-06iwlwifi: mvm: rs: don't allow TPC when power save is disabledEyal Shapira
Currently we were checking only if the driver power_scheme is set to CAM. TPC shouldn't be enabled also when disabling powersave on the interface (e.g. iw wlan0 set power_save off) which may occur even if power_scheme wasn't set to CAM. Signed-off-by: Eyal Shapira <eyalx.shapira@intel.com> Reviewed-by: Eliad Peller <eliad@wizery.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
2014-05-06iwlwifi: mvm: rs: overhaul rs_get_best_rateEyal Shapira
rs_get_best_rate determines the optimal rate to try in a new Tx column. Currently we were sometimes trying a too high rate which would lead us to fail and avoid switching to the new column despite it having a potential to be better. Change the logic to try and find the first rate which would exceed the current actual throughput or be more aggressive if the success ratio is good. Signed-off-by: Eyal Shapira <eyalx.shapira@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
2014-05-06iwlwifi: mvm: rs: revert changes to search cycle rulesEyal Shapira
Adding more options in the search cycle causes longer search cycles with additional wondering off to non optimal Tx configurations. Reduce the Tx configurations searched to improve throughput in non optimal attenuations. Signed-off-by: Eyal Shapira <eyalx.shapira@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
2014-05-06Merge remote-tracking branch 'wireless-next/master' into iwlwifi-nextEmmanuel Grumbach
2014-05-06Merge remote-tracking branch 'iwlwifi-fixes/master' into iwlwifi-nextEmmanuel Grumbach
2014-05-06iwlwifi: mvm: rs - s/CPTCFG/CONFIGEmmanuel Grumbach
My bad - I forgot to update this when sending the patch upstream. Fixes: 87d5e4155c00 ("iwlwifi: mvm: rs: reinit rs if no tx for a long time") Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
2014-05-06iwlwifi: mvm: BT Coex - fix validity flags during initEmmanuel Grumbach
The commit below introduced a bug in the validity bits in init. Due to that, all the Coex mechanism stopped sending kills to the BT side. Fix that. Fixes: b9fae2d54c9f ("iwlwifi: mvm: BT Coex add support for Co-running block") Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
2014-04-30rsi: Changing opcode for sta mode according to changes in firmwareJahnavi Meher
Signed-off-by: Jahnavi Meher <jahnavi.meher@redpinesignals.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-04-30ath9k_hw: fix worse EVM for 11b ratesRajkumar Manoharan
Adjust FIR filter co-efficients to improve EVM for 11b rates. Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-04-30ath9k_hw: update ar9300 initvalsRajkumar Manoharan
* rfsat gainchange hysteresis of rf_gain stuck with large interference present. Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-04-30b43: N-PHY: complete radio 0x2056 setupRafał Miłecki
Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-04-30ath5k: Fix AR5K_PHY_TXPOWER_RATE_MAX register value setting.Nickolay Ledovskikh
I was reading ath5k power setting code and noticed typing error in ath5k_hw_txpower function. Invalid value was written to AR5K_PHY_TXPOWER_RATE_MAX register. Signed-off-by: Nikolay Ledovskikh <nledovskikh@gmail.com> Acked-by: Nick Kossifidis <mickflemm@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-04-30iwlegacy: Convert /n to \nJoe Perches
Use a newline character appropriately. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-04-30wlcore: fix usage of platform_device_add_data()Christian Engelmayer
Coverity CID 986698 reports leakage of struct wlcore_platdev_data in the probe functions of both the SPI/SDIO interfaces. The structure passed to platform_device_add_data() is dynamically allocated and only freed in the error paths, however, platform_device_add_data() adds a copy of the platform specific data to the device. Move the temporary struct that is kmemdup'ed to the stack. This issue exists since afb43e6d (wlcore: remove if_ops from platform_data). Signed-off-by: Christian Engelmayer <cengelma@gmx.at> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-04-30rtlwifi: rtl8723be: disable MSI interrupts modeAdam Lee
94010fa0dd07e8b904e7c6b6589f15573008ab15 ("rtlwifi: add MSI interrupts mode support") introduced MSI interrupts mode support, which seemed safe enough with RTL8188EE and RTL8723BE as RealTek's testing results, but some users reported their RTL8188EE modules could not connect to any wireless network after the MSI mode was enabled by Ubuntu 14.04. So, let's fallback to pin-based mode until rtlwifi's MSI support get good compatibility. BugLink: https://bugs.launchpad.net/bugs/1310512 Signed-off-by: Adam Lee <adam.lee@canonical.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-04-30Revert "rtlwifi: rtl8188ee: enable MSI interrupts mode"Adam Lee
This reverts commit 2a54eb5e1476426ee639bbfbe179b52342a0d82c ("rtlwifi: rtl8188ee: enable MSI interrupts mode"). 94010fa0dd07e8b904e7c6b6589f15573008ab15 ("rtlwifi: add MSI interrupts mode support") introduced MSI interrupts mode support, which seemed safe enough with RTL8188EE and RTL8723BE as RealTek's testing results, but some users reported their RTL8188EE modules could not connect to any wireless network after the MSI mode was enabled by Ubuntu 14.04. So, let's fallback to pin-based mode until rtlwifi's MSI support get good compatibility. BugLink: https://bugs.launchpad.net/bugs/1310512 Signed-off-by: Adam Lee <adam.lee@canonical.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-04-30b43: don't pre-set radio_on variable to trueRafał Miłecki
Setting it to true during init doesn't seem to be any workaround while it can cause problems (not enabling radio due to belief it's enabled). Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-04-30b43: use b43_software_rfkill helperRafał Miłecki
This removes dealing with pointers directly and allows tracking radio state with radio_on variable. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-04-30b43: bcma: respect GMODE (band choice) during core resetRafał Miłecki
Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-04-30Merge branch 'for-john' of ↵John W. Linville
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next Conflicts: net/mac80211/chan.c
2014-04-30Merge branch 'for-upstream' of ↵John W. Linville
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next
2014-04-28mac80211_hwsim: Advertise support for AP mode channel width changesJouni Malinen
mac80211 takes care of all the needed steps for hwsim, so indicate support for this capability. Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-04-28mac80211: Support dynamic AP mode channel width changesJouni Malinen
Implement the new cfg80211 capability to enable mac80211-based drivers to support for dynamic channel bandwidth changes (e.g., HT 20/40 MHz changes). Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-04-28cfg80211: Dynamic channel bandwidth changes in AP modeJouni Malinen
This extends NL80211_CMD_SET_CHANNEL to allow dynamic channel bandwidth changes in AP mode (including P2P GO) during a lifetime of the BSS. This can be used to implement, e.g., HT 20/40 MHz co-existence rules on the 2.4 GHz band. Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-04-28mac80211: remove unnecessary assignmentZhao, Gang
P2P_DEVICE doesn't support ieee80211_bss_info_change_notify() for now, so it's not needed to set changed flags for P2P_DEVICE. Signed-off-by: Zhao, Gang <gamerh2o@gmail.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-04-28mac80211: avoid calling useless channel context codeZhao, Gang
ieee80211_assign_chanctx() checks if local->use_chanctx is true, so the two code block related to ieee80211_assign_chanctx() can be moved into above if clause, emphasize that these code are executed only if local->use_chanctx is true. Signed-off-by: Zhao, Gang <gamerh2o@gmail.com> [change subject] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-04-25cfg80211: Use 5MHz bandwidth by default when checking usable channelsRostislav Lisovy
Current code checks if the 20MHz bandwidth is allowed for particular channel -- if it is not, the channel is disabled. Since we need to use 5/10 MHz channels, this code is modified in the way that the default bandwidth to check is 5MHz. If the maximum bandwidth allowed by the channel is smaller than 5MHz, the channel is disabled. Otherwise the channel is used and the flags are set according to the bandwidth allowed by the channel. Signed-off-by: Rostislav Lisovy <rostislav.lisovy@fel.cvut.cz> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-04-25cfg80211: Add attributes describing prohibited channel bandwidthRostislav Lisovy
Since there are frequency bands (e.g. 5.9GHz) allowing channels with only 10 or 5 MHz bandwidth, this patch adds attributes that allow keeping track about this information. When channel attributes are reported to user-space, make sure to not break old tools, i.e. if the 'split wiphy dump' is enabled, report the extra attributes (if present) describing the bandwidth restrictions. If the 'split wiphy dump' is not enabled, completely omit those channels that have flags set to either IEEE80211_CHAN_NO_10MHZ or IEEE80211_CHAN_NO_20MHZ. Add the check for new bandwidth restriction flags in cfg80211_chandef_usable() to comply with the restrictions. Signed-off-by: Rostislav Lisovy <rostislav.lisovy@fel.cvut.cz> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-04-25mac80211: change return value of notifier functionZhao, Gang
Return NOTIFY_DONE if we don't care this time's notification, return NOTIFY_OK if we successfully handled this time's notification. That's the formal way to do it. Signed-off-by: Zhao, Gang <gamerh2o@gmail.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-04-25cfg80211: change return value of notifier functionZhao, Gang
Return NOTIFY_DONE if we don't care this time's notification, return NOTIFY_OK if we successfully handled this time's notification. That's the formal way to do it. Signed-off-by: Zhao, Gang <gamerh2o@gmail.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-04-25cfg80211: change wiphy_to_dev function nameZhao, Gang
Name wiphy_to_rdev is more accurate to describe what the function does, i.e., return a pointer pointing to struct cfg80211_registered_device. Signed-off-by: Zhao, Gang <gamerh2o@gmail.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-04-25cfg80211: change registered device pointer nameZhao, Gang
Name "dev" is too common and ambiguous, let all the pointer name pointing to struct cfg80211_registered_device be "rdev". This can improve code readability and consistency(since other places have already called it rdev). Signed-off-by: Zhao, Gang <gamerh2o@gmail.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-04-25mac80211: remove unnecessary BUG_ON()Zhao, Gang
The BUG_ON(!err) can't be triggered in the code path, so remove it. Signed-off-by: Zhao, Gang <gamerh2o@gmail.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-04-25mac80211: return bool instead of numbers in yes/no functionZhao, Gang
And some code style changes in the function, and correct a typo in comment. Signed-off-by: Zhao, Gang <gamerh2o@gmail.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-04-25mac80211: add option to generate CCMP IVs only for mgmt framesMarek Kwaczynski
Some chips can encrypt managment frames in HW, but require generated IV in the frame. Add a key flag that allows us to achieve this. Signed-off-by: Marek Kwaczynski <marek.kwaczynski@tieto.com> [use BIT(0) to fill that spot, fix indentation] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-04-25mac80211: compute chanctx refcount on-the-flyMichal Kazior
It doesn't make much sense to store refcount in the chanctx structure. One still needs to hold chanctx_mtx to get the value safely. Besides, refcount isn't on performance critical paths. This will make implementing chanctx reservation refcounting a little easier. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-04-25mac80211: fix racy usage of chanctx->refcountMichal Kazior
Channel context refcount is protected by chanctx_mtx. Accessing the value without holding the mutex is racy. RCU section didn't guarantee anything here. Theoretically ieee80211_channel_switch() could fail to see refcount change and read "1" instead of, e.g. "2". This means mac80211 could accept CSA even though it shouldn't have. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-04-25mac80211: split ieee80211_free_chanctx()Michal Kazior
The function did a little too much. Split it up so the code can be easily reused in the future. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-04-25mac80211: split ieee80211_new_chanctx()Michal Kazior
The function did a little too much. Split it up so the code can be easily reused in the future. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>