All the supported firmwares have this flag set.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

All the supported firmwares have this flag set.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

All the supported firmwares have this flag set.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

All the supported firmwares have this flag set.
Reviewed-by: NLuciano Coelho <luciano.coelho@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

All the supported firmwares have this flag set.
Reviewed-by: NAlexander Bondar <alexander.bondar@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

All the supported firmwares have this flag set.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

All the supported firmwares have this flag set.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

All the supported firmwares have this flag set.
Reviewed-by: NAlexander Bondar <alexander.bondar@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

All the supported firmwares have this flag set.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

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: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

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: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

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: NEyal Shapira <eyalx.shapira@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

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: NMonam Agarwal <monamagarwal123@gmail.com>
[rewrite commit log]
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

The firmware doesn't support broadcast filtering on P2P
client. Trying to enable it makes the firmware assert.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

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: NEytan Lifshitz <eytan.lifshitz@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

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: NEytan Lifshitz <eytan.lifshitz@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

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: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

This must not happen - otherwise we might keep flushing
forever.
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

This will be used later to flush / wait for queues that are
related to a specific vif.
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

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: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

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: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

This define is related to the firmware packaging and is
needed by more than one transport.
Signed-off-by: NEran Harary <eran.harary@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Besides the different allocation flags, they are really
the same. Pass the gfp_t flags as a parameter, and unify
them.
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

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: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

When updating the write pointer, the TX queue should be locked
to get consistent state, fix that in the interrupt handler.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Instead of using u8 to hold logic values, use bool.

Also fix a comment, the return value is no longer relevant.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

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: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

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: NJohannes Berg <johannes.berg@intel.com>
Reviewed-by: NIdo Yariv <ido@wizery.com>
[Squash different patches and rewrite the commit message]
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

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: NEliad Peller <eliadx.peller@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

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: NEliad Peller <eliadx.peller@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

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: NEliad Peller <eliadx.peller@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

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: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Number of channels changed from 40 to 50
Signed-off-by: NEran Harary <eran.harary@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

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: NAvri Altman <avri.altman@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

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: NAlexey Khoroshilov <khoroshilov@ispras.ru>
Acked-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NAndrea Merello <andrea.merello@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

There is a missing set of curly braces here so the debug output says
"Probe confirm received" unintentionally.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

[ 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: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NAndrea Merello <andrea.merello@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>