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>

Correct spelling typo in wireless/mwifiex driver.
Signed-off-by: NMasanari Iida <standby24x7@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

rtlwifi only provides pm callbacks for functions covered by pm sleep
and they are also just called if CONFIG_PM_SLEEP is set.

Only add functions rtl_pci_suspend and rtl_pci_resume if
CONFIG_PM_SLEEP is set and use SIMPLE_DEV_PM_OPS instead of
manually filling struct dev_pm_ops.
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

p54pci does not provide any runtime pm callbacks, so support for
PM_RUNTIME is not needed and we could go to PM_SLEEP.
This also makes it possible to use SIMPLE_DEV_PM_OPS instead of
manually filling struct dev_pm_ops.
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

ath9k does not provide any runtime pm callbacks, so support for
PM_RUNTIME is not needed and we could go to PM_SLEEP.
This also makes it possible to use SIMPLE_DEV_PM_OPS instead of
manually filling struct dev_pm_ops.
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch fixes almost all coding issues in the rtl8192se driver. Only
exception is putting trailing */ on separate lines.
Signed-off-by: NDaniel Stamer <daniel@stamer.info>
Acked-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Using bss->information_elements and treating
bss->len_beacon_ies as its size is wrong, the
real size is len_information_elements.

Found while I was reviewing the use of this
cfg80211 API (as it is actually potentially
broken due to races.)
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Acked-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

see header.
Reviewed-by: NArend Van Spriel <arend@broadcom.com>
Signed-off-by: NHante Meuleman <meuleman@broadcom.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Parsing vndrs ie was not taking len of tlv itself in account. Setting
mgmt ie was missing check for length indicating non configured ie and
wrongly checking available length.
Reviewed-by: NArend Van Spriel <arend@broadcom.com>
Signed-off-by: NHante Meuleman <meuleman@broadcom.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The mode should be stored and used per virtual interface. Remove
the mode from device global structure and rework the code to use
the mode from brcmf_cfg80211_vif.
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Reviewed-by: NHante Meuleman <meuleman@broadcom.com>
Reviewed-by: NFranky (Zhenhui) Lin <frankyl@broadcom.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This attribute indicates successful IBSS or AP connection has been
established. However, this no longer works for virtual interfaces.
As it turns out this attribute is identical to the CONNECTED bit
in struct brcmf_cfg80211_vif::sme_state. This patch removes the
attribute and rework some functions relying on it.
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Reviewed-by: NHante Meuleman <meuleman@broadcom.com>
Reviewed-by: NFranky (Zhenhui) Lin <frankyl@broadcom.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Add support for 4313 iPA variant.
It is a variant of already supported 4313 ePA
and needs some PHY changes to work properly.
Reviewed-by: NArend Van Spriel <arend@broadcom.com>
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Reviewed-by: NHante Meuleman <meuleman@broadcom.com>
Signed-off-by: NPiotr Haber <phaber@broadcom.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Move functions in
preparation for 4313iPA changes
Reviewed-by: NArend Van Spriel <arend@broadcom.com>
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Reviewed-by: NHante Meuleman <meuleman@broadcom.com>
Signed-off-by: NPiotr Haber <phaber@broadcom.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Put basic information about hardware in debugfs.
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Reviewed-by: NHante Meuleman <meuleman@broadcom.com>
Reviewed-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NPiotr Haber <phaber@broadcom.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Acked-by: NSeth Forshee <seth.forshee@canonical.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

brcms_b_txstatus and brcms_b_recv are off by one when
doing bounds checking on number of packets to process
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Reviewed-by: NHante Meuleman <meuleman@broadcom.com>
Reviewed-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NPiotr Haber <phaber@broadcom.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

brcms_c_isr returns true if interrupt was for us
and if dpc should be scheduled which is the same thing.
Simplify it.
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Reviewed-by: NHante Meuleman <meuleman@broadcom.com>
Reviewed-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NPiotr Haber <phaber@broadcom.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The .tx() callback function can drop packets when there is no
space in the DMA fifo. Propagate that information to caller
and make sure the freed sk_buff reference is not accessed.
Reviewed-by: NArend van Spriel <arend@broadcom.com>
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: NPiotr Haber <phaber@broadcom.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Organizational changes need to be reflected in the MAINTAINERS file.
The contact info on wireless.kernel.org has also been updated.
Reviewed-by: NHante Meuleman <meuleman@broadcom.com>
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

There are 2 different things:
- sub-menu for "Atheros Wireless cards" family
- module ath.ko with common Atheros code

Until now, they both used to depend on the same Kconfig variable ATH_COMMON.
Thus, being "Atheros card" and "depending on ath.ko" was the same.

To allow module to belong to the
"Atheros Wireless cards" family but not use ath.ko,
2 conditions above need to be separated.

So, this patch introduce new Kconfig variable ATH_CARDS for belonging
to the "Atheros Wireless Cards" family; while ATH_COMMON becomes hidden
variable to express dependency on common Atheros code in ath.ko. Modules
that depend on this common code now express it by setting ATH_COMMON.

Right now, ath6kl do not depend on common code and thus do not set ATH_COMMON.
Signed-off-by: NVladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

'bf_next' is cleared using ATH_TXBUF_RESET() in both the
callsites of ath_tx_get_buffer().
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>