Commit graph

348671 commits

Author SHA1 Message Date
Sven Eckelmann c67ba5e580 ath9k: Remove unused variables in ath_mci_cleanup
Leaving the unused variables ath_mci_cleanup causes build warnings.

Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-02-01 14:27:24 -05:00
Sven Eckelmann 1282437409 ath9k: Fix sparse __CHECK_ENDIAN__ for spectral code
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-02-01 14:27:24 -05:00
Sven Eckelmann 00b5418234 ath9k: Only remove spectral scan relay file when it was created
The relay file depends on relayfs. Trying to close this file without having
ATH9K_DEBUGFS (and therefore RELAY) activated causes build failures.

Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-02-01 14:27:24 -05:00
Sven Eckelmann ab2e2fc890 ath9k: Only add fix_rssi_inv_only when spectral code is used
The code is only used when ATH9K_DEBUGFS is activated and causes build warnings
when it is still compiled without user.

Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-02-01 14:27:24 -05:00
Sven Eckelmann bd2ffe14d4 ath9k: Only process fft samples when ATH9K_DEBUGFS is enabled
The code can only be used when ATH9k_DEBUGFS is enabled an not when ATH_DEBUG
is activated. Still enabling it would cause build failures.

Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-02-01 14:27:23 -05:00
Sven Eckelmann c672a3abb7 ath9k: Select RELAY for ATH9K_DEBUGFS
The spectral scan support activated through ATH9K_DEBUGFS depends on RELAY for
the kernel->userspace communication. Not activating RELAY causes build
failures.

The RELAY is added as select instead of depend to do it similar like
the only other user of RELAY: BLK_DEV_IO_TRACE

Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-02-01 14:27:23 -05:00
Bing Zhao 5e3175fb67 mwifiex: remove max_tx_buf_size
max_tx_buf_size is not used any more after reconfiguration of
tx buffer size has been removed.

Also add missing curr_tx_buf_size update while dumping debug info
via debugfs.

Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-02-01 14:27:23 -05:00
Bing Zhao 62749238d1 mwifiex: do not reconfigure tx buffer size in firmware while associating
It's observed that reconfiguration of tx buffer size before
association can cause data path failure in firmware after
associated. Although this is only found with PCIe cards, but
potentially it could happen with any other interfaces as well.

The tx buffer reconfiguration is not really useful in firmware.
Let's remove it for all interfaces.

Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-02-01 14:27:23 -05:00
Christian Lamparter 21fbbca337 ath9k: report A-MPDU status
The ath9k hardware reports whenever an frame was part
of an A-MPDU. MAC80211 already provides the necessary
API to pass this additional information along to
whomever needs it.

Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-02-01 14:27:22 -05:00
Xose Vazquez Perez cd435d561a wireless: rt2x00: rt2800usb add/identify ids
Devices were taken from Ralink Linux drivers:
- RT5370
0x043e, 0x7a32
0x043e, 0x7a42
0x0471, 0x2126
0x0471, 0x2180
0x0471, 0x2181
0x0471, 0x2182

Identify these ones:
0x04da, 0x23f6 in CONFIG_RT2800USB_RT53XX is a Panasonic device
0x07d1, 0x3c17 in RT2800USB_UNKNOWN is a RT3070
0x0586, 0x341a in RT2800USB_UNKNOWN is a RT3070

Cc: Ivo van Doorn <IvDoorn@gmail.com>
Cc: Gertjan van Wingerde <gwingerde@gmail.com>
Cc: Helmut Schaa <helmut.schaa@googlemail.com>
Cc: John W. Linville <linville@tuxdriver.com>
Cc: users@rt2x00.serialmonkey.com
Cc: linux-wireless@vger.kernel.org
Signed-off-by: Xose Vazquez Perez <xose.vazquez@gmail.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-02-01 14:27:22 -05:00
Stanislaw Gruszka 96ebbe8d01 iwlegacy: check for dma mapping errors
Handle pci_map_page() errors. This fixes "DMA-API: device driver failed
to check map error" warning.

Reported-by: Zdenek Kabelac <zkabelac@redhat.com>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-02-01 14:27:22 -05:00
Rafał Miłecki 58b27101e1 bcma: Xflash: reorder includes to make pr_fmt work
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-02-01 14:27:21 -05:00
Christian Lamparter 0255beda59 iwl4965: report A-MPDU status
This patch is based on "iwlwifi: report A-MPDU status".
(12bf6f45d1)

Since the firmware will give us an A-MPDU bit and
only a single PHY information packet for all the
subframes in an A-MPDU, we can easily report the
minimal A-MPDU information for radiotap.

Cc: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-02-01 14:27:21 -05:00
John W. Linville 5d38745fa8 Merge branch 'for-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next 2013-02-01 14:21:56 -05:00
Andre Guedes a3d0935649 Bluetooth: Refactor mgmt_pending_foreach
This patch does a trivial refactor in mgmt_pending_foreach function.
It replaces list_for_each_safe by list_for_each_entry_safe, simplifying
the function.

Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2013-02-01 15:50:18 -02:00
Andre Guedes 2b8a9a2e6a Bluetooth: Remove unneeded locking
This patch removes unneeded locking in hci_le_adv_report_evt. There
is no need to lock hdev before calling mgmt_device_found.

Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2013-02-01 15:50:18 -02:00
Andre Guedes 405280887f Bluetooth: Reduce critical section in sco_conn_ready
This patch reduces the critical section protected by sco_conn_lock in
sco_conn_ready function. The lock is acquired only when it is really
needed.

This patch fixes the following lockdep warning which is generated
when the host terminates a SCO connection.

Today, this warning is a false positive. There is no way those
two threads reported by lockdep are running at the same time since
hdev->workqueue (where rx_work is queued) is single-thread. However,
if somehow this behavior is changed in future, we will have a
potential deadlock.

======================================================
[ INFO: possible circular locking dependency detected ]
3.8.0-rc1+ #7 Not tainted
-------------------------------------------------------
kworker/u:1H/1018 is trying to acquire lock:
 (&(&conn->lock)->rlock){+.+...}, at: [<ffffffffa0033ba6>] sco_chan_del+0x66/0x190 [bluetooth]

but task is already holding lock:
 (slock-AF_BLUETOOTH-BTPROTO_SCO){+.+...}, at: [<ffffffffa0033d5a>] sco_conn_del+0x8a/0xe0 [bluetooth]

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #1 (slock-AF_BLUETOOTH-BTPROTO_SCO){+.+...}:
       [<ffffffff81083011>] lock_acquire+0xb1/0xe0
       [<ffffffff813efd01>] _raw_spin_lock+0x41/0x80
       [<ffffffffa003436e>] sco_connect_cfm+0xbe/0x350 [bluetooth]
       [<ffffffffa0015d6c>] hci_event_packet+0xd3c/0x29b0 [bluetooth]
       [<ffffffffa0004583>] hci_rx_work+0x133/0x870 [bluetooth]
       [<ffffffff8104d65f>] process_one_work+0x2bf/0x4f0
       [<ffffffff81050022>] worker_thread+0x2b2/0x3e0
       [<ffffffff81056021>] kthread+0xd1/0xe0
       [<ffffffff813f14bc>] ret_from_fork+0x7c/0xb0

-> #0 (&(&conn->lock)->rlock){+.+...}:
       [<ffffffff81082215>] __lock_acquire+0x1465/0x1c70
       [<ffffffff81083011>] lock_acquire+0xb1/0xe0
       [<ffffffff813efd01>] _raw_spin_lock+0x41/0x80
       [<ffffffffa0033ba6>] sco_chan_del+0x66/0x190 [bluetooth]
       [<ffffffffa0033d6d>] sco_conn_del+0x9d/0xe0 [bluetooth]
       [<ffffffffa0034653>] sco_disconn_cfm+0x53/0x60 [bluetooth]
       [<ffffffffa000fef3>] hci_disconn_complete_evt.isra.54+0x363/0x3c0 [bluetooth]
       [<ffffffffa00150f7>] hci_event_packet+0xc7/0x29b0 [bluetooth]
       [<ffffffffa0004583>] hci_rx_work+0x133/0x870 [bluetooth]
       [<ffffffff8104d65f>] process_one_work+0x2bf/0x4f0
       [<ffffffff81050022>] worker_thread+0x2b2/0x3e0
       [<ffffffff81056021>] kthread+0xd1/0xe0
       [<ffffffff813f14bc>] ret_from_fork+0x7c/0xb0

other info that might help us debug this:

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(slock-AF_BLUETOOTH-BTPROTO_SCO);
                               lock(&(&conn->lock)->rlock);
                               lock(slock-AF_BLUETOOTH-BTPROTO_SCO);
  lock(&(&conn->lock)->rlock);

 *** DEADLOCK ***

4 locks held by kworker/u:1H/1018:
 #0:  (hdev->name#2){.+.+.+}, at: [<ffffffff8104d5f8>] process_one_work+0x258/0x4f0
 #1:  ((&hdev->rx_work)){+.+.+.}, at: [<ffffffff8104d5f8>] process_one_work+0x258/0x4f0
 #2:  (&hdev->lock){+.+.+.}, at: [<ffffffffa000fbe9>] hci_disconn_complete_evt.isra.54+0x59/0x3c0 [bluetooth]
 #3:  (slock-AF_BLUETOOTH-BTPROTO_SCO){+.+...}, at: [<ffffffffa0033d5a>] sco_conn_del+0x8a/0xe0 [bluetooth]

stack backtrace:
Pid: 1018, comm: kworker/u:1H Not tainted 3.8.0-rc1+ #7
Call Trace:
 [<ffffffff813e92f9>] print_circular_bug+0x1fb/0x20c
 [<ffffffff81082215>] __lock_acquire+0x1465/0x1c70
 [<ffffffff81083011>] lock_acquire+0xb1/0xe0
 [<ffffffffa0033ba6>] ? sco_chan_del+0x66/0x190 [bluetooth]
 [<ffffffff813efd01>] _raw_spin_lock+0x41/0x80
 [<ffffffffa0033ba6>] ? sco_chan_del+0x66/0x190 [bluetooth]
 [<ffffffffa0033ba6>] sco_chan_del+0x66/0x190 [bluetooth]
 [<ffffffffa0033d6d>] sco_conn_del+0x9d/0xe0 [bluetooth]
 [<ffffffffa0034653>] sco_disconn_cfm+0x53/0x60 [bluetooth]
 [<ffffffffa000fef3>] hci_disconn_complete_evt.isra.54+0x363/0x3c0 [bluetooth]
 [<ffffffffa000fbd0>] ? hci_disconn_complete_evt.isra.54+0x40/0x3c0 [bluetooth]
 [<ffffffffa00150f7>] hci_event_packet+0xc7/0x29b0 [bluetooth]
 [<ffffffff81202e90>] ? __dynamic_pr_debug+0x80/0x90
 [<ffffffff8133ff7d>] ? kfree_skb+0x2d/0x40
 [<ffffffffa0021644>] ? hci_send_to_monitor+0x1a4/0x1c0 [bluetooth]
 [<ffffffffa0004583>] hci_rx_work+0x133/0x870 [bluetooth]
 [<ffffffff8104d5f8>] ? process_one_work+0x258/0x4f0
 [<ffffffff8104d65f>] process_one_work+0x2bf/0x4f0
 [<ffffffff8104d5f8>] ? process_one_work+0x258/0x4f0
 [<ffffffff8104fdc1>] ? worker_thread+0x51/0x3e0
 [<ffffffffa0004450>] ? hci_tx_work+0x800/0x800 [bluetooth]
 [<ffffffff81050022>] worker_thread+0x2b2/0x3e0
 [<ffffffff8104fd70>] ? busy_worker_rebind_fn+0x100/0x100
 [<ffffffff81056021>] kthread+0xd1/0xe0
 [<ffffffff81055f50>] ? flush_kthread_worker+0xc0/0xc0
 [<ffffffff813f14bc>] ret_from_fork+0x7c/0xb0
 [<ffffffff81055f50>] ? flush_kthread_worker+0xc0/0xc0

Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2013-02-01 15:50:18 -02:00
Johan Hedberg 3810285cf8 Bluetooth: Increment Management interface revision
This patch increments the management interface revision due to the
various fixes, improvements and other changes that have gone in lately.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2013-02-01 15:50:18 -02:00
Johan Hedberg f0ff92fbfa Bluetooth: Fix link security setting when powering on
If a controller is powered on while the HCI_AUTO_OFF flag is set the
link security setting (HCI_LINK_SECURITY) might not be in sync with the
actual state of the controller (HCI_AUTH). This patch fixes the issue by
checking for inequality between the intended and actual settings and
sends a HCI_Write_Auth_Enable command if necessary.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2013-02-01 15:50:18 -02:00
Johan Hedberg c00d575bd5 Bluetooth: Add support for 128-bit UUIDs in EIR data
This patch adds the necessary code for encoding a list of 128-bit UUIDs
into the EIR data.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2013-02-01 15:50:17 -02:00
Johan Hedberg cdf1963f7b Bluetooth: Add support for 32-bit UUIDs in EIR data
This patch adds the necessary code for inserting a list of 32-bit UUIDs
into the EIR data.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2013-02-01 15:50:17 -02:00
Johan Hedberg 213202edc9 Bluetooth: Refactor UUID-16 list generation into its own function
We will need to create three separate UUID lists in the EIR data (for
16, 32 and 128 bit UUIDs) so the code is easier to follow if each list
is generated in their own function.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2013-02-01 15:50:17 -02:00
Johan Hedberg 892bbc5794 Bluetooth: Remove useless eir_len variable from EIR creation
The amount of data encoded so far in the create_eir() function can be
calculated simply through the difference between the data and ptr
pointer variables. The eir_len variable then becomes essentially
useless.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2013-02-01 15:50:17 -02:00
Johan Hedberg a10f27cf42 Bluetooth: Simplify UUID16 list generation for EIR
There's no need to use two separate loops to generate a UUID list for
the EIR data. This patch merges the two loops previously used for the
16-bit UUID list generation into a single loop, thus simplifying the
code a great deal.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2013-02-01 15:50:17 -02:00
Johan Hedberg 056341c8cb Bluetooth: Simplify UUID removal code
The UUID removal code can be simplified by using
list_for_each_entry_safe instead of list_for_each_safe.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2013-02-01 15:50:17 -02:00
Johan Hedberg 83be8eca2e Bluetooth: Keep track of UUID type upon addition
The primary purpose of the UUIDs is to enable generation of EIR and AD
data. In these data formats the UUIDs are split into separate fields
based on whether they're 16, 32 or 128 bit UUIDs. To make the generation
of these data fields simpler this patch adds a type member to the
bt_uuid struct and assigns a value to it as soon as the UUID is added to
the kernel. This way the type doesn't need to be calculated each time
the UUID list is later iterated.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2013-02-01 15:50:17 -02:00
Johan Hedberg 4821002ce2 Bluetooth: Simplify UUIDs clearing code
The code for clearing the UUIDs list can be simplified by using
list_for_each_entry_safe instead of list_for_each_safe.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2013-02-01 15:50:16 -02:00
Johan Hedberg de66aa6305 Bluetooth: Store UUIDs in the same order that they were added
We should be encoding UUIDs to the EIR data in the same order that they
were added to the kernel, i.e. each UUID should be added to the end of
the UUIDs list. This patch fixes the issue by using list_add_tail
instead of list_add for storing the UUIDs.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2013-02-01 15:50:16 -02:00
Lilach Edelstein e56b04efc1 iwlwifi: move register access lock into transport
Move the reg_lock that protects HW register access
into the transport implementation. Locking is no
longer exposed, but handled internally in grab and
release NIC access. This simplifies the users.

Signed-off-by: Lilach Edelstein <lilach.edelstein@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-01 11:27:22 +01:00
Lilach Edelstein e139dc4aeb iwlwifi: add iwl_set_bits_mask to transport API
Express iwl_set_bit() and iwl_clear_bit() through iwl_set_bits_mask()
and add the latter to the transport's API in order to allow different
implementation for different transport types in the future.

Signed-off-by: Lilach Edelstein <lilach.edelstein@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-01 11:27:22 +01:00
Johannes Berg 6690c01d16 iwlwifi: lower BT coex aggregation message severity
As the rate scaling algorithm will attempt to enable
aggregation over and over again, the message will
flood the log if there is, for example, Bluetooth
streaming music. Make it a debug messages instead of
printing it all the time.

Reported-by: Jan-Michael Brummer <jan.brummer@tabos.org>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-01 11:27:21 +01:00
Johannes Berg 8ca151b568 iwlwifi: add the MVM driver
Newer firmware revisions have a completely new
firmware API. This is the new driver for this
new API.

I've listed the people who directly contributed
code, but many others from various teams have
contributed in other ways.

Cc: Alexander Bondar <alexander.bondar@intel.com>
Cc: Amit Beka <amit.beka@intel.com>
Cc: Amnon Paz <amnonx.paz@intel.com>
Cc: Assaf Krauss <assaf.krauss@intel.com>
Cc: David Spinadel <david.spinadel@intel.com>
Cc: Dor Shaish <dor.shaish@intel.com>
Cc: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Cc: Eytan Lifshitz <eytan.lifshitz@intel.com>
Cc: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-01 11:27:15 +01:00
Stanislaw Gruszka 3f892b61a8 mac80211: improve latency and throughput while software scanning
Patch vastly improve latency while scanning. Slight throughput
improvements were observed as well. Is intended for improve performance
of voice and video applications, when scan is periodically requested by
user space (i.e. default NetworkManager behaviour).

Patch remove latency requirement based on PM_QOS_NETWORK_LATENCY,
this value is 2000 seconds by default (i.e. approximately 0.5 hour !?!).

Also remove listen interval requirement, which based on beaconing and
depending on BSS parameters. It can make we stay off-channel for a
second or more.

Instead try to offer the best latency that we could, i.e. be off-channel
no longer than PASSIVE channel scan time: 125 ms. That mean we will
scan two ACTIVE channels and go back to on-channel, and one PASSIVE
channel, and go back to on-channel.

Patch also decrease PASSIVE channel scan time to about 110 ms.

As drawback patch increase overall scan time. On my tests, when scanning
both 2GHz and 5GHz bands, scanning time increase from 5 seconds up to 10
seconds. Since that increase happen only when we are associated, I think
it can be acceptable. If eventually better scan time is needed for
situations when we lose signal and quickly need to decide to which AP
roam, additional scan flag or parameter can be introduced.

I tested patch by doing:

while true; do iw dev wlan0 scan; sleep 3; done > /dev/null

and

ping -i0.2 -c 1000 HOST

on remote and local machine, results are as below:

* Ping from local periodically scanning machine to AP:
Unpatched: rtt min/avg/max/mdev = 0.928/24.946/182.135/36.873 ms
Patched:   rtt min/avg/max/mdev = 0.928/19.678/150.845/33.130 ms

* Ping from remote machine to periodically scanning machine:
Unpatched: rtt min/avg/max/mdev = 1.637/120.683/709.139/164.337 ms
Patched:   rtt min/avg/max/mdev = 1.807/26.893/201.435/40.284 ms

Throughput measured by scp show following results.

* Upload to periodically scanning machine:
Unpatched: 3.9MB/s   03:15
Patched:   4.3MB/s   02:58

* Download from periodically scanning machine:
Unpatched: 5.5MB/s   02:17
Patched:   6.2MB/s   02:02

Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-01-31 16:45:05 +01:00
Johannes Berg 1672c0e319 mac80211: start auth/assoc timeout on frame status
When sending authentication/association frames they
might take a bit of time to go out because we may
have to synchronise with the AP, in particular in
the case where it's really a P2P GO. In this case
the 200ms fixed timeout could potentially be too
short if the beacon interval is relatively large.

For drivers that report TX status we can do better.
Instead of starting the timeout directly, start it
only when the frame status arrives. Since then the
frame was out on the air, we can wait shorter (the
typical response time is supposed to be 30ms, wait
100ms.) Also, if the frame failed to be transmitted
try again right away instead of waiting.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-01-31 14:28:43 +01:00
Johannes Berg 3ff9a827c6 cfg80211: remove free_priv BSS API
Now that mac80211 no longer uses this API, remove
it completely. If anyone needs it again, we can
revert this patch of course, but mac80211 was the
only user right now.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-01-31 14:07:30 +01:00
Johannes Berg 0fe20add2c mac80211: remove unused mesh data from bss
These pointers/values are never used, remove them.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-01-31 14:07:14 +01:00
Johannes Berg ce9877c0cd mac80211: remove last_probe_resp from bss
We track this, but never use it, so we can
just remove it.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-01-31 14:06:32 +01:00
Emmanuel Grumbach c65dd1477b mac80211: inform the driver about update of dtim_period
Currently, when the driver requires the DTIM period,
mac80211 will wait to hear a beacon before association.
This behavior is suboptimal since some drivers may be
able to deal with knowing the DTIM period after the
association, if they get it at all.

To address this, notify the drivers with bss_info_changed
with the new BSS_CHANGED_DTIM_PERIOD flag when the DTIM
becomes known. This might be when changing to associated,
or later when the entire association was done with only
probe response information.

Rename the hardware flag for the current behaviour to
IEEE80211_HW_NEED_DTIM_BEFORE_ASSOC to more accurately
reflect its behaviour. IEEE80211_HW_NEED_DTIM_PERIOD is
no longer accurate as all drivers get the DTIM period
now, just not before association.

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-01-31 14:05:38 +01:00
Johannes Berg fdcb786930 mac80211: remove assoc data "sent_assoc"
The field is never used, so remove it.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-01-31 14:05:33 +01:00
Johannes Berg cd8f7cb4e6 cfg80211/mac80211: support reporting wakeup reason
When waking up from WoWLAN, it is useful to know
what triggered the wakeup. Support reporting the
wakeup reason(s) in cfg80211 (and a pass-through
in mac80211) to allow userspace to know.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-01-31 14:00:21 +01:00
Johannes Berg b1e1adfa7d iwlwifi: add NVM and PHY DB code for new MVM driver
The new MVM (multi-virtual MAC) firmware driver
requires NVM (non-volatile memory) parsing code
and some PHY information database code. Add this
separately.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-01-30 21:41:32 +01:00
Johannes Berg aa2b177083 iwlwifi: fix calibration parser
The firmware TLV for calibration data isn't
really a u64, but two u32 values. Define a
struct for that and change the parser.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-01-30 21:41:29 +01:00
Johannes Berg 4a4ee1010d iwlwifi: clean up CMD_MODE enum
Just format the enum better.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-01-30 21:41:26 +01:00
Johannes Berg 99cd471423 iwlwifi: add 7000 series device configuration
Add configuration and detection code for the new
7000 series, with 7260 and 3160 devices.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-01-30 21:41:24 +01:00
Johannes Berg de8d7a5380 Merge remote-tracking branch 'wireless-next/master' into iwlwifi-next 2013-01-30 21:39:54 +01:00
Vladimir Kondratiev c331997b6c wil6210: fix wil_vring_init_tx status
In case vring setup with the firmware failed,
success status was returned. fix it.

Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-01-30 15:07:19 -05:00
Vladimir Kondratiev 2acb4220b2 wil6210: Never delete Rx chain with firmware
Firmware crash on attempt to delete Rx chain.
Driver part of Rx chain removed only in preparation for the target reset;
as reset is the only flow that removes Rx chain in the firmware.

Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-01-30 15:07:19 -05:00
Vladimir Kondratiev afda8bb50b wil6210: checkpatch warnings
Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-01-30 15:07:18 -05:00
Vladimir Kondratiev 7743882d6f wil6210: fix checkpatch CamelCase warnings
Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-01-30 15:07:17 -05:00
Vladimir Kondratiev e08b5906cc wil6210: Reorder reset preparation sequence
Disable interrupts first to prevent spurious WMI events arrival

Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-01-30 15:07:16 -05:00