- 13 Apr, 2014 31 commits
-
-
Emmanuel Grumbach authored
All the supported firmwares have this flag set. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
-
Emmanuel Grumbach authored
All the supported firmwares have this flag set. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
-
Emmanuel Grumbach authored
All the supported firmwares have this flag set. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
-
Emmanuel Grumbach authored
All the supported firmwares have this flag set. Reviewed-by: Luciano Coelho <luciano.coelho@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
-
Emmanuel Grumbach authored
All the supported firmwares have this flag set. Reviewed-by: Alexander Bondar <alexander.bondar@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
-
Emmanuel Grumbach authored
All the supported firmwares have this flag set. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
-
Emmanuel Grumbach authored
All the supported firmwares have this flag set. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
-
Emmanuel Grumbach authored
All the supported firmwares have this flag set. Reviewed-by: Alexander Bondar <alexander.bondar@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
-
Emmanuel Grumbach authored
All the supported firmwares have this flag set. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
-
Emmanuel Grumbach authored
This firmware is not supported any more. A few code paths specific to old firmware can be removed. We can now assume that a few TLV flags are always set since we won't load firmware that didn't support the corresponding features. This will be done in a separate patch. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
-
Emmanuel Grumbach authored
While the scan_cmd should really be allocated in init (and we do fail init in case the allocation failed), it doesn't mean we should lock up the machine if something really bad happened. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
-
Eyal Shapira authored
Collect accumulated stats of tx attempts and successes per rate and column for debugging purposes. These stats can be read via debugfs file drv_tx_stats and can also be reset by writing to this file. Signed-off-by: Eyal Shapira <eyalx.shapira@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
-
Monam Agarwal authored
rcu_assign_pointer() ensures that the initialization of a structure is carried out before storing a pointer to that structure. However, in the case that NULL is assigned there's no structure to initialize so using RCU_INIT_POINTER instead is safe and more efficient. Signed-off-by: Monam Agarwal <monamagarwal123@gmail.com> [rewrite commit log] Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
-
Emmanuel Grumbach authored
The firmware doesn't support broadcast filtering on P2P client. Trying to enable it makes the firmware assert. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
-
Eytan Lifshitz authored
When NIC is exiting from thermal throttling state (i.e. after heating and then cooling down), tx-backoff values are assigned to be zero, instead of being restored to the minimal value. Fixed. Signed-off-by: Eytan Lifshitz <eytan.lifshitz@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
-
Eytan Lifshitz authored
When NIC exit thermal throttling while having minimal tx-backoff restriction, the warning message that indicate about that state won't show up. Fixed. Signed-off-by: Eytan Lifshitz <eytan.lifshitz@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
-
Emmanuel Grumbach authored
The Rx FIFO includes valuable data - dump it when the FW asserts. Also - free the SRAM and Rx FIFO when we create the file, and don't collect new SRAM / Rx FIFO if the previous file hasn't been collected through debugfs yet. Also - add a comment to saying that the ASSERT output should not be modified since we have automatic scripts that monitor this output. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
-
Emmanuel Grumbach authored
This must not happen - otherwise we might keep flushing forever. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
-
Emmanuel Grumbach authored
This will be used later to flush / wait for queues that are related to a specific vif. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
-
Emmanuel Grumbach authored
Now that mac80211 calls pre_rcu_remove and we set the fw_id_to_mac_id pointer to -ENOENT before the station is removed, we don't need to set fw_id_to_mac_id to -EINVAL when the station is really removed. Leave fw_id_to_mac_id to be -ENOENT which will let the drain worker (iwl_mvm_sta_drained_wk) know that this station is not to be drained. We don't need to drain this station since it is our AP in managed mode and we flush all its frames synchronously anyway. Setting the AP station to -EINVAL could lead to confusion since internal stations are also reserved with -EINVAL, this confusion showed up in the logs as: Drained sta 0, but it is internal? Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
-
Emmanuel Grumbach authored
The firmware tells us if an Rx packet was beamformed or not. Propagate this data to mac80211's rx_status.vht_flags. The main user of this data is the radiotap header. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
-
Emmanuel Grumbach authored
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
-
Eran Harary authored
This define is related to the firmware packaging and is needed by more than one transport. Signed-off-by: Eran Harary <eran.harary@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
-
Emmanuel Grumbach authored
Besides the different allocation flags, they are really the same. Pass the gfp_t flags as a parameter, and unify them. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
-
Johannes Berg authored
Similar to the recent RX queue patch, this changes the need_update handling for the TX queues to be clearer and only done when needed. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
-
Johannes Berg authored
When updating the write pointer, the TX queue should be locked to get consistent state, fix that in the interrupt handler. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
-
Johannes Berg authored
Instead of using u8 to hold logic values, use bool. Also fix a comment, the return value is no longer relevant. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
-
Johannes Berg authored
When shadow registers are enabled, then need_update never needs to be set, so move the need_update handling into the function that really needs to do it (iwl_pcie_rxq_inc_wr_ptr) and also separate the check when it woke up. While at it, convert it to bool. This also clarifies the locking and means the irq_lock needs to no longer be held for any such updates. The irq_lock also doesn't have to be held for restocking since everything else locks the RX queue properly, so remove that and finally disentangle the two locks entirely so there aren't any dependencies between the two left. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
-
Johannes Berg authored
Use the new NAPI infrastructure added to mac80211 to get GRO. We don't really implement NAPI since we don't have a real poll function and we never schedule a NAPI poll. Instead of this, we collect all the packets we got from a single interrupt and then call napi_gro_flush(). This allows us to benefit from GRO. In half duplex medium like WiFi, its main advantage is that it reduces the number of TCP Acks, hence improving the TCP Rx performance. Since we call the Rx path with a spinlock held, remove the might_sleep mention from the op_mode's API. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reviewed-by: Ido Yariv <ido@wizery.com> [Squash different patches and rewrite the commit message] Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
-
Eliad Peller authored
Allow fixing the tx power reduction through debugfs file. The change doesn't take affect immediately, but will be considered the next time tpc is evaluated. Signed-off-by: Eliad Peller <eliadx.peller@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
-
Eliad Peller authored
Implement Adaptive Tx Power Control algorithm. ATPC basically tries to decrease the tx power as much as possible while the throughput is not being hurt. Signed-off-by: Eliad Peller <eliadx.peller@intel.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
-
- 09 Apr, 2014 1 commit
-
-
Eliad Peller authored
The fw recently added an option to set tx power reduction per station (in the lq_cmd command), and get the tx power reduction used (in the tx_resp struct). Use them and propogate this value up to mac80211's tx response (in order to use it later in the rate-scaling algorithm). Signed-off-by: Eliad Peller <eliadx.peller@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
-
- 06 Apr, 2014 3 commits
-
-
Emmanuel Grumbach authored
A hardware bug had been discovered on 7260 / 3160 and 7265 and the workaround for this bug is to force the NIC to stay awake as long as we have host commands in flight. This workaround has been introduced for all NICs in a previous patch: b9439491 ("iwlwifi: pcie: keep the NIC awake when commands are in flight") In newer NICs, this bug is solved, so we can let the NIC go to sleep even when we send commands. The hardware will wake up when we increment the scheduler write pointer. Make the workaround conditional to only use it on affected hardware. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
-
Eran Harary authored
Number of channels changed from 40 to 50 Signed-off-by: Eran Harary <eran.harary@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
-
Avri Altman authored
Today, the driver logic looks for the conditions to disable power management albeit power management should be enabled in a very few distinct cases. This patch changes the driver logic to enable power management once the required conditions met. While at it, make some housekeeping and support a few additional use cases: a) Add support for a standalone p2p client: Power management should be enabled for a P2P client MAC only if the firmware supports it (TLV flag is set). Instead we used the DCM flag, therefore we didn't cover use cases that did not include the DCM flag. b) Add support to Same-Channel-Mode (SCM): If both clients share the same channel (SCM), and there are no other active vifs in the system, power management should be enabled only if the firmware supports this (TLV flag is set). c) Fix power management logic for GO/AP: Today, when we detect an active GO / AP MAC - we disable power management for all the vifs altogether. Actually, the correct behavior is to enable power management on a client if on a different channel (based on the firmware capabilities). d) Housekeeping - Along with that, this patch includes some code-reorganizing: Today the logic of disabling power is scattered across several functions, specifically in the iterator. For the sake of both readability and scalability, we moved this logic to its applicable function, leaving the iterator gather information only. Furthermore, as power management is a MAC-related attribute, we moved the power management member to the iwl_mvm_vif structure. Signed-off-by: Avri Altman <avri.altman@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
-
- 31 Mar, 2014 5 commits
-
-
Alexey Khoroshilov authored
If allocation of io_dmabuf fails, rtl8187_probe() calls usb_put_dev(udev) while usb_get_dev(udev) is not called yet. As a result refcnt is decremented incorrectly and usb_dev can be used after memory deallocation. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru> Acked-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Andrea Merello authored
In rtl8180/rtl8185/rtl8187se the register space is represented using packed structure type. Register are thus accessed using a pointer of this type. All registers are packed toghether, and only small gaps are present. However Rtl8187se has also some "sparse" registers, very far from the "main register block". It could be possible to access them by simply declare huge reserved blocks inside the register struct (and this causes NO memory waste). However, for various reasons, access to those "far" registers is done with special dedicated macros, without declaring them in the register struct. This is done in an intricate manner, that makes code less readable and caused static analisys tool to produce warnings. This patch keeps the "macro" mechanism, but it changes its implementation in a simplier and more straightforward way. Signed-off-by: Andrea Merello <andrea.merello@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Dan Carpenter authored
There is a missing set of curly braces here so the debug output says "Probe confirm received" unintentionally. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Amitkumar Karwar authored
[ 6630.450908] BUG: spinlock bad magic on CPU#1, ksdioirqd/mmc1/355 [ 6630.450914] Unable to handle kernel NULL pointer dereference at virtual address 0000004f [ 6630.450919] pgd = ecbd8000 [ 6630.450926] [0000004f] *pgd=00000000 [ 6630.450936] lock: 0xeea4ab08, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0 [ 6630.450939] Backtrace: [ 6630.450956] [<c010d354>] (unwind_backtrace+0x0/0x118) from [<c060c238>] (dump_stack+0x28/0x30) [ 6630.450960] Internal error: Oops: 5 [#1] SMP ARM [ 6630.450964] Modules linked in: uvcvideo videobuf2_vmalloc [ 6630.450980] [<c060c238>] (dump_stack+0x28/0x30) from [<c0315ab4>] (spin_dump+0x80/0x94) [ 6630.450988] [<c0315ab4>] (spin_dump+0x80/0x94) from [<c0315af4>] (spin_bug+0x2c/0x30) [ 6630.450996] [<c0315af4>] (spin_bug+0x2c/0x30) from [<c0315b80>] (do_raw_spin_lock+0x28/0x15c) [ 6630.451004] [<c0315b80>] (do_raw_spin_lock+0x28/0x15c) from [<c0610c24>] (_raw_spin_lock_irqsave+0x20/0x28) [ 6630.451016] [<c0610c24>] (_raw_spin_lock_irqsave+0x20/0x28) from [<bf07a7f4>] (mwifiex_exec_next_cmd +0x6c/0x45c [mwifiex]) [ 6630.451030] [<bf07a7f4>] (mwifiex_exec_next_cmd+0x6c/0x45c [mwifiex]) from [<bf07834c>] (mwifiex_main_process+0x2c8/0x464 [mwifiex]) [ 6630.451047] [<bf07834c>] (mwifiex_main_process+0x2c8/0x464 [mwifiex]) from [<bf0a093c>] (mwifiex_sdio_interrupt+0xc8/0x1cc [mwifiex_sdio] [ 6630.451064] [<bf0a093c>] (mwifiex_sdio_interrupt+0xc8/0x1cc [mwifiex_sdio]) from [<c04bbde0>] (sdio_irq_thread+0x178/0x31c) [ 6630.451079] [<c04bbde0>] (sdio_irq_thread+0x178/0x31c) from [<c0145514>] (kthread+0xc8/0xd8) [ 6630.451095] [<c0145514>] (kthread+0xc8/0xd8) from [<c0106118>] (ret_from_fork+0x14/0x20) This bug has introduced/exposed due to recent patch in which we cancel pending commands before suspend (using hs_enabling flag). The NULL pointer is dereferenced when both mwifiex_cancel_all_pending_cmd() and mwifiex_exec_next_cmd() try to access cmd pending queue simultaneously. 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>
-
Andrea Merello authored
ANAPARAM3 register, defined in the rtl818x common register struct, is accessed as 16bit by rtl8187se and as 8bit by rtl8187b. Since I have no documentation about this, I can only stick to the reference code and to what is known to work. This issue has been addressed by a patch from Larry Finger that introduces an "union", in the register struct. In my last patch-set I applied it on the register struct, but I forget to update rtl8187 driver too. This patch does it. Suggested-by: Larry Finger <Larry.Finger@lwfinger.net> [ Original patch ] Signed-off-by: Andrea Merello <andrea.merello@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-