mwifiex: 11n specific configuration for transmit

Currently device is not able to transmit in 40MHz in spite of
enabling 40MHz support in HTCapInfo IE in assoc req, because
11n specific FW capabilities for transmission are not initialized.
This patch adds code to initilize these capabilities.

Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: Kiran Divekar <dkiran@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

iwlagn: remove iwlagn_hcmd_utils structure and call directly

Not needed since the driver split.  Move single use routines to
calling location and keep static where possible.

Signed-off-by: Don Fry <donald.h.fry@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

iwlagn: separate and enhance the fixed rate from

For testing purpose, we need better control of msc from user application.
Separate the fixed_rate between debugfs and testmode and enforce it.

Signed-off-by: Kenny Hsu <kenny.hsu@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

iwlagn: block regular host commands if driver don't own uCode

The only host command allow to send to uCode is the one initiated from
testmode if testmode is the owner of uCode

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

iwlagn: allow application own the uCode operation

Since we open the door to allow application control the device behavior through
testmode, add command to allow application request the ownership of the uCode

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

iwlagn: add CMD_ON_DEMAND flag for host command from testmode

For all the hist command request from testmode, set the CMD_ON_DEMAND flag.
this flag will be used later to control the uCode behavior

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

iwlagn: declare static

Declare iwl_mac_rssi_callback as "static"

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

iwlagn: Enable/disable PS poll based on RSSI and BT coex traffic state

WiFi throughput drops drastically when BT is turned on, BT and WiFi
are simultaneously transmitting/receiving traffic. This is particularly true
when BT has higher priority over WiFi, and hence the device defers TX frames.
The AP assumes that the channel is bad and reduces the data rate, implying
longer airtime, which exacerbates the problem further, resulting ultimately
in what is popularly called the "death-spiral" phenomenon. The use of PS-poll
in such scenarios guarantees a low but consistent throughput.

Since the death-spiral phenomenon is observed only when the RSSI is low, use
PS-poll only when RSSI is low and disable when high, with a known hysterisis.

This feature specifies the high and low thresholds and implements the
callbacks registered with mac80211, which will be called when threshold events
occur.

iwlwifi: dynamic pspoll: optimize rssi monitor code

Signed-off-by: Meenakshi Venkataraman <meenakshi.venkataraman@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

mac80211: add driver RSSI threshold events

mac80211 maintains a running average of the RSSI when a STA
is associated to an AP. Report threshold events to any driver
that has registered callbacks for getting RSSI measurements.

Implement callbacks in mac80211 so that driver can set thresholds.
Add callbacks in mac80211 which is invoked when an RSSI threshold
event occurs.

mac80211: add tracing to rssi_reports api and remove extraneous fn argument
mac80211: scale up rssi thresholds from driver by 16 before storing

Signed-off-by: Meenakshi Venkataraman <meenakshi.venkataraman@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

iwlagn: use bt handler for 2030 and 135 series devices

For bt combo devices, need to use bt enabled handlers and functions

Reported-by: Don Fry <donald.h.fry@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

iwlagn: remove double level temperature indirect call

No need to do double level indirect call after driver split
no functional changes

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

iwlagn: remove indirection for eeprom_query_addr

Not needed since the driver split.  Eliminate redundant routine.

Signed-off-by: Don Fry <donald.h.fry@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

iwlagn: remove the indirection for iwl_apm_init

Not needed since the driver split.

Signed-off-by: Don Fry <donald.h.fry@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

iwlagn: remove the indirection for update_chain_flags

Not needed since the driver split.

Signed-off-by: Don Fry <donald.h.fry@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

iwlagn: provide heplers to access the transport ops

This removes the for priv->trans.ops->...

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

iwlagn: remove the indirection for the dma channel num

Not needed since the driver split.

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

iwlagn: consolidate the API that sends host commands and move to transport

Now, there are only two functions to send a host command:
* send_cmd that receives a iwl_host_cmd
* send_cmd_pdu that builds the iwl_host_cmd itself and received flags

The flags CMD_ASYNC / CMD_SYNC / CMD_WANT_SKB are not changed by the API
functions.

Kill the unused flags CMD_SIZE_NORMAL / CMD_NO_SKB on the way.

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

iwlagn: remove code duplication

Code duplication was needed during the move, not needed any more.

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

iwlagn: add an API for TX stop

Tx stop moves to transport layer.

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

iwlagn: add an API for RX stop

Rx stop moves to transport layer.

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

iwlagn: add an API to free the TX context

Tx free functions move to the transport layer. Unify the functions that deal with tx queues and cmd queue.

Since the CMD queue is not fully allocated, but uses the q->n_bd / q->window trick, the release flow of TX queue and CMD queue was different.
iwlagn_txq_free_tfd receives now the index of the TFD to be freed, which allows to unify the release flow for all the queues.

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

iwlagn: remove the CMD_MAPPED flag

It is uneeded since Johannes removed the HUGE flag. The DMA mapping is always held in the same index as the command.

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Merge branch 'master' of /linux/kernel/git/padovan/bluetooth-next-2.6

Conflicts:
net/bluetooth/l2cap_core.c

Merge branch 'master' of git://git./linux/kernel/git/linville/wireless-2.6

Conflicts:
drivers/net/wireless/ath/ath5k/sysfs.c
net/bluetooth/l2cap_core.c
net/mac80211/wpa.c

Bluetooth: Fixes l2cap "command reject" reply according to spec

There can 3 reasons for the "command reject" reply produced
by the stack. Each such reply should be accompanied by the
relevand data ( as defined in spec. ). Currently there is one
instance of "command reject" reply with reason "invalid cid"
wich is fixed. Also, added clean-up definitions related to the
"command reject" replies.

Signed-off-by: Ilia Kolomisnky <iliak@ti.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>

Bluetooth: Add support for returning the encryption key size

This will be useful when userspace wants to restrict some kinds of
operations based on the length of the key size used to encrypt the
link.

Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>

Bluetooth: Add support for storing the key size

In some cases it will be useful having the key size used for
encrypting the link. For example, some profiles may restrict
some operations depending on the key length.

The key size is stored in the key that is passed to userspace
using the pin_length field in the key structure.

For now this field is only valid for LE controllers. 3.0+HS
controllers define the Read Encryption Key Size command, this
field is intended for storing the value returned by that
command.

Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>

Bluetooth: Add support for communicating keys with userspace

As the key format has changed to something that has a dynamic size,
the way that keys are received and sent must be changed.

The structure fields order is changed to make the parsing of the
information received from the Management Interface easier.

Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>

Bluetooth: Remove unused field in hci_conn

Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>

Bluetooth: Use the stored LTK for restabilishing security

Now that it's possible that the exchanged key is present in
the link key list, we may be able to estabilish security with
an already existing key, without need to perform any SMP
procedure.

Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>

Bluetooth: Use the link key list to temporarily store the STK

With this we can use only one place to store all keys, without
need to use a field in the connection structure for this
purpose.

Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>

Bluetooth: Add support for storing the LTK

Now when the LTK is received from the remote or generated it is stored,
so it can later be used.

Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>

Bluetooth: Fix SM pairing parameters negotiation

Before implementing SM key distribution, the pairing features
exchange must be better negotiated, taking into account some
features of the host and connection requirements.

If we are in the "not pairable" state, it makes no sense to
exchange any key. This allows for simplification of the key
negociation method.

Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>

Bluetooth: Reject an encryption request when the key isn't found

Now that we have methods to finding keys by its parameters we can
reject an encryption request if the key isn't found.

Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>

Bluetooth: Add functions to manipulate the link key list for SMP

As the LTK (the new type of key being handled now) has more data
associated with it, we need to store this extra data and retrieve
the keys based on that data.

Methods for searching for a key and for adding a new LTK are
introduced here.

Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>

Bluetooth: Add new structures for supporting SM key distribution

We need these changes because SMP keys may have more information
associated with them, for example, in the LTK case, it has an
encrypted diversifier (ediv) and a random number (rand).

Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>

Bluetooth: Add support for SMP phase 3 (key distribution)

This adds support for generating and distributing all the keys
specified in the third phase of SMP.

This will make possible to re-establish secure connections, resolve
private addresses and sign commands.

For now, the values generated are random.

Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>

ath9k_htc: Inform stack about tx ack status

Recent firmware changes report tx ack status properly
to driver. Hence updating ath9k_htc driver capabilities.

Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k_hw: Remove read-only registers from AR9003 intervals

This patch removes read only registers that cause invalid
address access and also updates index for measurement filter
calibration window size.

Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k_hw: Disable power detector calibration for AR9003

The power detector calibration is disabled because this block
doesn't exist in AR9003 based chips and also parallel
calibration is enabled otherwise the calibration will never stop.

Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k_hw: Update AR9003 interval to improve 5G Tx EVM

The number of temperature reading samples to average
during a Tx packet is decreased to 1 from 2 to improve
5G Tx EVM with chain 0-only mode.

Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

cfg80211: return -ENOENT when stopping sched_scan while not running

If we try to stop a scheduled scan while it is not running, we should
return -ENOENT instead of simply ignoring the command and returning
success.  This is more consistent with other parts of the code.

Reported-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Luciano Coelho <coelho@ti.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k_hw: Disable PAPRD based on paprd_ht20_mask for 5GHz

Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

mwifiex: 4-byte alignment in mwifiex_process_sta_txpd()

In XMIT path, the skb that we get from the kernel itself is not
aligned with 4-byte boundary on some embedded platforms.

Had it not been the presence of tx_pkt_offset field in txpd, 4 byte
memory alignment was not possible without memmove of entire skb.
And that would have increased MIPS instead of reducing.

With this patch few memory cycles can be saved while fetching
interface header and txpd structure because of 4 bytes memory
alignment.

Reported-by: Philip Rakity <prakity@marvell.com>
Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com>
Tested-by: Philip Rakity <prakity@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

mwifiex: fix minor issue in debugfs command 'info'

Debugfs command 'info' shows wrong interface type. The regression
occurred due to commit eecd8250e (mwifiex: remove MWIFIEX_BSS_MODE_
macros) in which we replaced MWIFIEX_BSS_MODE_* macros by
NL80211_IFTYPE_*, for example,

MWIFIEX_BSS_MODE_IBSS (2) --> NL80211_IFTYPE_ADHOC (1)

The issue is fixed by swapping static character array used to
display interface type information.

Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

mwifiex: fix regression in WEP security mode

Htcapinfo is unnecessarily sent in assoc request in WEP security due
to a regression introduced by commit 2be50b8df53 (mwifiex: remove
redundant encryption_mode mapping).
The issue is fixed in this patch.

Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath5k: read sc->imask with sc->irqlock held

Signed-off-by: Pavel Roskin <proski@gnu.org>
sc->imask may change if ath5k_set_current_imask() races against itself.
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath5k: use kstrtoint() to parse numbers coming from sysfs

Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath5k: fix formatting errors found by checkpatch.pl

Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath5k: fix misplaced or extraneous braces found by checkpatch.pl

Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath5k: use parentheses around macro definitions

Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath5k: don't use volatile, it's not needed

Signed-off-by: Pavel Roskin <proski@gnu.org>
The reg variable is only used by __raw_writel() and __raw_readl(), which
should guarantee memory access in the right order.
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath5k: use more readable way to clear MAC address

Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath5k: use DEFINE_PCI_DEVICE_TABLE in led.c, mark users with __devinit

Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath5k: use KERN_WARNING in ATH5K_PRINTF

Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath5k: remove unneeded parentheses after return

Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath5k: replace spaces with tabs as suggested by checkpatch.pl

Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath5k: remove PRIV_ENTRY and PRIV_ASSIGN macros, they obfuscate the code

Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

carl9170: Implement tx_frames_pending mac80211 callback function

Implementing this callback function will cause mac80211 refrain from
going to powersave state when there are still untransmitted TX frames
in the queues.

Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

net/b43: don't return IRQ_HANDLED if nothing was done

Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

b43: HT-PHY: define dummy TX power functions

Without them we get Oops with NULL pointer

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

mac80211: Restart STA timers only on associated state

A panic was observed when the device is failed to resume properly,
and there are no running interfaces. ieee80211_reconfig tries
to restart STA timers on unassociated state.

Cc: stable@kernel.org
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k_htc: do not configure filter before driver is started

Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

b43: LCN-PHY: include new PHY in common code

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

b43: define firmwares for HT and LCN PHYs

We were uploading different firmwares to the hardware until finding
responding one.

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

mac80211: allow driver to generate P1K for IV32

In order to support pre-populating the P1K cache in
iwlwifi hardware for WoWLAN, we need to calculate
the P1K for the current IV32. Allow drivers to get
the P1K for any given IV32 instead of for a given
packet, but keep the packet-based version around as
an inline.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

mac80211: allow drivers to access key sequence counter

In order to implement GTK rekeying, the device needs
to be able to encrypt frames with the right PN/IV and
check the PN/IV in RX frames. To be able to tell it
about all those counters, we need to be able to get
them from mac80211, this adds the required API.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

mac80211: simplify RX PN/IV handling

The current rx->queue value is slightly confusing.
It is set to 16 on non-QoS frames, including data,
and then used for sequence number and PN/IV checks.
Until recently, we had a TKIP IV checking bug that
had been introduced in 2008 to fix a seqno issue.
Before that, we always used TID 0 for checking the
PN or IV on non-QoS packets.

Go back to the old status for PN/IV checks using
the TID 0 counter for non-QoS by splitting up the
rx->queue value into "seqno_idx" and "security_idx"
in order to avoid confusion in the future. They
each have special rules on the value used for non-
QoS data frames.

Since the handling is now unified, also revert the
special TKIP handling from my patch
"mac80211: fix TKIP replay vulnerability".

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

b43: LCN-PHY add place for new PHY support

LCN-PHY was found in 14e4:4727 card. It uses LCN/1 and 0x2064/1 radio.

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

mac80211: use AES_BLOCK_SIZE

mac80211 has a defnition of AES_BLOCK_SIZE and
multiple definitions of AES_BLOCK_LEN. Remove
them all and use crypto/aes.h.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

b43: read radio ID on new cores

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

b43: use radio ID reading code to older cores only

Newer ones need separated way

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

b43: select BLOCKIO for BCMA

We want PIO as fallback for BCMA as well.

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

b43: change selecting ucode for newer cores

Older cores had unique PHY. This is not true anymore for newer ones.
For example core rev 16 can be LP, SSLPN or N (PHY).

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

b43: bus: add helpers for getting/setting wldev from/in bus core

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

b43: handle BCMA in bus switches

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

b43: use switches for SSB specific code

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

mac80211: fix CMAC races

Just like TKIP and CCMP, CMAC has the PN race.
It might not actually be possible to hit it now
since there aren't multiple ACs for management
frames, but fix it anyway.

Also move scratch buffers onto the stack.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

mac80211: fix CCMP races

Since we can process multiple packets at the
same time for different ACs, but the PN is
allocated from a single counter, we need to
use an atomic value there. Use atomic64_t to
make this cheaper on 64-bit platforms, other
platforms will support this through software
emulation, see lib/atomic64.c.

We also need to use an on-stack scratch buf
so that multiple packets won't corrupt each
others scratch buffers.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

mac80211: fix TKIP races, make API easier to use

Our current TKIP code races against itself on TX
since we can process multiple packets at the same
time on different ACs, but they all share the TX
context for TKIP. This can lead to bad IVs etc.

Also, the crypto offload helper code just obtains
the P1K/P2K from the cache, and can update it as
well, but there's no guarantee that packets are
really processed in order.

To fix these issues, first introduce a spinlock
that will protect the IV16/IV32 values in the TX
context. This first step makes sure that we don't
assign the same IV multiple times or get confused
in other ways.

Secondly, change the way the P1K cache works. I
add a field "p1k_iv32" that stores the value of
the IV32 when the P1K was last recomputed, and
if different from the last time, then a new P1K
is recomputed. This can cause the P1K computation
to flip back and forth if packets are processed
out of order. All this also happens under the new
spinlock.

Finally, because there are argument differences,
split up the ieee80211_get_tkip_key() API into
ieee80211_get_tkip_p1k() and ieee80211_get_tkip_p2k()
and give them the correct arguments.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

b43: implement BCMA bus ops

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

b43: make b43_wireless_init bus generic

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

Merge branch 'for-linville' of git://git./linux/kernel/git/luca/wl12xx

wl12xx: start/stop queues according to global per-AC counters

Split tx_queue_count to count per-AC skb's queued, instead of relying on
the skb-queue len. The skb queues used were only valid in STA-mode, as
AP-mode uses per-link queues.

This fixes a major regression in AP-mode, caused by the patch
"wl12xx: implement Tx watermarks per AC". With that patch applied, we
effectively had no regulation of Tx queues in AP-mode. Therefore a
sustained high rate of Tx could cause exhaustion of the skb memory pool.

Signed-off-by: Arik Nemtsov <arik@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>

Bluetooth: Remove L2CAP busy queue

The ERTM receive buffer is now handled in a way that does not require
the busy queue and the associated polling code.

Signed-off-by: Mat Martineau <mathewm@codeaurora.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>

Bluetooth: Use event-driven approach for handling ERTM receive buffer

This change moves most L2CAP ERTM receive buffer handling out of the
L2CAP core and in to the socket code.  It's up to the higher layer
(the socket code, in this case) to tell the core when its buffer is
full or has space available.  The recv op should always accept
incoming ERTM data or else the connection will go down.

Within the socket layer, an skb that does not fit in the socket
receive buffer will be temporarily stored.  When the socket is read
from, that skb will be placed in the receive buffer if possible.  Once
adequate buffer space becomes available, the L2CAP core is informed
and the ERTM local busy state is cleared.

Receive buffer management for non-ERTM modes is unchanged.

Signed-off-by: Mat Martineau <mathewm@codeaurora.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>

Bluetooth: Move code for ERTM local busy state to separate functions

The local busy state is entered and exited based on buffer status in
the socket layer (or other upper layer).  This change is in
preparation for general buffer status reports from the socket layer,
which will then be used to change the local busy status.

Signed-off-by: Mat Martineau <mathewm@codeaurora.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>

Bluetooth: Fix potential deadlock in mgmt

All threads running in process context should disable local bottom
halve before locking hdev->lock.

This patch fix the following message generated when Bluetooh module
is loaded with enable_mgmt=y (CONFIG_PROVE_LOCKING enabled).

[  107.880781] =================================
[  107.881631] [ INFO: inconsistent lock state ]
[  107.881631] 2.6.39+ #1
[  107.881631] ---------------------------------
[  107.881631] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
[  107.881631] rcuc0/7 [HC0[0]:SC1[3]:HE1:SE0] takes:
[  107.881631]  (&(&hdev->lock)->rlock){+.?...}, at: [<ffffffffa0012c8d>] mgmt_set_local_name_complete+0x84/0x10b [bluetooth]
[  107.881631] {SOFTIRQ-ON-W} state was registered at:
[  107.881631]   [<ffffffff8105188b>] __lock_acquire+0x347/0xd52
[  107.881631]   [<ffffffff810526ac>] lock_acquire+0x8a/0xa7
[  107.881631]   [<ffffffff812b3758>] _raw_spin_lock+0x2c/0x3b
[  107.881631]   [<ffffffffa0011cc2>] mgmt_control+0xd4d/0x175b [bluetooth]
[  107.881631]   [<ffffffffa0013275>] hci_sock_sendmsg+0x97/0x293 [bluetooth]
[  107.881631]   [<ffffffff8121940c>] sock_aio_write+0x126/0x13a
[  107.881631]   [<ffffffff810a35fa>] do_sync_write+0xba/0xfa
[  107.881631]   [<ffffffff810a3beb>] vfs_write+0xaa/0xca
[  107.881631]   [<ffffffff810a3d80>] sys_write+0x45/0x69
[  107.881631]   [<ffffffff812b4892>] system_call_fastpath+0x16/0x1b
[  107.881631] irq event stamp: 2100876
[  107.881631] hardirqs last  enabled at (2100876): [<ffffffff812b40d4>] restore_args+0x0/0x30
[  107.881631] hardirqs last disabled at (2100875): [<ffffffff812b3f6a>] save_args+0x6a/0x70
[  107.881631] softirqs last  enabled at (2100862): [<ffffffff8106a805>] rcu_cpu_kthread+0x2b5/0x2e2
[  107.881631] softirqs last disabled at (2100863): [<ffffffff812b56bc>] call_softirq+0x1c/0x26
[  107.881631]
[  107.881631] other info that might help us debug this:
[  107.881631]  Possible unsafe locking scenario:
[  107.881631]
[  107.881631]        CPU0
[  107.881631]        ----
[  107.881631]   lock(&(&hdev->lock)->rlock);
[  107.881631]   <Interrupt>
[  107.881631]     lock(&(&hdev->lock)->rlock);
[  107.881631]
[  107.881631]  *** DEADLOCK ***
[  107.881631]
[  107.881631] 1 lock held by rcuc0/7:
[  107.881631]  #0:  (hci_task_lock){++.-..}, at: [<ffffffffa0008353>] hci_rx_task+0x49/0x2f3 [bluetooth]
[  107.881631]
[  107.881631] stack backtrace:
[  107.881631] Pid: 7, comm: rcuc0 Not tainted 2.6.39+ #1
[  107.881631] Call Trace:
[  107.881631]  <IRQ>  [<ffffffff812ae901>] print_usage_bug+0x1e7/0x1f8
[  107.881631]  [<ffffffff8100a796>] ? save_stack_trace+0x27/0x44
[  107.881631]  [<ffffffff8104fc3f>] ? print_irq_inversion_bug.part.26+0x19a/0x19a
[  107.881631]  [<ffffffff810504bb>] mark_lock+0x106/0x258
[  107.881631]  [<ffffffff81051817>] __lock_acquire+0x2d3/0xd52
[  107.881631]  [<ffffffff8102be73>] ? vprintk+0x3ab/0x3d7
[  107.881631]  [<ffffffff810526ac>] lock_acquire+0x8a/0xa7
[  107.881631]  [<ffffffffa0012c8d>] ? mgmt_set_local_name_complete+0x84/0x10b [bluetooth]
[  107.881631]  [<ffffffff81052615>] ? lock_release+0x16c/0x179
[  107.881631]  [<ffffffff812b3952>] _raw_spin_lock_bh+0x31/0x40
[  107.881631]  [<ffffffffa0012c8d>] ? mgmt_set_local_name_complete+0x84/0x10b [bluetooth]
[  107.881631]  [<ffffffffa0012c8d>] mgmt_set_local_name_complete+0x84/0x10b [bluetooth]
[  107.881631]  [<ffffffffa000d3fe>] hci_event_packet+0x122b/0x3e12 [bluetooth]
[  107.881631]  [<ffffffff81050658>] ? mark_held_locks+0x4b/0x6d
[  107.881631]  [<ffffffff812b3cff>] ? _raw_spin_unlock_irqrestore+0x40/0x4d
[  107.881631]  [<ffffffff810507b9>] ? trace_hardirqs_on_caller+0x13f/0x172
[  107.881631]  [<ffffffff812b3d07>] ? _raw_spin_unlock_irqrestore+0x48/0x4d
[  107.881631]  [<ffffffffa00083d2>] hci_rx_task+0xc8/0x2f3 [bluetooth]
[  107.881631]  [<ffffffff8102f836>] ? __local_bh_enable+0x90/0xa4
[  107.881631]  [<ffffffff8102f5a9>] tasklet_action+0x87/0xe6
[  107.881631]  [<ffffffff8102fa11>] __do_softirq+0x9f/0x13f
[  107.881631]  [<ffffffff812b56bc>] call_softirq+0x1c/0x26
[  107.881631]  <EOI>  [<ffffffff810033b8>] ? do_softirq+0x46/0x9a
[  107.881631]  [<ffffffff8106a805>] ? rcu_cpu_kthread+0x2b5/0x2e2
[  107.881631]  [<ffffffff8102f906>] _local_bh_enable_ip+0xac/0xc9
[  107.881631]  [<ffffffff8102f93b>] local_bh_enable+0xd/0xf
[  107.881631]  [<ffffffff8106a805>] rcu_cpu_kthread+0x2b5/0x2e2
[  107.881631]  [<ffffffff81041586>] ? __init_waitqueue_head+0x46/0x46
[  107.881631]  [<ffffffff8106a550>] ? rcu_yield.constprop.42+0x98/0x98
[  107.881631]  [<ffffffff81040f0a>] kthread+0x7f/0x87
[  107.881631]  [<ffffffff812b55c4>] kernel_thread_helper+0x4/0x10
[  107.881631]  [<ffffffff812b40d4>] ? retint_restore_args+0x13/0x13
[  107.881631]  [<ffffffff81040e8b>] ? __init_kthread_worker+0x53/0x53
[  107.881631]  [<ffffffff812b55c0>] ? gs_change+0x13/0x13

Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>

Bluetooth: Fix potential deadlock in hci_core

Since hdev->lock may be acquired by threads runnning in interrupt
context, all threads running in process context should disable
local bottom halve before locking hdev->lock. This can be done by
using hci_dev_lock_bh macro.

This way, we avoid potencial deadlocks like this one reported by
CONFIG_PROVE_LOCKING=y.

[  304.788780] =================================
[  304.789686] [ INFO: inconsistent lock state ]
[  304.789686] 2.6.39+ #1
[  304.789686] ---------------------------------
[  304.789686] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
[  304.789686] ksoftirqd/0/3 [HC0[0]:SC1[1]:HE1:SE0] takes:
[  304.789686]  (&(&hdev->lock)->rlock){+.?...}, at: [<ffffffffa000bbfe>] hci_conn_check_pending+0x38/0x76 [bluetooth]
[  304.789686] {SOFTIRQ-ON-W} state was registered at:
[  304.789686]   [<ffffffff8105188b>] __lock_acquire+0x347/0xd52
[  304.789686]   [<ffffffff810526ac>] lock_acquire+0x8a/0xa7
[  304.789686]   [<ffffffff812b3758>] _raw_spin_lock+0x2c/0x3b
[  304.789686]   [<ffffffffa0009cf0>] hci_blacklist_del+0x1f/0x8a [bluetooth]
[  304.789686]   [<ffffffffa00139fd>] hci_sock_ioctl+0x2d9/0x314 [bluetooth]
[  304.789686]   [<ffffffff812197d8>] sock_ioctl+0x1f2/0x214
[  304.789686]   [<ffffffff810b0fd6>] do_vfs_ioctl+0x46c/0x4ad
[  304.789686]   [<ffffffff810b1059>] sys_ioctl+0x42/0x65
[  304.789686]   [<ffffffff812b4892>] system_call_fastpath+0x16/0x1b
[  304.789686] irq event stamp: 9768
[  304.789686] hardirqs last  enabled at (9768): [<ffffffff812b40d4>] restore_args+0x0/0x30
[  304.789686] hardirqs last disabled at (9767): [<ffffffff812b3f6a>] save_args+0x6a/0x70
[  304.789686] softirqs last  enabled at (9726): [<ffffffff8102fa9b>] __do_softirq+0x129/0x13f
[  304.789686] softirqs last disabled at (9739): [<ffffffff8102fb33>] run_ksoftirqd+0x82/0x133
[  304.789686]
[  304.789686] other info that might help us debug this:
[  304.789686]  Possible unsafe locking scenario:
[  304.789686]
[  304.789686]        CPU0
[  304.789686]        ----
[  304.789686]   lock(&(&hdev->lock)->rlock);
[  304.789686]   <Interrupt>
[  304.789686]     lock(&(&hdev->lock)->rlock);
[  304.789686]
[  304.789686]  *** DEADLOCK ***
[  304.789686]
[  304.789686] 1 lock held by ksoftirqd/0/3:
[  304.789686]  #0:  (hci_task_lock){++.-..}, at: [<ffffffffa0008353>] hci_rx_task+0x49/0x2f3 [bluetooth]
[  304.789686]
[  304.789686] stack backtrace:
[  304.789686] Pid: 3, comm: ksoftirqd/0 Not tainted 2.6.39+ #1
[  304.789686] Call Trace:
[  304.789686]  [<ffffffff812ae901>] print_usage_bug+0x1e7/0x1f8
[  304.789686]  [<ffffffff8100a796>] ? save_stack_trace+0x27/0x44
[  304.789686]  [<ffffffff8104fc3f>] ? print_irq_inversion_bug.part.26+0x19a/0x19a
[  304.789686]  [<ffffffff810504bb>] mark_lock+0x106/0x258
[  304.789686]  [<ffffffff812b40d4>] ? retint_restore_args+0x13/0x13
[  304.789686]  [<ffffffff81051817>] __lock_acquire+0x2d3/0xd52
[  304.789686]  [<ffffffff8102be73>] ? vprintk+0x3ab/0x3d7
[  304.789686]  [<ffffffff812ae126>] ? printk+0x3c/0x3e
[  304.789686]  [<ffffffff810526ac>] lock_acquire+0x8a/0xa7
[  304.789686]  [<ffffffffa000bbfe>] ? hci_conn_check_pending+0x38/0x76 [bluetooth]
[  304.789686]  [<ffffffff811601c6>] ? __dynamic_pr_debug+0x10c/0x11a
[  304.789686]  [<ffffffff812b3758>] _raw_spin_lock+0x2c/0x3b
[  304.789686]  [<ffffffffa000bbfe>] ? hci_conn_check_pending+0x38/0x76 [bluetooth]
[  304.789686]  [<ffffffffa000bbfe>] hci_conn_check_pending+0x38/0x76 [bluetooth]
[  304.789686]  [<ffffffffa000c561>] hci_event_packet+0x38e/0x3e12 [bluetooth]
[  304.789686]  [<ffffffff81052615>] ? lock_release+0x16c/0x179
[  304.789686]  [<ffffffff812b3b41>] ? _raw_read_unlock+0x23/0x27
[  304.789686]  [<ffffffffa0013e7f>] ? hci_send_to_sock+0x179/0x188 [bluetooth]
[  304.789686]  [<ffffffffa00083d2>] hci_rx_task+0xc8/0x2f3 [bluetooth]
[  304.789686]  [<ffffffff8102f5a9>] tasklet_action+0x87/0xe6
[  304.789686]  [<ffffffff8102fa11>] __do_softirq+0x9f/0x13f
[  304.789686]  [<ffffffff8102fb33>] run_ksoftirqd+0x82/0x133
[  304.789686]  [<ffffffff8102fab1>] ? __do_softirq+0x13f/0x13f
[  304.789686]  [<ffffffff81040f0a>] kthread+0x7f/0x87
[  304.789686]  [<ffffffff812b55c4>] kernel_thread_helper+0x4/0x10
[  304.789686]  [<ffffffff812b40d4>] ? retint_restore_args+0x13/0x13
[  304.789686]  [<ffffffff81040e8b>] ? __init_kthread_worker+0x53/0x53
[  304.789686]  [<ffffffff812b55c0>] ? gs_change+0x13/0x13

Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>

rt2x00: Implement tx_frames_pending mac80211 callback function.

Implementing this callback function will cause mac80211 refrain from
going to powersave state when there are still untransmitted TX frames
in the queues.
This would exactly mimic the behaviour of the legacy vendor driver which
also doesn't go in powersave mode if there are still TX frames that are not
transmitted.
This should make powersaving and rt2x00 a better couple.

Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

rt2x00: Properly identify rt2800usb devices.

Sitecom WLA4000 (USB ID 0x0df6:0x0060) is an RT3072 chipset.
Sitecom WLA5000 (USB ID 0x0df6:0x0062) is an RT3572 chipset.

Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

rt2x00: Add device ID for RT539F device.

Reported-by: Wim Vander Schelden <wim@fixnum.org>
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

rt2x00: Reduce window of a queue's tx lock.

Currently a lot of actions that can be done without the queue's tx lock
being held are done inside the locked area.
Move them out to have a leaner and meaner code that operates while the
tx lock is being held.

Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

rt2x00: Don't use queue entry as parameter when creating TX descriptor.

The functions that create the tx descriptor structure do not operate on
a queue entry at all. Signal this fact in the code by not providing a
queue entry as a parameter, but the rt2x00 device structure and the skb
directly.

This patch is a preparation for reducing the time a queue is locked for
a tx operation.

Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

rt2x00: Serialize TX operations on a queue.

The rt2x00 driver gets frequent occurrences of the following error message
when operating under load:
phy0 -> rt2x00queue_write_tx_frame: Error - Arrived at non-free entry in the
non-full queue 2.

This is caused by simultaneous attempts from mac80211 to send a frame via
rt2x00, which are not properly serialized inside rt2x00queue_write_tx_frame,
causing the second frame to fail sending with the above mentioned error
message.

Fix this by introducing a per-queue spinlock to serialize the TX operations
on that queue.

Reported-by: Andreas Hartmann <andihartmann@01019freenet.de>
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

bcma: detect PCI core working in hostmode

We must not init it like clientmode one, it would break device (tested
by Hauke on BCM4718). Add stub hostmode driver for now.

Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

mac80211: fix TKIP replay vulnerability

Unlike CCMP, the presence or absence of the QoS
field doesn't change the encryption, only the
TID is used. When no QoS field is present, zero
is used as the TID value. This means that it is
possible for an attacker to take a QoS packet
with TID 0 and replay it as a non-QoS packet.

Unfortunately, mac80211 uses different IVs for
checking the validity of the packet's TKIP IV
when it checks TID 0 and when it checks non-QoS
packets. This means it is vulnerable to this
replay attack.

To fix this, use the same replay counter for
TID 0 and non-QoS packets by overriding the
rx->queue value to 0 if it is 16 (non-QoS).

This is a minimal fix for now. I caused this
issue in

commit 1411f9b531f0a910cd1c85a337737c1e6ffbae6a
Author: Johannes Berg <johannes@sipsolutions.net>
Date:   Thu Jul 10 10:11:02 2008 +0200

    mac80211: fix RX sequence number check

while fixing a sequence number issue (there,
a separate counter needs to be used).

Cc: stable@kernel.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

mac80211: fix ie memory allocation for scheduled scans

We were not allocating memory for the IEs passed in the scheduled_scan
request and this was causing memory corruption (buffer overflow).

Signed-off-by: Luciano Coelho <coelho@ti.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ssb: fix init regression of hostmode PCI core

Our workarounds seem to be clientmode PCI specific. Using SPROM
workaround on SoC resulted in Oops:

Data bus error, epc == 8017ed58, ra == 80225838
 Oops[#1]:
 Cpu 0
 $ 0   : 00000000 10008000 b8000000 00000001
 $ 4   : 80293b5c 00000caa ffffffff 00000000
 $ 8   : 0000000a 00000003 00000001 696d6d20
 $12   : ffffffff 00000000 00000000 ffffffff
 $16   : 802d0140 b8004800 802c0000 00000000
 $20   : 00000000 802c0000 00000000 802d04d4
 $24   : 00000018 80151a00
 $28   : 81816000 81817df8 8029bda0 80225838
 Hi    : 00000000
 Lo    : 00000000
 epc   : 8017ed58 ssb_ssb_read16+0x48/0x60
   Not tainted
 ra    : 80225838 ssb_pcicore_init+0x54/0x3b4

Reported-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Tested-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Bluetooth: Remove enable_smp parameter

The enable_smp parameter is no longer needed. It can be replaced by
checking lmp_host_le_capable.

Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>