I can't find any valid reason for not setting the ATH9K_RX_FILTER_PSPOLL
flag on older hardware and neither the documentation nor the reference
code mention any reason for excluding older hardware here.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Instead of having separate key information definitions for
each type of key, a common key information bitmap is used.
Signed-off-by: NYogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Before calling host_to_card() to send the cmd to firmware,
we use skb_push() to add 4 bytes SDIO interface header at
the start of the data buffer. Since cmd_skb data structure
will be re-used at a later time, we need to restore its
headroom by removing the 4 bytes header.
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NMarc Yang <yangyang@marvell.com>
Signed-off-by: NYogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The problem is that when the attenuation is increased,
the rate will start to drop from MCS7 -> MCS6, and finally
will see MCS1 -> CCK_11Mbps. When the rate is changed b/w
CCK and OFDM, it will use register desired_scale to calculate
how much tx gain need to change.

The output power with the same tx gain for CCK and OFDM modulated
signals are different. This difference is constant for AR9280
but not AR9285/AR9271. It has different PA architecture
a constant. So it should be calibrated against this PA
characteristic.

The driver has to read the calibrated values from EEPROM and set
the tx power registers accordingly.
Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com>
Acked-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This function returns true if there is atleast one frame
in any one of the tx queues.
Signed-off-by: NVivek Natarajan <vnatarajan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

In a highly noisy environment, the tx rate of the driver drops and
the application slows down since it has not yet received ACKs for
the frames already queued in the hardware. Since this ACK may take
more than 100ms, stopping the dev queues for entering PS at this
stage breaks applications, WMM test cases in my testing.
If there are frames already pending in the tx queue, postponing the
PS logic helps to avoid redundant queue stops. When power save is
enabled by default and in a noisy environment, this API certainly
helps in improving the average throughput.
Signed-off-by: NVivek Natarajan <vnatarajan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

If we maintain API properly, then there isn't
really a reason to warn about this since we'll
just be adding things that are safe to ignore,
so downgrade the warning to debug info level.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

There's no need to keep both normal and BT statistics
versions around all the time in memory when we only
use a subset of both. So keep only the subsets that
we need in memory, depending on the debug config).

Also, in doing so, we can remove all the calls to
iwl_bt_statistics() in the driver as we'll just
access the copied statistics now.

Finally, also remove this call from the one place
where it might still be needed and automatically
detect what kind of statistics the device is sending
based on their size. This way, we don't need to keep
track of which devices do what any more, which is
good since this is subject to change based on the
ucode version (as some ucode even for non-BT devices
will in fact use BT statistics).

Warn upon encountering a statistics command from the
ucode that isn't known, so we will find such issues
earlier in the future.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Tested-by: NDon Fry <donald.h.fry@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

_agn driver should perform both sensitivity and chain noise calib.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Remove the config flag for tx power calib
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Remove broken_power_save checking
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

More cleanup code, no functional changes
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

After driver split, set_l0s config is no longer needed, remove it
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Remove the reference to both 3945 and 4965 in LED code
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

More clean up after driver split
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

3945 no longer apply
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Remove 3945 define
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

For 2000 series NICs, disable OTP refresh in order to read correct
PAPD table from high OTP block
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

If change_interface gets invoked during a firmware
restart, it may crash; prevent that from happening
by checking if ctx->vif is assigned.

Additionally, in my initial commit I forgot to set
the vif->p2p variable correctly, so fix that too.

Cc: stable@kernel.org [2.6.38+]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

The microcode may sometimes reject TX frames when
on a radar channel even after we associated as it
clears information during association and needs to
receive a new beacon before allowing that channel
again. This manifests itself as a TX status value
of TX_STATUS_FAIL_PASSIVE_NO_RX. So in this case,
stop the corresponding queue and give the frame
back to mac80211 for retransmission. We start the
queue again when a beacon from the AP is received
which will make the regulatory enforcement in the
device allow transmitting again.
Signed-off-by: NGaren Tamrazian <garenx.tamrazian@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

After driver split, no need to use function pointer for those event and
register dump function.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

define of firmware filenames use extra macro to build the files name.
Signed-off-by: NJay Sternberg <jay.e.sternberg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Conflicts:
	drivers/net/wireless/rtlwifi/efuse.c
	drivers/net/wireless/rtlwifi/rtl8192c/fw_common.c
	net/bluetooth/mgmt.c

We have no other option but to inform userspace that we
have queued up their regulatory hint request when we are
given one given that nl80211 operates atomically on user
requests. The best we can do is accept the request, and
add a delayed work item for processing failure and cancel it
if we succeeed. Upon failure we restore the regulatory
settings and ignore the user input.

This fixes this reported bug:

https://bugzilla.kernel.org/show_bug.cgi?id=28112

Reported-by: gregoryx.alagnou@intel.com
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When we restore regulatory settings its possible CRDA
will not reply because of a bogus user entry. In this
case the bogus entry will prevent any further processing
on cfg80211 for regulatory domains even if we restore
regulatory settings.

To prevent this we suck out all pending requests when
restoring regulatory settings and add them back into the
queue after we have queued up the reset work.

The impact of not having this applied is that a user
with privileges can issue a userspace regulatory hint
while we are disasocciating and this would prevent any
further processing of regulatory domains.
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This generates a massive reduction in module size:
with debug:
   text	   data	    bss	    dec	    hex	filename
 670300	  13136	    420	 683856	  a6f50	iwlagn.ko (before)
 388347	  13136	    408	 401891	  621e3	iwlagn.ko (after)

without debug:
   text	   data	    bss	    dec	    hex	filename
 528575	  13072	    420	 542067	  84573	iwlagn.ko (before)
 294192	  13072	    408	 307672	  4b1d8	iwlagn.ko (after)

This also removes all the IO debug functionality since
it can easily be replaced by tracing, and makes the
code unnecessarily complex.

I haven't done any CPU utilisation measurements, but
given that the hotpaths don't use much IO it is not
likely to have a negative impact; in fact, the size
reduction will reduce cache pressure which possibly
improves performance.

Finally, an unused function or two were removed.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The ISR (interrupt service routine) ops are now
no longer necessary since they are the same for
all devices this driver now handles.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We never use the value in alloc_rxb_page,
so there's no point in keeping it either.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The rev_id variable is only printed, we
don't need to store it.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The hw_rev variable is used only during init,
so there's no need to keep it around.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The variable is never used.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Again, a 4965 specific code path that we no
longer need in iwlagn.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We know after loading the ucode whether it will
support PAN or not, so we can also initialise
the cmd_queue variable much earlier.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Devices newer than 4965 don't actually send
two different versions of the ALIVE command,
so we always had a bug here since before this
patch we copy more data than we got. Remove
the iwl_init_alive_resp struct and don't use
it.

Since we also really don't need to track all
the data received in ALIVE as we only use the
error and log event tables later, we can also
save space by just keeping those and not more
data around in memory.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

My previous patch left a message talking about
bootstrap, but that's clearly bogus.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Some new devices and microcode files will a greater
variety of features, so the TLV-per-feature approach
we took before will quickly make things harder to
manage and increase the file size.

Add a new TLV that has feature flags. Currently, it
will contain:
 1) a PAN feature flag, which moves from a separate
    TLV
 2) a new BT stats bit that indicates whether the
    microcode image uses bluetooth statistics
 3) a new MFP flag for management frame protection
    which can be enabled once the device/microcode
    supports it
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

In alive notify, we should check return code instead of assume everything ok
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This was used only on 4965 in conjunction with
the bootstrap ucode.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The ucode restart has to take into account a number
of things, like clearing the HCMD_ACTIVE and other
status bits, and waking up the wait_command_queue.
Currently, however, there are a number of places
that neither do that, nor actually set the FW error
bit that leads to proper restart handling, which
means that in those cases things will probably just
hang completely.

To clean this up, make all ucode restart go through
a single function, except for the cases where it's
called during firmware loading.

Also fix a bug in wimax coexist restart avoidance,
it needs to first clear the status bits (and it has
to clear the HCMD_ACTIVE one as well) and then wake
up anything waiting on wait_command_queue.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>