Set the gf_protection bit when calling ACX_HT_BSS_OPERATION according
to the GF bit passed by mac80211 in ht_operation_mode.

[Added a proper commit message -- Luca]
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>

Commands are sometimes sent to FW on scan completion. Make sure the chip
is awake to receive them. Sending commands while the chip is in ELP
can cause SDIO read errors and/or crash the FW.
Signed-off-by: Arik Nemtsov <arik@wizery.com>
Signed-off-by: Ido Yariv <ido@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>

Tests have shown that the requested number of memory blocks is
sub-optimal. Slightly modify the requested number of memory blocks for
TX.
Signed-off-by: Ido Yariv <ido@wizery.com>
Reviewed-by: Luciano Coelho <coelho@ti.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>

TX might be handled in the threaded IRQ handler, in which case, TX work
might be scheduled just to discover it has nothing to do.

Save a few context switches by cancelling redundant TX work in case TX
is about to be handled in the threaded IRQ handler. Also, avoid
scheduling TX work from wl1271_op_tx if not needed.
Signed-off-by: Ido Yariv <ido@wizery.com>
Reviewed-by: Luciano Coelho <coelho@ti.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>

The interrupt of the wl12xx is a level interrupt in nature, since the
interrupt line is not auto-reset. However, since resetting the interrupt
requires bus transactions, this cannot be done from an interrupt
context. Thus, requesting a level interrupt would require to disable the
irq and re-enable it after the HW is acknowledged. Since we now request
a threaded irq, this can also be done by specifying the IRQF_ONESHOT
flag.

Triggering on an edge can be problematic in some platforms, if the
sampling frequency is not sufficient for detecting very frequent
interrupts. In case an interrupt is missed, the driver will hang as the
interrupt line will stay high until it is acknowledged by the driver,
which will never happen.

Fix this by requesting a level triggered interrupt, with the
IRQF_ONESHOT flag.
Signed-off-by: Ido Yariv <ido@wizery.com>
Reviewed-by: Luciano Coelho <coelho@ti.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>

To achieve maximal throughput, it is very important to react to
interrupts as soon as possible. Currently the interrupt handler wakes up
a worker for handling interrupts in process context. A cleaner and more
efficient design would be to request a threaded interrupt handler.  This
handler's priority is very high, and can do blocking operations such as
SDIO/SPI transactions.

Some work can be deferred, mostly calls to mac80211 APIs
(ieee80211_rx_ni and ieee80211_tx_status). By deferring such work to a
different worker, we can keep the irq handler thread more I/O
responsive. In addition, on multi-core systems the two threads can be
scheduled on different cores, which will improve overall performance.

The use of WL1271_FLAG_IRQ_PENDING & WL1271_FLAG_IRQ_RUNNING was
changed. For simplicity, always query the FW for more pending
interrupts. Since there are relatively long bursts of interrupts, the
extra FW status read overhead is negligible. In addition, this enables
registering the IRQ handler with the ONESHOT option.
Signed-off-by: Ido Yariv <ido@wizery.com>
Reviewed-by: Luciano Coelho <coelho@ti.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>

The SDIO bus is claimed and released for each SDIO transaction. In
addition to the few CPU cycles it takes to claim and release the bus, it
may also cause undesired side effects such as the MMC host stopping its
internal clocks.

Since only the wl12xx_sdio driver drives this SDIO card, it is safe to
claim the SDIO host once (on power on), and release it only when turning
the power off.

This patch was inspired by Juuso Oikarinen's (juuso.oikarinen@nokia.com)
patch "wl12xx: Change claiming of the (SDIO) bus".
Signed-off-by: Ido Yariv <ido@wizery.com>
Reviewed-by: Luciano Coelho <coelho@ti.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>

On newer hardware revisions, there is no need to write the host's
counter at the end of a RX transaction. The same applies to writing the
number of packets at the end of a TX transaction.

It is generally a good idea to avoid unnecessary SDIO/SPI transfers.
Throughput and CPU usage are improved when avoiding these.

Send the host's RX counter and the TX packet count only if needed, based
on the hardware revision.

[Changed WL12XX_QUIRK_END_OF_TRANSACTION to use BIT(0) -- Luca]
Signed-off-by: Ido Yariv <ido@wizery.com>
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Reviewed-by: Luciano Coelho <coelho@ti.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>

The FW has a limited amount of memory for holding frames. In case it
runs out of memory reserved for RX frames, it'll have no other choice
but to drop packets received from the AP. Thus, it is important to
handle RX data interrupts as soon as possible, before handling anything
else.

In addition, since there are enough TX descriptors to go around, it is
better to first send TX frames, and only then handle TX completions.

Fix this by changing the order of function calls in wl1271_irq_work.
Signed-off-by: Ido Yariv <ido@wizery.com>
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Reviewed-by: Luciano Coelho <coelho@ti.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>

Frames in the tx_frames array include extra private headers, which must
be removed before passing the skbs to ieee80211_tx_status.

Fix this by removing any private headers in wl1271_tx_reset, similar to
how this is done in wl1271_tx_complete_packet.
Signed-off-by: Ido Yariv <ido@wizery.com>
Signed-off-by: Arik Nemtsov <arik@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>

Runtime PM might not always be enabled. Even if it is enabled in the
running kernel, it can still be temporarily disabled, for instance
during suspend. Runtime PM is opportunistic in nature, and should not be
relied on for toggling power.

In case the interface is removed and re-added while runtime PM is
disabled, the FW will fail to boot, as it is mandatory to toggle power
between boots. For instance, this can happen during suspend in case one
of the devices fails to suspend before the MMC host suspends, but after
mac80211 was suspended. The interface will be removed and reactivated
without toggling the power.

Fix this by calling mmc_power_save_host/mmc_power_restore_host in
wl1271_sdio_power_on/off functions. It will toggle the power to the chip
even if runtime PM is disabled. The runtime PM functions should still be
called to make sure runtime PM does not opportunistically power the chip
off (e.g. after resuming from system suspend).
Signed-off-by: Ido Yariv <ido@wizery.com>
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>

In the linux-firmware git tree, the firmwares and the NVS are inside
the ti-connectivity directory.  Fix the filenames that the driver
looks for accordingly.

[Fixed commit message and merged with the latest changes. -- Luca]
Signed-off-by: Sebastien Jan <s-jan@ti.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>

... Otherwise it is displayed when mac80211 isn't
even turned on, which is completely pointless.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

This finally makes TX on OFDM rates possible on my dev with PHY rev 4.
We still have lower performance than wl, but at least speeds around 15M
become possible.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

When a second module such as rtl8192ce or rtl8192cu links to rtlwifi, the attempt
to register a rate-control mechanism fails with the warning shown below. The fix is to
select the RC mechanism when rtlwifi is initialized.

WARNING: at net/mac80211/rate.c:42 ieee80211_rate_control_register+0xc9/0x100 [mac80211]()
Hardware name: HP Pavilion dv2700 Notebook PC
Modules linked in: arc4 ecb rtl8192ce rtl8192cu(+) rtl8192c_common rtlwifi snd_hda_codec_conexant amd74xx(+) ide_core sg mac80211 snd_hda_intel snd_hda_codec i2c_nforce2 snd_pcm snd_timer cfg80211 snd k8temp hwmon serio_raw joydev i2c_core soundcore snd_page_alloc rfkill forcedeth video ac battery button ext3 jbd mbcache sd_mod ohci_hcd ahci libahci libata scsi_mod ehci_hcd usbcore fan processor thermal
Pid: 2227, comm: modprobe Not tainted 2.6.38-rc6-wl+ #468
Call Trace:
 [<ffffffff8104a3da>] ? warn_slowpath_common+0x7a/0xb0
 [<ffffffff8104a425>] ? warn_slowpath_null+0x15/0x20
 [<ffffffffa02de409>] ? ieee80211_rate_control_register+0xc9/0x100 [mac80211]
 [<ffffffffa03b3790>] ? rtl_rate_control_register+0x10/0x20 [rtlwifi]
 [<ffffffffa03ab9c9>] ? rtl_init_core+0x189/0x620 [rtlwifi]
 [<ffffffff811cfff8>] ? __raw_spin_lock_init+0x38/0x70
 [<ffffffffa03b9dea>] ? rtl_usb_probe+0x709/0x82e [rtlwifi]
 [<ffffffffa002a7fd>] ? usb_match_one_id+0x3d/0xc0 [usbcore]
 [<ffffffffa002aae9>] ? usb_probe_interface+0xb9/0x160 [usbcore]
 [<ffffffff8126ed19>] ? driver_probe_device+0x89/0x1a0
 [<ffffffff8126eed3>] ? __driver_attach+0xa3/0xb0
 [<ffffffff8126ee30>] ? __driver_attach+0x0/0xb0
 [<ffffffff8126dd4e>] ? bus_for_each_dev+0x5e/0x90
 [<ffffffff8126e9d9>] ? driver_attach+0x19/0x20
 [<ffffffff8126e5e8>] ? bus_add_driver+0x158/0x290
 [<ffffffff8126f151>] ? driver_register+0x71/0x140
 [<ffffffff811cfff8>] ? __raw_spin_lock_init+0x38/0x70
 [<ffffffffa002a2cc>] ? usb_register_driver+0xdc/0x190 [usbcore]
 [<ffffffffa0013000>] ? rtl8192cu_init+0x0/0x20 [rtl8192cu]
 [<ffffffffa001301e>] ? rtl8192cu_init+0x1e/0x20 [rtl8192cu]
 [<ffffffff810002cf>] ? do_one_initcall+0x3f/0x180
 [<ffffffff8108fd4b>] ? sys_init_module+0xbb/0x200
 [<ffffffff81002c7b>] ? system_call_fastpath+0x16/0x1b
 ---[ end trace 726271c07a47439e ]---
rtlwifi:rtl_init_core():<0-0> rtl: Unable to register rtl_rc,use default RC !!
ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
Signed-off-by: Chaoming Li <chaoming_li@realsil.com.cn>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Also fix a typo in the STATION_INFO_TX_BITRATE description
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

The AID and BSSID should be set in the HW only for the
first station interface or adhoc interface. Also, cancel
the ANI timer in stop() for multi-STA scenario. And finally
configure the HW beacon timers only for the first station
interface.
Signed-off-by: Sujith Manoharan <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

There is no need to have separate iwl-agn-rx.c file after iwlegacy
split.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Remove check_plcp_health and check_ack_health ops methods, they are
unneeded after iwlegacy driver split. Merge check health code into to
iwl-rx.c and make functions static.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Add module ack_check, and plcp_check parameters. Ack_check is disabled
by default since is proved that check ack health can cause troubles.
Plcp_check is enabled by default.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Fix possible dma mappings and skbs introduced by commit
470058e0 "iwlwifi: avoid Tx queue
memory allocation in interface down".
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Since commit commit 470058e0
"iwlwifi: avoid Tx queue memory allocation in interface down" we do
not unmap dma and free skbs when down device and there is pending
transfer. What in consequence may cause that system hung (waiting
for free skb's) when performing shutdown at iptables module unload.

DMA leak manifest itself following warning:

WARNING: at lib/dma-debug.c:689 dma_debug_device_change+0x15a/0x1b0()
Hardware name: HP xw8600 Workstation
pci 0000:80:00.0: DMA-API: device driver has pending DMA allocations while released from device [count=240]
Modules linked in: iwlagn(-) aes_x86_64 aes_generic fuse cpufreq_ondemand acpi_cpufreq freq_table mperf xt_physdev ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables ipv6 ext3 jbd dm_mirror dm_region_hash dm_log dm_mod uinput hp_wmi sparse_keymap sg wmi microcode serio_raw tg3 arc4 ecb shpchp mac80211 cfg80211 rfkill ext4 mbcache jbd2 sr_mod cdrom sd_mod crc_t10dif firewire_ohci firewire_core crc_itu_t mptsas mptscsih mptbase scsi_transport_sas pata_acpi ata_generic ata_piix ahci libahci floppy nouveau ttm drm_kms_helper drm i2c_algo_bit i2c_core video [last unloaded: iwlagn]
Pid: 9131, comm: rmmod Tainted: G        W   2.6.38-rc6-wl+ #33
Call Trace:
 [<ffffffff810649ef>] ? warn_slowpath_common+0x7f/0xc0
 [<ffffffff81064ae6>] ? warn_slowpath_fmt+0x46/0x50
 [<ffffffff812320ab>] ? dma_debug_device_change+0xdb/0x1b0
 [<ffffffff8123212a>] ? dma_debug_device_change+0x15a/0x1b0
 [<ffffffff8149dc18>] ? notifier_call_chain+0x58/0xb0
 [<ffffffff8108e370>] ? __blocking_notifier_call_chain+0x60/0x90
 [<ffffffff8108e3b6>] ? blocking_notifier_call_chain+0x16/0x20
 [<ffffffff812f570c>] ? __device_release_driver+0xbc/0xe0
 [<ffffffff812f5808>] ? driver_detach+0xd8/0xe0
 [<ffffffff812f45d1>] ? bus_remove_driver+0x91/0x100
 [<ffffffff812f6022>] ? driver_unregister+0x62/0xa0
 [<ffffffff8123d5d4>] ? pci_unregister_driver+0x44/0xa0
 [<ffffffffa05632d1>] ? iwl_exit+0x15/0x1c [iwlagn]
 [<ffffffff810ab492>] ? sys_delete_module+0x1a2/0x270
 [<ffffffff81498da9>] ? trace_hardirqs_on_thunk+0x3a/0x3f
 [<ffffffff8100bf42>] ? system_call_fastpath+0x16/0x1b

I still can observe above warning after apply patch, but it is very
hard to reproduce it, and have count=1. Whereas that one is easy to
reproduce using debugfs force_reset while transmitting data, and have
very big counts eg. 240, like quoted here. So count=1 WARNING seems
to be different issue that need to be resolved separately.

v1 -> v2: fix infinity loop bug I made during "for" to "while" loop transition.
v2 -> v3: remove unneeded EXPORT_SYMBOL
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

AR9485 doesn't use the default GPIO pin for LED and GPIO 6 is actually
used for this.
Signed-off-by: Senthil Balasubramanian <senthilkumar@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

If the RSSI calibration table was not found or not parsed properly,
priv->rssi_db will be NULL, p54_rssi_find needs to be able to deal
with that.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Acked-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

drivers/net/wireless/rtlwifi/rtl8192ce/trx.c: In function ‘rtl92ce_rx_query_desc’:
drivers/net/wireless/rtlwifi/rtl8192ce/trx.c:255:5: warning: ‘rf_rx_num’ may be used uninitialized in this function
drivers/net/wireless/rtlwifi/rtl8192ce/trx.c:257:12: warning: ‘total_rssi’ may be used uninitialized in this function
drivers/net/wireless/rtlwifi/rtl8192ce/trx.c:466:6: warning: ‘weighting’ may be used uninitialized in this function

This work was supported by a hardware donation from the CE Linux Forum.
Signed-off-by: Alessio Igor Bogani <abogani@kernel.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

===================================================
[ INFO: suspicious rcu_dereference_check() usage. ]
---------------------------------------------------
net/mac80211/sta_info.c:125 invoked rcu_dereference_check() without protection!

other info that might help us debug this:

rcu_scheduler_active = 1, debug_locks = 0
5 locks held by wpa_supplicant/468:
 #0:  (rtnl_mutex){+.+.+.}, at: [<c1465d84>] rtnl_lock+0x14/0x20
 #1:  (&rdev->mtx){+.+.+.}, at: [<f84b8c2b>] cfg80211_mgd_wext_siwfreq+0x6b/0x170 [cfg80211]
 #2:  (&rdev->devlist_mtx){+.+.+.}, at: [<f84b8c37>] cfg80211_mgd_wext_siwfreq+0x77/0x170 [cfg80211]
 #3:  (&wdev->mtx){+.+.+.}, at: [<f84b8c44>] cfg80211_mgd_wext_siwfreq+0x84/0x170 [cfg80211]
 #4:  (&rtlpriv->locks.conf_mutex){+.+.+.}, at: [<f8506476>] rtl_op_bss_info_changed+0x26/0xc10 [rtlwifi]

stack backtrace:
Pid: 468, comm: wpa_supplicant Not tainted 2.6.38-rc6+ #79
Call Trace:
 [<c108806a>] ? lockdep_rcu_dereference+0xaa/0xb0
 [<f8523d2c>] ? sta_info_get_bss+0x19c/0x1b0 [mac80211]
 [<f8523d62>] ? ieee80211_find_sta+0x22/0x40 [mac80211]
 [<f850661c>] ? rtl_op_bss_info_changed+0x1cc/0xc10 [rtlwifi]
 [<c153671c>] ? __mutex_unlock_slowpath+0x14c/0x160
 [<c153673d>] ? mutex_unlock+0xd/0x10
 [<f8507180>] ? rtl_op_config+0x120/0x310 [rtlwifi]
 [<c10896db>] ? trace_hardirqs_on+0xb/0x10
 [<f8522169>] ? ieee80211_bss_info_change_notify+0xf9/0x1f0 [mac80211]
 [<f8506450>] ? rtl_op_bss_info_changed+0x0/0xc10 [rtlwifi]
 [<f853646f>] ? ieee80211_set_channel+0xbf/0xd0 [mac80211]
 [<f84b5f41>] ? cfg80211_set_freq+0x121/0x180 [cfg80211]
 [<f85363b0>] ? ieee80211_set_channel+0x0/0xd0 [mac80211]
 [<f84b8ceb>] ? cfg80211_mgd_wext_siwfreq+0x12b/0x170 [cfg80211]
 [<f84b87eb>] ? cfg80211_wext_siwfreq+0x9b/0x100 [cfg80211]
 [<c153b98b>] ? sub_preempt_count+0x7b/0xb0
 [<c150f874>] ? ioctl_standard_call+0x74/0x3b0
 [<c1465d84>] ? rtnl_lock+0x14/0x20
 [<f84b8750>] ? cfg80211_wext_siwfreq+0x0/0x100 [cfg80211]
 [<c14568bd>] ? __dev_get_by_name+0x8d/0xb0
 [<c150fddb>] ? wext_handle_ioctl+0x16b/0x180
 [<f84b8750>] ? cfg80211_wext_siwfreq+0x0/0x100 [cfg80211]
 [<c145bc7a>] ? dev_ioctl+0x5ba/0x720
 [<c108a947>] ? __lock_acquire+0x3e7/0x19b0
 [<c1443b0b>] ? sock_ioctl+0x1eb/0x290
 [<c108bfa5>] ? lock_release_non_nested+0x95/0x2f0
 [<c1443920>] ? sock_ioctl+0x0/0x290
 [<c114d74d>] ? do_vfs_ioctl+0x7d/0x5c0
 [<c1112232>] ? might_fault+0x62/0xb0
 [<c113e3c6>] ? fget_light+0x226/0x390
 [<c1112278>] ? might_fault+0xa8/0xb0
 [<c114dd17>] ? sys_ioctl+0x87/0x90
 [<c1002f9f>] ? sysenter_do_call+0x12/0x38

This work was supported by a hardware donation from the CE Linux Forum.
Signed-off-by: Alessio Igor Bogani <abogani@kernel.org>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

rate_mask is initialized again later so this can be removed.  Btw, if
rate_control_send_low(sta, priv_sta, txrc) returns false, that means
that "sta" is non-NULL.  That's why the second initialization of
rate_mask is a little simpler than the first.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Acked-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

If we want something "bool" built-in in something "tristate" it can't
"depend on" the tristate config option.

Report by DaveM:

   I give it 'y' just to make it happen, for both, and afterways no
   matter how many times I rerun "make oldconfig" I keep seeing things
   like this in my build:

scripts/kconfig/conf --silentoldconfig Kconfig
include/config/auto.conf:986:warning: symbol value 'm' invalid for BT_SCO
include/config/auto.conf:3156:warning: symbol value 'm' invalid for BT_L2CAP
Reported-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Merge branch 'wireless-next-2.6' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-2.6

  CC [M]  drivers/net/wireless/at76c50x-usb.o
drivers/net/wireless/at76c50x-usb.c: In function ‘at76_mac80211_tx’:
drivers/net/wireless/at76c50x-usb.c:1759:4: warning: ‘return’ with a value, in function returning void

This is fallout from commit 7bb45683
("mac80211: make tx() operation return void").
Signed-off-by: John W. Linville <linville@tuxdriver.com>

For 2000 series device, use session 2 type of BT UART message
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>

Both inquiry and page was combine in frame7 of UART message, separate it
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>

additional UART message defines
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>

2000 series has different bt config command structure, add support for it
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>

No functional changes, name changes to reflect the structure used by
6000 series.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>

drivers/net/wireless/iwlegacy/built-in.o:(.rodata+0x29f0): multiple definition of `iwl_rates'
drivers/net/wireless/iwlwifi/built-in.o:(.rodata+0xa68): first defined here
powerpc64-linux-ld: Warning: size of symbol `iwl_rates' changed from 143 in drivers/net/wireless/iwlwifi/built-in.o to 130 in drivers/net/wireless/iwlegacy/built-in.o
drivers/net/wireless/iwlegacy/built-in.o:(.data+0x0): multiple definition of `bt_coex_active'
drivers/net/wireless/iwlwifi/built-in.o:(.data+0x668): first defined here
drivers/net/wireless/iwlegacy/built-in.o:(.rodata+0x750): multiple definition of `iwl_eeprom_band_1'
drivers/net/wireless/iwlwifi/built-in.o:(.rodata+0x27d0): first defined here
drivers/net/wireless/iwlegacy/built-in.o:(.rodata+0x3f0): multiple definition of `iwl_bcast_addr'
drivers/net/wireless/iwlwifi/built-in.o:(.rodata+0x24f8): first defined here
drivers/net/wireless/iwlegacy/built-in.o:(.bss+0x3d48): multiple definition of `iwl_debug_level'
drivers/net/wireless/iwlwifi/built-in.o:(.bss+0x21950): first defined here
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

For devices supported by iwlwifi sometimes
off-channel transmissions need to be handled
by the device completely. To support this
mac80211 needs to pass the frame directly
to the driver and not through the TX path
as the driver needs the frame and channel
information at the same time.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Is still possible to schedule conn_mon_timer after disassociate from
ieee80211_sta_tx_notify() and ieee80211_offchannel_ps_disable().

Move disassociate check to ieee80211_sta_reset_conn_monitor() to cover
all these cases, and add unlikely since in most the time we call
ieee80211_sta_reset_conn_monitor() when associated.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>