all the current firmwares support elp, so
we can safely remove WLCORE_QUIRK_NO_ELP.
Signed-off-by: NEliad Peller <eliad@wizery.com>
Signed-off-by: NArik Nemtsov <arik@wizery.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

Under some circumstances, that fw might be asked to
remove a rx ba sessions it doesn't know about. In
this case, instead of triggering a recovery, accept
the error code (CMD_STATUS_NO_RX_BA_SESSION) and
ignore it.

[Arik - indicate failure up when the BA session cannot be setup]
Signed-off-by: NEliad Peller <eliad@wizery.com>
Signed-off-by: NArik Nemtsov <arik@wizery.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

Currently, each fw command/acx that return a status code
different than CMD_STATUS_SUCCESS will trigger a recovery
in the driver.

However, it is a valid for some fw commands to fail (e.g.
due to temporary lack of resources), so add new functions
that allow passing bitmap of valid error return values.

(make the current wl1271_cmd_send/wl1271_cmd_configure
wrappers around the new functions, in order to avoid
changing the whole driver)
Signed-off-by: NEliad Peller <eliad@wizery.com>
Signed-off-by: NArik Nemtsov <arik@wizery.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

First set (low, medium and high TX power values) is used
for STA-HP background role. The 2nd set is used for other roles.

Update other mac/phy parameters according to new FW.
Signed-off-by: NYair Shapira <yair.shapira@ti.com>
Signed-off-by: NArik Nemtsov <arik@wizery.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

Conflicts:
	drivers/net/wireless/ti/wl18xx/main.c

Update mac/phy paramters according to the default HP SISO boards.
Signed-off-by: NIdo Reis <idor@ti.com>
Signed-off-by: NArik Nemtsov <arik@wizery.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

The 12xx FW doesn't support non-zero session ids for AP-mode. Introduce
an appropriate quirk to make sure the session id is always zero when
needed.
Signed-off-by: NArik Nemtsov <arik@wizery.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

Conflicts:
	drivers/net/wireless/ti/wlcore/main.c

For wl18xx, only the chip ID and the minor version number are
relevant.  Ignore the other numbers which are either not used or
relate to internal projects or internal branches.
Signed-off-by: NLuciano Coelho <coelho@ti.com>

Previously we were only checking the single-role firmware version.
Now add code to check for the firmware versions separately for each
firmware type.
Signed-off-by: NLuciano Coelho <coelho@ti.com>

The firmware type and the project number fields in the firmware
version number, cannot be checked as if they increase sequentially,
because the former is the firmware type and the latter is an internal
project number.  There's no guarantee that these numbers will remain
incremental, so use WLCORE_FW_VER_IGNORE.
Signed-off-by: NLuciano Coelho <coelho@ti.com>

The firmwares version string contain 5 integers.  We used to consider
all the digits (except for the first one, which indicates the chip) as
linearly increasing version numbers.  This is not correct, because
some of the integers indicate type of firmware (eg. single-role
vs. multi-role) or the internal project it was created for.

Besides, this varies a bit from chip to chip, so we need to make the
firmware version checks more flexible (eg. allow the lower driver to
ignore some of the integers).  Additionally, we need to change the
code so that we only check for a linearly increasing number on the
fields where this actually makes sense.
Signed-off-by: NLuciano Coelho <coelho@ti.com>

We don't distinguish between STA and AP firmwares anymore, so the
firmware version checking and quirks setting in wl12xx isn't needed
anymore.

Remove implementation of .identify_fw in wl12xx and deprecated
definitions.  Don't remove the op entirely from wlcore, because it may
be needed for more fine-grained checking later.
Signed-off-by: NLuciano Coelho <coelho@ti.com>

Move wl12xx-specific chip ID macros to the wl12xx driver and rename
them to 127X and 128X for clarity since both the "1" (2.4GHz) and the
"3" (2.4GHz and 5GHz) variants use the same chip ID.
Signed-off-by: NLuciano Coelho <coelho@ti.com>

add support for recovery settings including bug_on_recovery and
no_recovery options.

These options can now be set using wl18xx-conf.bin file and wlconf
tool.
Signed-off-by: NYair Shapira <yair.shapira@ti.com>
Signed-off-by: NArik Nemtsov <arik@wizery.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

It's sometimes useful to gather information about the firmware
stability in long test runs, especially to see if problems are
recurring frequently or not.  With this commit we count the number of
times a hardware recovery was issued and print it out during recovery
and in the driver_state in debugfs.
Signed-off-by: NLuciano Coelho <coelho@ti.com>
Signed-off-by: NIgal Chernobelsky <igalc@ti.com>
Signed-off-by: NArik Nemtsov <arik@wizery.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

Adapt the new mac80211 BSS_CHANGED_PS notification,
and do the ps handling in mac80211's per-vif
callback (.bss_info_changed), rather than in
the per-device (.config) callback.

Make sure to configure it only after association.
Signed-off-by: NEliad Peller <eliad@wizery.com>
Signed-off-by: NArik Nemtsov <arik@wizery.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

mask out CCK rates from the AP's local rates
when the interace is p2p interface (GO).
Signed-off-by: NEliad Peller <eliad@wizery.com>
Signed-off-by: NArik Nemtsov <arik@wizery.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

Try an opportunistic ROC when a STA is first added and stop the ROC when
the STA is removed or successfully authenticated. This would ensure we
don't miss auth/assoc/EAPOL packets during connection
Signed-off-by: NEliad Peller <eliad@wizery.com>
Signed-off-by: NArik Nemtsov <arik@wizery.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

18xx chips are capable of staying on 2 channels at the same time.
Introduce a chip-family specific parameter to set the number of channels
in the interface-combinations published by the driver.
Signed-off-by: NArik Nemtsov <arik@wizery.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

This patch removes a left over debugging print present in the pci
shutdown callback, since this callback does not do anything useful, get
rid of it entirely.
Signed-off-by: NFlorian Fainelli <ffainelli@freebox.fr>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

On the RF3290,RF5360,RF5370,RF5372,RF5390,RF5392
radio frontends, the VCO calibration can be
controlled via the RFCSR3 register. The current
code uses the RFCSR30_RF_CALIBRATION constant to
enable the calibration, however that belongs to
the RFCSR30 register. Although the values of the
constant is correct, but using that for another
register is confusing.

Add a new definition for the VCO calibration enable
bit of the RFCSR3 register and use that in the
relevant places in order to avoid confusions.

The patch contains no functional changes.
Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

On A-MPDU frames, the hardware only reports valid
signal strength data for the last subframe.

This patch fixes it by flagging everything but the
last subframe in an A-MPDU to tell mac80211 to
ignore the signal strength entirely. Otherwise
the empty value (= 0 dbm) will distort the
average quite badly.
Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The patch contains no functional changes.
Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The patch contains no functional changes.
Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

"entries" is unsigned here, so it is never less than zero.  In theory,
len could be less than offset so I have added a check for that.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Acked-by: NChristian Lamparter <chunkeey@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Merge branch 'for-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next

This reverts commit 269c4845.

The commit was causing dead locks and NULL dereferences in the sco code:

 [28084.104013] BUG: soft lockup - CPU#0 stuck for 22s! [kworker/u:0H:7]
 [28084.104021] Modules linked in: btusb bluetooth <snip [last unloaded:
bluetooth]
...
 [28084.104021]  [<c160246d>] _raw_spin_lock+0xd/0x10
 [28084.104021]  [<f920e708>] sco_conn_del+0x58/0x1b0 [bluetooth]
 [28084.104021]  [<f920f1a9>] sco_connect_cfm+0xb9/0x2b0 [bluetooth]
 [28084.104021]  [<f91ef289>]
hci_sync_conn_complete_evt.isra.94+0x1c9/0x260 [bluetooth]
 [28084.104021]  [<f91f1a8d>] hci_event_packet+0x74d/0x2b40 [bluetooth]
 [28084.104021]  [<c1501abd>] ? __kfree_skb+0x3d/0x90
 [28084.104021]  [<c1501b46>] ? kfree_skb+0x36/0x90
 [28084.104021]  [<f91fcb4e>] ? hci_send_to_monitor+0x10e/0x190 [bluetooth]
 [28084.104021]  [<f91fcb4e>] ? hci_send_to_monitor+0x10e/0x190 [bluetooth]

Cc: stable@vger.kernel.org
Reported-by: NChan-yeol Park <chanyeol.park@gmail.com>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

Make code more readable by changing CONF_NO_FCS_RECV which is read
as "No L2CAP FCS option received" to CONF_RECV_NO_FCS which means
"Received L2CAP option NO_FCS". This flag really means that we have
received L2CAP FRAME CHECK SEQUENCE (FCS) OPTION with value "No FCS".
Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

Process L2CAP Config rsp Pending with FCS Option 0x00 (No FCS)
which is sent by Motorola Windows 7 Bluetooth stack. The trace
is shown below (all other options are skipped).

...
< ACL data: handle 1 flags 0x00 dlen 48
    L2CAP(s): Config req: dcid 0x0043 flags 0x00 clen 36
      ...
      FCS Option 0x00 (No FCS)
> ACL data: handle 1 flags 0x02 dlen 48
    L2CAP(s): Config req: dcid 0x0041 flags 0x00 clen 36
      ...
      FCS Option 0x01 (CRC16 Check)
< ACL data: handle 1 flags 0x00 dlen 47
    L2CAP(s): Config rsp: scid 0x0043 flags 0x00 result 4 clen 33
      Pending
      ...
> ACL data: handle 1 flags 0x02 dlen 50
    L2CAP(s): Config rsp: scid 0x0041 flags 0x00 result 4 clen 36
      Pending
      ...
      FCS Option 0x00 (No FCS)
< ACL data: handle 1 flags 0x00 dlen 14
    L2CAP(s): Config rsp: scid 0x0043 flags 0x00 result 0 clen 0
      Success
> ACL data: handle 1 flags 0x02 dlen 14
    L2CAP(s): Config rsp: scid 0x0041 flags 0x00 result 0 clen 0
      Success
...
Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

If L2CAP_FEAT_FCS is not supported we sould miss EWS option
configuration because of break. Make code more readable by
combining FCS configuration in the single block.
Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

Before starting quering remote AMP controllers make sure
that there is local active AMP controller.
Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

After getting HCIDEVDOWN controller did not mark itself as 0x00 which
means: "The Controller radio is available but is currently physically
powered down". The result was even if the hdev was down we return
in controller list value 0x01 "status 0x01 (Bluetooth only)".
Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

l2cap_send_disconn_req takes 3 parameters of which conn might be
derived from chan. Make this conversion inside l2cap_send_disconn_req.
Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

Some comparisons needs to double negation(!!) in order to make the value
of the field boolean. Add it to the macro makes the code more readable.
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

In order to authenticate and configure an incoming SCO connection, the
BT_DEFER_SETUP option was added. This option is intended to defer reply
to Connect Request on SCO sockets.
When a connection is requested, the listening socket is unblocked but
the effective connection setup happens only on first recv. Any send
between accept and recv fails with -ENOTCONN.
Signed-off-by: NFrédéric Dalleau <frederic.dalleau@linux.intel.com>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

This option will set the BT_SK_DEFER_SETUP bit in socket flags.
Signed-off-by: NFrédéric Dalleau <frederic.dalleau@linux.intel.com>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

We need to cancel the hci_power_on work in order to avoid it run when we
try to free the hdev.

[ 1434.201149] ------------[ cut here ]------------
[ 1434.204998] WARNING: at lib/debugobjects.c:261 debug_print_object+0x8e/0xb0()
[ 1434.208324] ODEBUG: free active (active state 0) object type: work_struct hint: hci
_power_on+0x0/0x90
[ 1434.210386] Pid: 8564, comm: trinity-child25 Tainted: G        W    3.7.0-rc5-next-
20121112-sasha-00018-g2f4ce0e #127
[ 1434.210760] Call Trace:
[ 1434.210760]  [<ffffffff819f3d6e>] ? debug_print_object+0x8e/0xb0
[ 1434.210760]  [<ffffffff8110b887>] warn_slowpath_common+0x87/0xb0
[ 1434.210760]  [<ffffffff8110b911>] warn_slowpath_fmt+0x41/0x50
[ 1434.210760]  [<ffffffff819f3d6e>] debug_print_object+0x8e/0xb0
[ 1434.210760]  [<ffffffff8376b750>] ? hci_dev_open+0x310/0x310
[ 1434.210760]  [<ffffffff83bf94e5>] ? _raw_spin_unlock_irqrestore+0x55/0xa0
[ 1434.210760]  [<ffffffff819f3ee5>] __debug_check_no_obj_freed+0xa5/0x230
[ 1434.210760]  [<ffffffff83785db0>] ? bt_host_release+0x10/0x20
[ 1434.210760]  [<ffffffff819f4d15>] debug_check_no_obj_freed+0x15/0x20
[ 1434.210760]  [<ffffffff8125eee7>] kfree+0x227/0x330
[ 1434.210760]  [<ffffffff83785db0>] bt_host_release+0x10/0x20
[ 1434.210760]  [<ffffffff81e539e5>] device_release+0x65/0xc0
[ 1434.210760]  [<ffffffff819d3975>] kobject_cleanup+0x145/0x190
[ 1434.210760]  [<ffffffff819d39cd>] kobject_release+0xd/0x10
[ 1434.210760]  [<ffffffff819d33cc>] kobject_put+0x4c/0x60
[ 1434.210760]  [<ffffffff81e548b2>] put_device+0x12/0x20
[ 1434.210760]  [<ffffffff8376a334>] hci_free_dev+0x24/0x30
[ 1434.210760]  [<ffffffff82fd8fe1>] vhci_release+0x31/0x60
[ 1434.210760]  [<ffffffff8127be12>] __fput+0x122/0x250
[ 1434.210760]  [<ffffffff811cab0d>] ? rcu_user_exit+0x9d/0xd0
[ 1434.210760]  [<ffffffff8127bf49>] ____fput+0x9/0x10
[ 1434.210760]  [<ffffffff81133402>] task_work_run+0xb2/0xf0
[ 1434.210760]  [<ffffffff8106cfa7>] do_notify_resume+0x77/0xa0
[ 1434.210760]  [<ffffffff83bfb0ea>] int_signal+0x12/0x17
[ 1434.210760] ---[ end trace a6d57fefbc8a8cc7 ]---

Cc: stable@vger.kernel.org
Reported-by: NSasha Levin <sasha.levin@oracle.com>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

This patch fixes the following report, it happens when accepting rfcomm
connections:

[  228.165378] =============================================
[  228.165378] [ INFO: possible recursive locking detected ]
[  228.165378] 3.7.0-rc1-00536-gc1d5dc4a #120 Tainted: G        W
[  228.165378] ---------------------------------------------
[  228.165378] bluetoothd/1341 is trying to acquire lock:
[  228.165378]  (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+...}, at:
[<ffffffffa0000aa0>] bt_accept_dequeue+0xa0/0x180 [bluetooth]
[  228.165378]
[  228.165378] but task is already holding lock:
[  228.165378]  (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+...}, at:
[<ffffffffa0205118>] rfcomm_sock_accept+0x58/0x2d0 [rfcomm]
[  228.165378]
[  228.165378] other info that might help us debug this:
[  228.165378]  Possible unsafe locking scenario:
[  228.165378]
[  228.165378]        CPU0
[  228.165378]        ----
[  228.165378]   lock(sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM);
[  228.165378]   lock(sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM);
[  228.165378]
[  228.165378]  *** DEADLOCK ***
[  228.165378]
[  228.165378]  May be due to missing lock nesting notation

Cc: stable@vger.kernel.org
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

There's a debug message to warn if this function is passed a NULL
pointer, but in order to print the message we have to dereference the
pointer. Obviously this isn't a good idea, so remove the message.
Reported-by: NFengguang Wu <fengguang.wu@intel.com>
Signed-off-by: NSeth Forshee <seth.forshee@canonical.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>