Fixing coding style by rearranging the switch statement
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>

This saves some space and adds better readability.
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>

Recent changes in udev are causing problems for drivers that load firmware
from the probe routine. As b43 has such a structure, it must be changed.
As this driver loads more than 1 firmware file, changing to the asynchronous routine
request_firmware_nowait() would be complicated. In this implementation, the probe
routine starts a queue that calls the firmware loading routines.
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Recent changes in udev are causing problems for drivers that load firmware
from the probe routine. As b43legacy has such a structure, it must be changed.
As this driver loads 3 or 4 firmware files, changing to the asynchronous routine
request_firmware_nowait() would be complicated. In this implementation, the probe
routine starts a work queue that calls the firmware loading routines.
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Commit 7504a3e1 ("ath6kl: add padding to firmware log records") accidentally
changed debug.c mode from 100644 to 100755. Revert that back to original.
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

ath6kl/cfg80211.c:589: WARNING: max() should probably be
max_t(u16, vif->listen_intvl_t, ATH6KL_MAX_WOW_LISTEN_INTL)
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

ath6kl/sdio.c:875: CHECK: Alignment should match open parenthesis
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Recommended by checkpatch.
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

My patch 24fc32b3 ("ath6kl: add ath6kl_bmi_write_hi32()") caused a regression
in ath6kl_upload_board_file() and the board_address variable was not
properly initialised in some cases:

ath6kl/init.c:1068:6: warning: ‘board_address’ may be used uninitialized
in this function

Most likely this broke ar6004 support but I can't test that right now.
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

mvm_ucode is true when mvm TLVs arive.
Signed-off-by: NDavid Spinadel <david.spinadel@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Change iwl_fw struct to hold an array of fw_img instead of
three separated instances.

Change fw_img to hold an array of fw_desc instead of two
separate descriptors for instructions and data.

Change load_given_ucode, load_section, verification functions
etc. to support this structure.
Signed-off-by: NDavid Spinadel <david.spinadel@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

New TLVs for ucode sections that are not known as
instruction or data.

New TLVs for phy-configuration and default calibrations.

Add default calib and phy config fields to iwl_fw.
Signed-off-by: NDavid Spinadel <david.spinadel@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Changed iwl_firmware_pieces structure to support an array of
separate images, and an array of sections for each image.

In fw_sec and fw_desc structures, added a field for
offset from the HW address, to support 16.0 uCode that
provides an offset instead of any other data about the section.
This field is filled with default values when parsing instruction
or data section.
Signed-off-by: NDavid Spinadel <david.spinadel@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Remove IWL_UCODE_NONE from enum iwl_ucode_type which,
by being the default value in 0-initialized memory,
implicitly allowed us to track whether any uCode had
ever been loaded successfully (which would have been
the INIT uCode) and instead explicitly track whether
or not INIT uCode has been run.
Signed-off-by: NDavid Spinadel <david.spinadel@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Printing the SRAM and similar testmode operations could
be triggered when no uCode is loaded; prevent those
invalid operations by tracking whether uCode is loaded.
Signed-off-by: NDavid Spinadel <david.spinadel@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This wait queue really belongs to the transport
layer, as it is used for sending synchronous
commands to the HW.

However, only op_mode knows about errors and
exceptional conditions, so make this queue
accessible by the op_mode.
Signed-off-by: NMeenakshi Venkataraman <meenakshi.venkataraman@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Looking at logs, I see that we did get the bad
state message a few times for some reason, but
it doesn't indicate why or where it came from,
so make it a warning in order to identify 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>

Mohammed Shafi ran into [1] the SEQ_RX_FRAME workaround
warning with a statistics notification, this means we
can't just remove it as we'd hoped.

Abstract it out so that the higher layer can configure
this as a kind of "filter" in the transport.

[1] http://mid.gmane.org/CAD2nsn1_DzbRHuSbS_1rFNzuux_9pW1-pABEasQ01_y7-ndO5w@mail.gmail.comReported-by: NMohammed Shafi <shafi.wireless@gmail.com>
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>

Tracing is much better for this, so
remove the hex printk debug for the
TX command.
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 check for PS_WAIT_FOR_TX_ACK was inverted, the hardware should only go
to full sleep if no tx is pending.
Reported-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Cc: stable@vger.kernel.org
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

mactime was being overwritten by the function ath9k_rx_skb_preprocess. Fixed by
memsetting rx_status in ath_rx_tasklet.
Signed-off-by: NAshok Nagarajan <ashok@cozybit.com>
Signed-off-by: NJavier Cardona <javier@cozybit.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The proper place to configure bss info is at assoc notification. So that
ath9k continues to work if the supirous bssid notification will be
removed in future.

Cc: Johannes Berg <johannes@sipsolutions.net>
Reported-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

rt2800pci is suffering from beacon skew in AP mode. Some powersaving
clients (like VOIP phones) are getting into trouble after some time
when the beacon skew is getting too big.

The ralink legacy drivers contain a function that indicates that the
beacon timer is off by 1us per tbtt. And this function works around
that by reducing the beacon interval for every 64th beacon transmission
by 64us (the smallest possible value). Do the same in rt2800pci.

This allows proper powersaving when rt2800pci is used in AP mode.
Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

tested in AR9462 Rev:2, both hardware capability flag are set
Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

ipw2200 driver does not use these defines, it uses geo struct instead.
Therefore remove them from its header.

Note: we keep them in the ipw2100 driver's header, because the driver
still uses them.
Signed-off-by: NStanislav Yakovlev <stas.yakovlev@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

On systems with multiple NICs, it's nice to know which
one is producing warnings.  Here is an example of the
new ouput:

ath: wiphy0: Failed to stop TX DMA, queues=0x005!
Signed-off-by: NBen Greear <greearb@candelatech.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The patch "mac80211_hwsim:  Add tsf to beacons, probe responses and radiotap
header" was setting the mactime on wrong hwsim radio. This patch fixes it.
Signed-off-by: NAshok Nagarajan <ashok@cozybit.com>
Signed-off-by: NJavier Cardona <javier@cozybit.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Flush MCI profiles only if MCI is being actually used.
This fixes a panic on driver unload when non-MCI devices
are being used and btcoex_enable is set.

BUG: unable to handle kernel NULL pointer dereference at           (null)
IP: [<ffffffffa06296d2>] ath_mci_flush_profile+0x12/0x100 [ath9k]
Call Trace:
[<ffffffffa061befe>] ath9k_stop_btcoex+0x5e/0x80 [ath9k]
[<ffffffffa061ed57>] ath9k_stop+0xb7/0x230 [ath9k]
[<ffffffffa0533f30>] ieee80211_stop_device+0x50/0x180 [mac80211]
[<ffffffffa051f0cf>] ieee80211_do_stop+0x2af/0x6a0 [mac80211]
[<ffffffffa051f4da>] ieee80211_stop+0x1a/0x20 [mac80211]
[<ffffffff81365d96>] __dev_close_many+0x86/0xe0
[<ffffffff81365ee0>] dev_close_many+0xa0/0x110
[<ffffffff81366038>] rollback_registered_many+0xe8/0x260
[<ffffffff813661cb>] unregister_netdevice_many+0x1b/0x80
[<ffffffffa051e950>] ieee80211_remove_interfaces+0xd0/0x110 [mac80211]
[<ffffffffa050c133>] ieee80211_unregister_hw+0x53/0x120 [mac80211]
[<ffffffffa061d5a4>] ath9k_deinit_device+0x44/0x70 [ath9k]
[<ffffffffa062c1d4>] ath_pci_remove+0x54/0xa0 [ath9k]
[<ffffffff81267c46>] pci_device_remove+0x46/0x110
[<ffffffff8131021c>] __device_release_driver+0x7c/0xe0
[<ffffffff81310960>] driver_detach+0xd0/0xe0
[<ffffffff81310078>] bus_remove_driver+0x88/0xe0
[<ffffffff81311122>] driver_unregister+0x62/0xa0
[<ffffffff81268004>] pci_unregister_driver+0x44/0xc0
[<ffffffffa062c8b5>] ath_pci_exit+0x15/0x20 [ath9k]
[<ffffffffa063205d>] ath9k_exit+0x15/0x31 [ath9k]
[<ffffffff810b92cc>] sys_delete_module+0x18c/0x270
[<ffffffff814373dd>] ? retint_swapgs+0x13/0x1b
[<ffffffff8124828e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[<ffffffff81437de9>] system_call_fastpath+0x16/0x1b
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Portion of the commit id 080eec4f ("ath6kl: Clear the IE in firmware
if not set") was overwritten by mistake due to a merge
conflict. This patch fixes the code back to how it should be.

kvalo: more details to the commit log
Signed-off-by: NAarthi Thiruvengadam <athiruve@qca.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

BIg portion of "iwlwifi: remove max_txq_num from hw_params" was
missing during merge, here is the fix for it.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

iwlwifi: move command queue number out of the iwl_shared struct
move the cmd_queue out of iwl_shared struct, but for some reason the
patch is half done and fail compile

Here is the fix

John, could you apply this patch to wireless-next to address the issue
Thanks
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

in iwlwifi: move setting up fw parameters

Meenakshi moved code up to configure the transport layer, but this
code read the sku before it was set (from the EEPROM). This killed
P2P.
Only the ucode_flags are needed to configure the transport layer, not
the sku which _must_ be set after the EEPROM is read.

We need to reconfigure the transport in case the EEPROM disabled PAN
support. This is not the nicest thing to do, but we have no choice.
Document that we are allowed to configure the transport several times
before start_fw, but not after.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The command queue number is required by the transport
layer, but it can be determined only by the op mode.
Move this parameter to the dvm op mode, and configure
the transport layer using an API.
Signed-off-by: NMeenakshi Venkataraman <meenakshi.venkataraman@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

In recent commit "mwifiex: correct bitrates advertised..", we have
removed 22Mbps and 72Mbps bitrates from supported bitrate array.
It means number of bitrates has reduced from 14 to 12.

Initialize ".n_bitrates" to array size instead of hardcoding it.
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>

Driver does not use it any more.
Signed-off-by: NStanislav Yakovlev <stas.yakovlev@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

I missed a couple of status bits in my refactoring changes.  This
fixes the ones I missed.
Signed-off-by: NDon Fry <donald.h.fry@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

With the mac80211 deauth sequence changes, the
station is deleted before the device is set
unassociated. This can cause the device to get
confused as it expects the station to be there
while the associated bit is set.

To fix this, do not delete the AP station from
the device when mac80211 asks for deletion,
instead just mark it as unused and rely on the
unassociated RXON to drop it from the station
database in the device.
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>

It's not needed anywhere but during init.
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 only reason we ever stop/wake queues at
the transport level is now that they become
full (or non-full), so the messages aren't
useful any more -- remove them.
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>

Continue splitting the status bits between transport and op_mode.
All but a few are separated.
Signed-off-by: NDon Fry <donald.h.fry@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>