OTP size changed in family 7000 and in family 8000.
Signed-off-by: NEran Harary <eran.harary@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

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

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

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

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

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

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

My bad - I forgot to update this when sending the patch
upstream.

Fixes: 87d5e415 ("iwlwifi: mvm: rs: reinit rs if no tx for a long time")
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

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: b9fae2d5 ("iwlwifi: mvm: BT Coex add support for Co-running block")
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Signed-off-by: NJahnavi Meher <jahnavi.meher@redpinesignals.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Adjust FIR filter co-efficients to improve EVM for 11b rates.
Signed-off-by: NRajkumar Manoharan <rmanohar@qti.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

 * rfsat gainchange hysteresis of rf_gain stuck with large
   interference present.
Signed-off-by: NRajkumar Manoharan <rmanohar@qti.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NNikolay Ledovskikh <nledovskikh@gmail.com>
Acked-by: NNick Kossifidis <mickflemm@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Use a newline character appropriately.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NChristian Engelmayer <cengelma@gmx.at>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

94010fa0 ("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/1310512Signed-off-by: NAdam Lee <adam.lee@canonical.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This reverts commit 2a54eb5e
("rtlwifi: rtl8188ee: enable MSI interrupts mode").

94010fa0 ("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/1310512Signed-off-by: NAdam Lee <adam.lee@canonical.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This removes dealing with pointers directly and allows tracking radio
state with radio_on variable.
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

mac80211 takes care of all the needed steps for hwsim, so indicate
support for this capability.
Signed-off-by: NJouni Malinen <jouni@qca.qualcomm.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This reverts commit e050c76f.

I'm not sure what crack pipe I was using when I merged this...
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This is the first step to remove leftover code.
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Some ancient Broadcom devices had one core per band, e.g.:
ssb: Found chip with id 0x4306, rev 0x02 and package 0x00
ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x02, vendor 0x4243)
ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x04, vendor 0x4243)
ssb: Core 2 found: PCMCIA (cc 0x80D, rev 0x01, vendor 0x4243)
ssb: Core 3 found: V90 (cc 0x807, rev 0x01, vendor 0x4243)
ssb: Core 4 found: PCI (cc 0x804, rev 0x07, vendor 0x4243)
ssb: Core 5 found: IEEE 802.11 (cc 0x812, rev 0x04, vendor 0x4243)

This hardware model was dropped for newer devices handled by b43.
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We've implemented table calculation, but forgot to enable writing it in
power setup function.
By the way document table layout.
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Logic in specs and our code was wrong. Init and calibration values for
newer cards depend on radio revision, not PHY revision.
To make code clearer, change tables names to include "radio" or "phy".
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

They were extracted from MMIO dumps of 14e4:4353 and wl 6.30.223.141.
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Mostly just add place for future code
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Bit 0x200 has been noticed in the following log:
 radio_read(0x02ca) -> 0x0000
radio_write(0x00ca) <- 0x0080
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

New Broadcom drivers don't upload it anymore. It was probably a copy & paste
mistake in early N-PHY rev 3+ days.
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Currently AMSDU and AMPDU aggregation is enabled for TID 0 to
TID 5 streams. Lets enable it for remaining two streams also.
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NAvinash Patil <patila@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This will help to aggregate more packets which yields better
throughput results for 11ac chipsets.
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NAvinash Patil <patila@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This will help to aggregate more packets which yields better
throughput results.
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NAvinash Patil <patila@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Firmware dump feature is added for PCIe based chipsets.
Separate file will be created at /var/log/fw_dump_*
for each memory segment.
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>

This option be useful to dump firmware memory for debugging
purpose. Actual code to dump firmware momory for SDIO and PCIe
chipsets will be added later.
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>