NFC: Fix NCI over SPI build

kbuild test robot found following error:

     net/built-in.o: In function `nci_spi_send':
  >> spi.c:(.text+0x19a76f): undefined reference to `crc_ccitt'

Add CRC_CCITT module to Kconfig to fix it

Reported-by: kbuild test robot.
Signed-off-by: Frederic Danis <frederic.danis@linux.intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
ath10k: ATH10K should depend on HAS_DMA

If NO_DMA=y:

drivers/built-in.o: In function `ath10k_skb_unmap':
drivers/net/wireless/ath/ath10k/core.h:98: undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `ath10k_skb_map':
drivers/net/wireless/ath/ath10k/core.h:83: undefined reference to `dma_map_single'
drivers/net/wireless/ath/ath10k/core.h:86: undefined reference to `dma_mapping_error'
drivers/built-in.o: In function `ath10k_htt_rx_ring_free':
drivers/net/wireless/ath/ath10k/htt_rx.c:113: undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `ath10k_htt_rx_amsdu_pop':
drivers/net/wireless/ath/ath10k/htt_rx.c:296: undefined reference to `dma_unmap_single'
drivers/net/wireless/ath/ath10k/htt_rx.c:389: undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `__ath10k_htt_rx_ring_fill_n':
drivers/net/wireless/ath/ath10k/htt_rx.c:146: undefined reference to `dma_map_single'
drivers/net/wireless/ath/ath10k/htt_rx.c:150: undefined reference to `dma_mapping_error'
drivers/built-in.o: In function `ath10k_htt_rx_attach':
drivers/net/wireless/ath/ath10k/htt_rx.c:474: undefined reference to `dma_alloc_coherent'
drivers/net/wireless/ath/ath10k/htt_rx.c:509: undefined reference to `dma_free_coherent'
drivers/net/wireless/ath/ath10k/htt_rx.c:514: undefined reference to `dma_free_coherent'
drivers/built-in.o: In function `ath10k_htt_rx_detach':
drivers/net/wireless/ath/ath10k/htt_rx.c:220: undefined reference to `dma_unmap_single'
drivers/net/wireless/ath/ath10k/htt_rx.c:228: undefined reference to `dma_free_coherent'
drivers/built-in.o: In function `ath10k_skb_map':
drivers/net/wireless/ath/ath10k/core.h:83: undefined reference to `dma_map_single'
drivers/net/wireless/ath/ath10k/core.h:86: undefined reference to `dma_mapping_error'
drivers/built-in.o: In function `ath10k_skb_unmap':
drivers/net/wireless/ath/ath10k/core.h:98: undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `ath10k_skb_map':
drivers/net/wireless/ath/ath10k/core.h:83: undefined reference to `dma_map_single'
drivers/net/wireless/ath/ath10k/core.h:86: undefined reference to `dma_mapping_error'
drivers/net/wireless/ath/ath10k/core.h:83: undefined reference to `dma_map_single'
drivers/net/wireless/ath/ath10k/core.h:86: undefined reference to `dma_mapping_error'
drivers/built-in.o: In function `ath10k_skb_unmap':
drivers/net/wireless/ath/ath10k/core.h:98: undefined reference to `dma_unmap_single'
drivers/net/wireless/ath/ath10k/core.h:98: undefined reference to `dma_unmap_single'
drivers/net/wireless/ath/ath10k/core.h:98: undefined reference to `dma_unmap_single'
drivers/net/wireless/ath/ath10k/core.h:98: undefined reference to `dma_unmap_single'

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: linux-wireless@vger.kernel.org
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
MAINTAINERS: add ath10k

I forgot to add an entry to MAINTAINERS when submitting the driver.

Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
pch_dma: fix error return code in pch_dma_probe()

Fix to return -ENODEV when no proper base address found error
handling case instead of 0, as done elsewhere in this function.

Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
MAINTAINERS: update ath6kl git location

The git tree is in github.com nowadays.

Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
mac80211: prevent the buffering or frame transmission to non-assoc mesh STA

This patch is intended to avoid the buffering to non-assoc mesh STA
and also to avoid the triggering of frame to non-assoc mesh STA which
could cause kernel panic in specific hw.

One of the examples, is kernel panic happens to ath9k if user space
inserts the mesh STA and not proceed with the SAE and AMPE, and later
the same mesh STA is detected again. The sta_state of the mesh STA remains
at IEEE80211_STA_NONE and if the ieee80211_sta_ps_deliver_wakeup is called
and subsequently the ath_tx_aggr_wakeup, the kernel panic due to
ath_tx_node_init is not called before to initialize the require data
structures.

This issue is reported by Cedric Voncken before.
http://www.spinics.net/lists/linux-wireless/msg106342.html

[<831ea6b4>] ath_tx_aggr_wakeup+0x44/0xcc [ath9k]
[<83084214>] ieee80211_sta_ps_deliver_wakeup+0xb8/0x208 [mac80211]
[<830b9824>] ieee80211_mps_sta_status_update+0x94/0x108 [mac80211]
[<83099398>] ieee80211_sta_ps_transition+0xc94/0x34d8 [mac80211]
[<8022399c>] nf_iterate+0x98/0x104
[<8309bb60>] ieee80211_sta_ps_transition+0x345c/0x34d8 [mac80211]

Signed-off-by: Chun-Yeow Yeoh <yeohchunyeow@gmail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
iwlwifi: add DELL SKU for 5150 HMC

This SKU was missing in the list of supported devices

https://bugzilla.kernel.org/show_bug.cgi?id=60577

Cc: <stable@vger.kernel.org> [all versions]
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
x86/iommu/vt-d: Expand interrupt remapping quirk to cover x58 chipset

Recently we added an early quirk to detect 5500/5520 chipsets
with early revisions that had problems with irq draining with
interrupt remapping enabled:

  commit 03bbcb2e7e292838bb0244f5a7816d194c911d62
  Author: Neil Horman <nhorman@tuxdriver.com>
  Date:   Tue Apr 16 16:38:32 2013 -0400

      iommu/vt-d: add quirk for broken interrupt remapping on 55XX chipsets

It turns out this same problem is present in the intel X58
chipset as well. See errata 69 here:

  http://www.intel.com/content/www/us/en/chipsets/x58-express-specification-update.html

This patch extends the pci early quirk so that the chip
devices/revisions specified in the above update are also covered
in the same way:

Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Donald Dutile <ddutile@redhat.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Malcolm Crossley <malcolm.crossley@citrix.com>
Cc: Prarit Bhargava <prarit@redhat.com>
Cc: Don Zickus <dzickus@redhat.com>
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/1374059639-8631-1-git-send-email-nhorman@tuxdriver.com
[ Small edits. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
mac80211: fix monitor interface suspend crash regression

My commit:

commit 12e7f517029dad819c45eca9ca01fdb9ba57616b
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date:   Thu Feb 28 10:55:26 2013 +0100

    mac80211: cleanup generic suspend/resume procedures

removed check for deleting MONITOR and AP_VLAN when suspend. That can
cause a crash (i.e. in iwlagn_mac_remove_interface()) since we remove
interface in the driver that we did not add before.

Reference:
http://marc.info/?l=linux-kernel&m=137391815113860&w=2

Bisected-by: Ortwin Glück <odi@odi.ch>
Reported-and-tested-by: Ortwin Glück <odi@odi.ch>
Cc: stable@vger.kernel.org # 3.10
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
iwlwifi: mvm: use only a single GTK in D3

Unfortunately, the firmware only supports replay counters for
a single GTK in D3, so that we should only upload the last
key and use its replay counters. Since mac80211 key iteration
will walk through the keys in order of their addition, simply
use the same HW key index (1) for all GTKs, thus overwriting
previous ones with newer ones. The replay counters for it are
already used.

Reviewed-by: Yaron Vaknin <Yaron.Vaknin@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
iwlwifi: mvm: set SSID bits for passive channels

Set SSID bitmap for direct scan even on passive channels,
for the passive-to-active feature. Without this patch only
the SSID from probe request template is sent on passive
channels, after passive-to-active switching, causing us to
not find all desired networks.

Remove the unused passive scan mask constant.

Cc: stable@vger.kernel.org
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: David Spinadel <david.spinadel@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
ASoC: dapm: Fix return value of snd_soc_dapm_put_{volsw,enum_virt}()

The ALSA core expect the put callback of a control to return 1 if the value of
the control changed and 0 if it did not. Both snd_soc_dapm_put_volsw() and
snd_soc_dapm_put_enum_virt() currently always returns 0. For both functions we
already have a 'change' variable which either contains 1 or 0 depending on
whether the value has changed or not, so just return that.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
regulatory: use correct regulatory initiator on wiphy register

The current regdomain was not always set by the core. This causes
cards with a custom regulatory domain to ignore user initiated changes
if done before the card was registered.

Signed-off-by: Arik Nemtsov <arik@wizery.com>
Acked-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Bluetooth: Fix invalid length check in l2cap_information_rsp()

The length check is invalid since the length varies with type of
info response.

This was introduced by the commit cb3b3152b2f5939d67005cff841a1ca748b19888

Because of this, l2cap info rsp is not handled and command reject is sent.

> ACL data: handle 11 flags 0x02 dlen 16
        L2CAP(s): Info rsp: type 2 result 0
          Extended feature mask 0x00b8
            Enhanced Retransmission mode
            Streaming mode
            FCS Option
            Fixed Channels
< ACL data: handle 11 flags 0x00 dlen 10
        L2CAP(s): Command rej: reason 0
          Command not understood

Cc: stable@vger.kernel.org
Signed-off-by: Jaganath Kanakkassery <jaganath.k@samsung.com>
Signed-off-by: Chan-Yeol Park <chanyeol.park@samsung.com>
Acked-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Bluetooth: ath3k: Add support for Fujitsu Lifebook UH5x2 [04c5:1330]

The Fujitsu Lifebook UH552/UH572 ships with a Qualcomm AR9462/AR3012
WLAN/BT-Combo card.
Add device ID to the ath3k driver to enable the bluetooth side of things.
Patch against v3.10.

T:  Bus=03 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#=  3 Spd=12  MxCh= 0
D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=04c5 ProdID=1330 Rev=00.02
C:  #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I:  If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb

Signed-off-by: Thomas Loo <tloo@saltstorm.net>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Bluetooth: ath3k: don't use stack memory for DMA

Memory allocated by vmalloc (including stack) can not be used for DMA,
i.e. data pointer on usb_control_msg() should not point to stack memory.

Resolves:
https://bugzilla.redhat.com/show_bug.cgi?id=977558

Reported-and-tested-by: Andy Lawrence <dr.diesel@gmail.com>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Bluetooth: fix wrong use of PTR_ERR() in btusb

PTR_ERR() returns a signed long type value which is limited by IS_ERR(),
it must be a negative number whose range is [-MAX_ERRNO, 0).

The bug here returns negative numbers as error codes, then check it by
"if (ret < 0)", but -PTR_ERR() is actually positive. The wrong use here
leads to failure as below, even panic.

[   12.958920] Bluetooth: hci0 command 0xfc8e tx timeout
[   14.961765] Bluetooth: hci0 command 0xfc8e tx timeout
[   16.964688] Bluetooth: hci0 command 0xfc8e tx timeout
[   20.954501] Bluetooth: hci0 sending Intel patch command (0xfc8e) failed (-110)
[   22.957358] Bluetooth: hci0 command 0xfc8e tx timeout
[   30.948922] Bluetooth: hci0 sending Intel patch command (0xfc8e) failed (-110)
[   32.951780] Bluetooth: hci0 command 0xfc8e tx timeout
[   40.943359] Bluetooth: hci0 sending Intel patch command (0xfc8e) failed (-110)
[   42.946219] Bluetooth: hci0 command 0xfc8e tx timeout
[   50.937812] Bluetooth: hci0 sending Intel patch command (0xfc8e) failed (-110)
[   52.940670] Bluetooth: hci0 command 0xfc8e tx timeout
[   60.932236] Bluetooth: hci0 sending Intel patch command (0xfc8e) failed (-110)
[   62.935092] Bluetooth: hci0 command 0xfc8e tx timeout
[   70.926688] Bluetooth: hci0 sending Intel patch command (0xfc8e) failed (-110)
[   72.929545] Bluetooth: hci0 command 0xfc8e tx timeout
[   80.921111] Bluetooth: hci0 sending Intel patch command (0xfc8e) failed (-110)
[   82.923969] Bluetooth: hci0 command 0xfc2f tx timeout
[   90.915542] Bluetooth: hci0 sending Intel patch command (0xfc2f) failed (-110)
[   92.918406] Bluetooth: hci0 command 0xfc11 tx timeout
[  100.909955] Bluetooth: hci0 sending Intel patch command (0xfc11) failed (-110)
[  102.912858] Bluetooth: hci0 command 0xfc60 tx timeout
[  110.904394] Bluetooth: hci0 sending Intel patch command (0xfc60) failed (-110)
[  112.907293] Bluetooth: hci0 command 0xfc11 tx timeout
[  120.898831] Bluetooth: hci0 exiting Intel manufacturer mode failed (-110)
[  120.904757] bluetoothd[1030]: segfault at 4 ip 00007f8b2eb55236 sp 00007fff53ff6920 error 4 in bluetoothd[7f8b2eaff000+cb000]

Signed-off-by: Adam Lee <adam.lee@canonical.com>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Bluetooth: ath3k: Add support for ID 0x13d3/0x3402

T:  Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#=  5 Spd=12   MxCh= 0
D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=13d3 ProdID=3402 Rev= 0.02
S:  Manufacturer=Atheros Communications
S:  Product=Bluetooth USB Host Controller
S:  SerialNumber=Alaska Day 2006
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb

Bug: https://bugzilla.kernel.org/show_bug.cgi?id=59701

Signed-off-by: Sujith Manoharan <sujith@msujith.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Bluetooth: Add support for Atheros [0cf3:3121]

Add support for the AR3012 chip.

T:  Bus=03 Lev=01 Prnt=01 Port=06 Cnt=01 Dev#=  6 Spd=12  MxCh= 0
D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=0cf3 ProdID=3121 Rev=00.02
C:  #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I:  If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb

Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Bluetooth: Fix race between hci_register_dev() and hci_dev_open()

If hci_dev_open() is called after hci_register_dev() added the device to
the hci_dev_list but before the workqueue are created we could run into a
NULL pointer dereference (see below).

This bug is very unlikely to happen, systems using bluetoothd to
manage their bluetooth devices will never see this happen.

BUG: unable to handle kernel NULL pointer dereference
0100
IP: [<ffffffff81077502>] __queue_work+0x32/0x3d0
(...)
Call Trace:
 [<ffffffff81077be5>] queue_work_on+0x45/0x50
 [<ffffffffa016e8ff>] hci_req_run+0xbf/0xf0 [bluetooth]
 [<ffffffffa01709b0>] ? hci_init2_req+0x720/0x720 [bluetooth]
 [<ffffffffa016ea06>] __hci_req_sync+0xd6/0x1c0 [bluetooth]
 [<ffffffff8108ee10>] ? try_to_wake_up+0x2b0/0x2b0
 [<ffffffff8150e3f0>] ? usb_autopm_put_interface+0x30/0x40
 [<ffffffffa016fad5>] hci_dev_open+0x275/0x2e0 [bluetooth]
 [<ffffffffa0182752>] hci_sock_ioctl+0x1f2/0x3f0 [bluetooth]
 [<ffffffff815c6050>] sock_do_ioctl+0x30/0x70
 [<ffffffff815c75f9>] sock_ioctl+0x79/0x2f0
 [<ffffffff811a8046>] do_vfs_ioctl+0x96/0x560
 [<ffffffff811a85a1>] SyS_ioctl+0x91/0xb0
 [<ffffffff816d989d>] system_call_fastpath+0x1a/0x1f

Reported-by: Sedat Dilek <sedat.dilek@gmail.com>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>