platform/adaptation/renesas_rcar/renesas_kernel.git
11 years agoMerge tag 'nfc-next-3.13-1' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo...
John W. Linville [Fri, 18 Oct 2013 17:59:28 +0000 (13:59 -0400)]
Merge tag 'nfc-next-3.13-1' of git://git./linux/kernel/git/sameo/nfc-next

Samuel Ortiz <sameo@linux.intel.com> says:

"This is the first NFC pull request for the 3.13 kernel.
It's a fairly big one, with the following highlights:

- NFC digital layer implementation: Most NFC chipsets implement the NFC
  digital layer in firmware, but others have more basic functionalities
  and expect the host to implement the digital layer. This layer sits
  below the NFC core.

- Sony's port100 support: This is "soft" NFC USB dongle that expects the
  digital layer to be implemented on the host. This is the first user of
  our NFC digital stack implementation.

- Secure element API: We now provide a netlink API for enabling,
  disabling and discovering NFC attached (embedded or UICC ones) secure
  elements. With some userspace help, this allows us to support NFC
  payments.
  Only the pn544 driver currently supports that API.

- NCI SPI fixes and improvements: In order to support NCI devices over
  SPI, we fixed and improved our NCI/SPI implementation. The currently
  most deployed NFC NCI chipset, Broadcom's bcm2079x, supports that mode
  and we're planning to use our NCI/SPI framework to implement a
  driver for it.

- pn533 fragmentation support in target mode: This was the only missing
  feature from our pn533 impementation. We now support fragmentation in
  both Tx and Rx modes, in target mode."

Signed-off-by: John W. Linville <linville@tuxdriver.com>
11 years agoMerge branch 'for-john' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi...
John W. Linville [Fri, 18 Oct 2013 17:58:13 +0000 (13:58 -0400)]
Merge branch 'for-john' of git://git./linux/kernel/git/iwlwifi/iwlwifi-next

11 years agoMerge branch 'for-linville' of git://github.com/kvalo/ath
John W. Linville [Fri, 18 Oct 2013 17:57:09 +0000 (13:57 -0400)]
Merge branch 'for-linville' of git://github.com/kvalo/ath

11 years agoMerge branch 'for-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetoot...
John W. Linville [Fri, 18 Oct 2013 17:56:17 +0000 (13:56 -0400)]
Merge branch 'for-upstream' of git://git./linux/kernel/git/bluetooth/bluetooth-next

11 years agoiwlwifi: mvm: fix operator precedence
David Spinadel [Thu, 17 Oct 2013 06:49:12 +0000 (09:49 +0300)]
iwlwifi: mvm: fix operator precedence

Integers need to be multiplied before division.

Signed-off-by: David Spinadel <david.spinadel@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
11 years agoiwlwifi: mvm: fix fw_rx_stats debugfs entry
Luciano Coelho [Mon, 14 Oct 2013 10:18:41 +0000 (13:18 +0300)]
iwlwifi: mvm: fix fw_rx_stats debugfs entry

The fw_rx_stats entry in debugfs was getting truncated because the
internal buffer used to hold the string was too short.  The
calculation of the needed buffer size was rather bogus.

Simplify the calculation by multiplying the number of entries in the
entire structure by the size of each data line and adding the size of
the header lines.

Additionally, add the mac_id value, which was missing.

Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
11 years agoiwlwifi: mvm: BT Coex - enable Tx power based on BT status
Emmanuel Grumbach [Tue, 15 Oct 2013 09:37:38 +0000 (12:37 +0300)]
iwlwifi: mvm: BT Coex - enable Tx power based on BT status

The activity grading indication from the firmware should
not be used in this case, but the bt_status in the firwmare
notification.
Fix that.

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
11 years agoiwlwifi: mvm: BT Coex - always set mandatory fields
Emmanuel Grumbach [Mon, 14 Oct 2013 15:52:23 +0000 (18:52 +0300)]
iwlwifi: mvm: BT Coex - always set mandatory fields

The firmware always expects the Coex Mode to be set.
Moreover, the firmware expects bit 0 is the valid bits to
be set all the times.
I misunderstood the API and didn't set these bits when
commands are sent to update the paramters of the Coex. As
a result, the firmware understood that the BT Coex was
disabled (Coex mode = 0) and ignored all the updates (valid
bit 0 clear).

Fix that.

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
11 years agoiwlwifi: mvm: NVM - increase max section size
Idan Kahlon [Wed, 9 Oct 2013 14:09:13 +0000 (16:09 +0200)]
iwlwifi: mvm: NVM - increase max section size

Section size limitation to 6000 is incorrect.
NVM file need to support bigger sections in order
to support PAPD tables.

Signed-off-by: Idan Kahlon <idanx.kahlon@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Reviewed-by: Maor Perez <maorx.perez@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
11 years agoath10k: add might_sleep() to ath10k_wmi_cmd_send()
Kalle Valo [Wed, 16 Oct 2013 12:44:47 +0000 (15:44 +0300)]
ath10k: add might_sleep() to ath10k_wmi_cmd_send()

ath10k_wmi_cmd_send() will now sleep if there are no credits available.
To make it easier to catch callers in atomic context add might_sleep()
to the function.

Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
11 years agoath10k: fix ath10k_bss_assoc() to not sleep in atomic context
Kalle Valo [Wed, 16 Oct 2013 12:44:46 +0000 (15:44 +0300)]
ath10k: fix ath10k_bss_assoc() to not sleep in atomic context

ath10k_bss_assoc() was calling ath10k_peer_assoc(), which can sleep, under
atomic rcu_read_lock() and causing scheduing while atomic errors. Workaround
that by delaying the call to ath10k_wmi_peer_assoc().

Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
11 years agoath10k: remove unnecessary checks
Michal Kazior [Wed, 16 Oct 2013 12:44:46 +0000 (15:44 +0300)]
ath10k: remove unnecessary checks

mac80211 interface iteration functions that were
used originally iterated over interfaces that
weren't re-added to the driver during recovery.

Since internal vif list is now used it's safe to
remove the safe-guard as internal vif list is
based on add/remove_interface function which
guarantees that vdev is created in FW before it is
iterated over.

Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
11 years agoath10k: fix scheduling while atomic config bug
Michal Kazior [Wed, 16 Oct 2013 12:44:46 +0000 (15:44 +0300)]
ath10k: fix scheduling while atomic config bug

Recent HTC/WMI changes introduced the bug. ath10k
was using _atomic iteration function with
sleepable functions.

mac80211 provides another iteration function but
it cannot be safely called in hw_config() callback
due to local->iflist_mtx being possibly acquired
already.

The patch uses internal vif list for iteration
purposes and removes/refactors no longer necessary
_iter functions.

Reported-By: Kalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
11 years agoath10k: track vif list internally
Michal Kazior [Wed, 16 Oct 2013 12:44:45 +0000 (15:44 +0300)]
ath10k: track vif list internally

mac80211 interface interations functions have
peculiar locking issues. This patch introduces
internal (to ath10k) vif list that will be used
for vif iteration purposes.

kvalo: remove extra INIT_LIST_HEAD()

Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
11 years agoath10k: fix add_interface failure handling
Michal Kazior [Wed, 16 Oct 2013 12:44:45 +0000 (15:44 +0300)]
ath10k: fix add_interface failure handling

If something failed along add_interface() setup it
was possible to leak a vdev id, vdev and peer.

This could end up with leaked FW state or FW crash
(assuming add_interface() failure wasn't a result of
a crash).

kvalo: rebased, whitespace fixes

Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
11 years agoath10k: use workqueue to set WEP TX key
Michal Kazior [Wed, 16 Oct 2013 12:44:45 +0000 (15:44 +0300)]
ath10k: use workqueue to set WEP TX key

Recent WMI/HTC changes made it possible for WMI
commands to sleep (if there's not enough HTC TX
credits to submit a command). TX path is in an
atomic context so calling WMI commands in it is
wrong.

This simply moves WEP key index update to a worker
and fixes the 'scheduling while atomic' bug.

This still leaves multiple WEP key handling laggy,
i.e. some frames may be TXed with an old/different
key (although recipient should still be able to RX
them).

kvalo: changed the title

Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
11 years agoath10k: return better errno for unsupported pdev params
Bartosz Markowski [Tue, 15 Oct 2013 07:55:32 +0000 (09:55 +0200)]
ath10k: return better errno for unsupported pdev params

Return -EOPNOTSUPP if given parameter is not supported by firmware.

Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
11 years agoath10k: rename WMI_CMD_UNDEFINED
Bartosz Markowski [Tue, 15 Oct 2013 07:55:31 +0000 (09:55 +0200)]
ath10k: rename WMI_CMD_UNDEFINED

Rename WMI_CMD_UNDEFINED to WMI_CMD_UNSUPPORTED. This is more
accurate here. Also return -EOPNOTSUPP instead of -EINVAL in
wmi_cmd_send().

Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
11 years agoath10k: do not warn about unsupported vdev param
Bartosz Markowski [Tue, 15 Oct 2013 07:26:20 +0000 (09:26 +0200)]
ath10k: do not warn about unsupported vdev param

10.X firmware does not support WMI_VDEV_PARAM_TX_ENCAP_TYPE.
It's a known limitation and we should not warn about this.

Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
11 years agoBluetooth: Read current IAC LAP on controller setup
Marcel Holtmann [Mon, 14 Oct 2013 21:06:36 +0000 (14:06 -0700)]
Bluetooth: Read current IAC LAP on controller setup

Read the current IAC LAP values when initializing the controller. The
values are not used, but it is good to have them in the trace files
for debugging purposes.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
11 years agoBluetooth: Read number of supported IAC on controller setup
Marcel Holtmann [Mon, 14 Oct 2013 20:56:16 +0000 (13:56 -0700)]
Bluetooth: Read number of supported IAC on controller setup

When initializing a controller make sure to read out the number of
supported IAC and store its result. This value is needed to determine
if limited discoverable for BR/EDR can be configured or not.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
11 years agoBluetooth: Check that scan window is smaller or equal than scan interval
Marcel Holtmann [Mon, 14 Oct 2013 16:55:32 +0000 (09:55 -0700)]
Bluetooth: Check that scan window is smaller or equal than scan interval

The scan window parameter for connection establishment and passive
scanning needs to be smaller or equal than the scan interval.

Instead of waiting for a controller to reject these values later on,
just reject them right away.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Check that bind() bdaddr type matches connect()
Johan Hedberg [Mon, 14 Oct 2013 18:17:53 +0000 (21:17 +0300)]
Bluetooth: Check that bind() bdaddr type matches connect()

If a socket was bound to an address type other than BR/EDR (such as LE)
we should reject trying to connect it to a BR/EDR address. The same
applies for binding to BR/EDR and trying to connect to non-BR/EDR.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
11 years agoBluetooth: Reject invalid bdaddr types for sockets
Johan Hedberg [Mon, 14 Oct 2013 18:17:52 +0000 (21:17 +0300)]
Bluetooth: Reject invalid bdaddr types for sockets

We need to verify that the bdaddr type passed to connect() and bind() is
within the set of valid values. If it is not we need to cleanly fail
with EINVAL.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
11 years agoBluetooth: Convert Set Discoverable to use an asynchronous request
Johan Hedberg [Mon, 14 Oct 2013 18:15:27 +0000 (21:15 +0300)]
Bluetooth: Convert Set Discoverable to use an asynchronous request

This patch converts Set Discoverable to use an asynchronous request
along with its own completion callback. This is necessary for splitting
raw HCI socket use cases from mgmt, as well as for enabling the hooking
up of Advertising parameters together with the HCI_DISCOVERABLE flag
(coming in later patches).

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
11 years agoBluetooth: Fix updating scan mode in set_bredr()
Johan Hedberg [Mon, 14 Oct 2013 18:15:26 +0000 (21:15 +0300)]
Bluetooth: Fix updating scan mode in set_bredr()

Now that the connectable setting is also applicable for the LE side it's
possible that the HCI_CONNECTABLE flag is already set when changing the
BR/EDR setting from false to true while the controller is powered. In
this situation we need to update the BR/EDR scan mode to reflect the
setting. Additionally, since HCI_CONNECTABLE also applies to LE we must
not clear the HCI_CONNECTABLE flag when disabling bredr.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
11 years agoBluetooth: Move set_bredr_scan() to avoid forward declaration
Johan Hedberg [Mon, 14 Oct 2013 18:15:25 +0000 (21:15 +0300)]
Bluetooth: Move set_bredr_scan() to avoid forward declaration

The set_bredr_scan() function will soon be needed by the set_bredr()
function, so move it to a new location to avoid having to add a forward
declaration.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
11 years agoBluetooth: Make Set Connectable also update the LE advertising type
Johan Hedberg [Mon, 14 Oct 2013 18:15:24 +0000 (21:15 +0300)]
Bluetooth: Make Set Connectable also update the LE advertising type

This patch updates the Set Connectable Management command to also update
the LE advertising type to either connectable or non-connectable
advertising. An extra helper function is needed for getting the right
advertising type since we can not only rely on the HCI_CONNECTABLE flag
but must also check for a pending Set Connectable command (in which case
the flag does not yet have its final value).

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
11 years agort2x00: rt2800lib: remove duplicate rf_vals for RF3053
Kevin Lo [Mon, 14 Oct 2013 02:05:45 +0000 (10:05 +0800)]
rt2x00: rt2800lib: remove duplicate rf_vals for RF3053

lready have rf_vals_3x with same values.  Hence rf_vals_3053 is removed
in this patch.

Signed-off-by: Kevin Lo <kevlo@kevlo.org>
Acked-by: Paul Menzel <paulepanter@users.sourceforge.net>
Acked-by: Stanislaw Gruszka <stf_xl@wp.pl>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
11 years agort2x00: rt2800lib: fix RF registers for RT5390/RT5392
Kevin Lo [Sat, 12 Oct 2013 15:25:23 +0000 (23:25 +0800)]
rt2x00: rt2800lib: fix RF registers for RT5390/RT5392

Update rf registers to use the same values that the MediaTek/Ralink
reference driver DPO_RT5572_LinuxSTA_2.6.1.3_20121022 uses.

References:
  RF5390RegTable in chips/rt5390.c
  RF5392RegTable in chips/rt5390.c

Tested on TP-Link TL-WN727N and D-Link DWA-140 Rev.b3 usb wifi dongles.

Signed-off-by: Kevin Lo <kevlo@kevlo.org>
Acked-by: Stanislaw Gruszka <stf_xl@wp.pl>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
11 years agomwifiex: use alloc_workqueue() function
Amitkumar Karwar [Sat, 12 Oct 2013 01:33:04 +0000 (18:33 -0700)]
mwifiex: use alloc_workqueue() function

It replaces deprecated create_workqueue().

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>
11 years agoath9k_hw: remove references to hw->conf
Felix Fietkau [Fri, 11 Oct 2013 21:31:01 +0000 (23:31 +0200)]
ath9k_hw: remove references to hw->conf

Accessing it to get the current operating channel is racy and in the way
of further channel handling related changes

Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
11 years agoath9k: make ath9k_uses_beacons static
Felix Fietkau [Fri, 11 Oct 2013 21:31:00 +0000 (23:31 +0200)]
ath9k: make ath9k_uses_beacons static

Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
11 years agoath9k: remove sc->config.cabqReadyTime
Felix Fietkau [Fri, 11 Oct 2013 21:30:59 +0000 (23:30 +0200)]
ath9k: remove sc->config.cabqReadyTime

It is not exposed as a configuration option anyway

Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
11 years agoath9k: move channel change code to ath_set_channel
Felix Fietkau [Fri, 11 Oct 2013 21:30:58 +0000 (23:30 +0200)]
ath9k: move channel change code to ath_set_channel

Preparation for adding the scanning state machine to ath9k

Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
11 years agoath9k: make ath9k_cmn_update_ichannel static
Felix Fietkau [Fri, 11 Oct 2013 21:30:57 +0000 (23:30 +0200)]
ath9k: make ath9k_cmn_update_ichannel static

Rework its wrapper function to make it more generic, using it as a
replacement for previous calls to ath9k_cmn_update_ichannel.

Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
11 years agoath9k_hw: simplify channel flags
Felix Fietkau [Fri, 11 Oct 2013 21:30:56 +0000 (23:30 +0200)]
ath9k_hw: simplify channel flags

There was some duplication between channelFlags and chanmode, as well as
a lot of redundant checks based on the combinations of flags.

Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
11 years agoath9k_hw: remove IS_CHAN_OFDM()
Felix Fietkau [Fri, 11 Oct 2013 21:30:55 +0000 (23:30 +0200)]
ath9k_hw: remove IS_CHAN_OFDM()

The hardware is always configured with OFDM support enabled

Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
11 years agoath9k_hw: remove IS_CHAN_B()
Felix Fietkau [Fri, 11 Oct 2013 21:30:54 +0000 (23:30 +0200)]
ath9k_hw: remove IS_CHAN_B()

Hardware 802.11b-only mode isn't supported by the driver (the device is
configured for 802.11n/g instead). Simplify the code by removing checks
for it.

Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
11 years agoath9k_hw: remove direct accesses to channel mode flags
Felix Fietkau [Fri, 11 Oct 2013 21:30:53 +0000 (23:30 +0200)]
ath9k_hw: remove direct accesses to channel mode flags

Use wrappers where available. Simplifies code and helps with further
improvements to the channel data structure

Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
11 years agoath9k: use a separate data structure for rx buffers
Felix Fietkau [Fri, 11 Oct 2013 21:30:52 +0000 (23:30 +0200)]
ath9k: use a separate data structure for rx buffers

There's no shared code for handling both rx and tx buffers, and tx
buffers require a lot more metadata than rx buffers.
Using a separate data structure for rx reduces memory usage and improves
cache footprint.

Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
11 years agowcn36xx: fix coccinelle warnings
Fengguang Wu [Fri, 11 Oct 2013 15:30:26 +0000 (23:30 +0800)]
wcn36xx: fix coccinelle warnings

drivers/net/wireless/ath/wcn36xx/debug.c:27:11-31: WARNING opportunity for simple_open, see also structure on line 106
/c/kernel-tests/src/i386/drivers/net/wireless/ath/wcn36xx/debug.c:27:11-31: WARNING opportunity for simple_open, see also structure on line 148

 This removes an open coded simple_open() function
 and replaces file operations references to the function
 with simple_open() instead.

Generated by: coccinelle/api/simple_open.cocci

CC: Eugene Krasnikov <k.eugene.e@gmail.com>
CC: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
11 years agort2x00: rt73usb: use rt2x00_has_cap_* helpers
Gabor Juhos [Fri, 11 Oct 2013 11:18:44 +0000 (13:18 +0200)]
rt2x00: rt73usb: use rt2x00_has_cap_* helpers

Use the appropriate helper functions instead of
directly accessing the rt2x00dev->cap_flags field
to check device capability flags.

This improves readability of the code a bit.

Compile tested only.

Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
11 years agort2x00: rt61pci: use rt2x00_has_cap_* helpers
Gabor Juhos [Fri, 11 Oct 2013 11:18:43 +0000 (13:18 +0200)]
rt2x00: rt61pci: use rt2x00_has_cap_* helpers

Use the appropriate helper functions instead of
directly accessing the rt2x00dev->cap_flags field
to check device capability flags.

This improves readability of the code a bit.

Compile tested only.

Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
11 years agort2x00: rt2800lib: use rt2x00_has_cap_* helpers
Gabor Juhos [Fri, 11 Oct 2013 11:18:42 +0000 (13:18 +0200)]
rt2x00: rt2800lib: use rt2x00_has_cap_* helpers

Use the appropriate helper functions instead of
directly accessing the rt2x00dev->cap_flags field
to check device capability flags.

This improves readability of the code a bit.

Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
11 years agort2x00: rt2x00lib: use rt2x00_has_cap_* helpers
Gabor Juhos [Fri, 11 Oct 2013 11:18:41 +0000 (13:18 +0200)]
rt2x00: rt2x00lib: use rt2x00_has_cap_* helpers

Use the appropriate helper functions instead of
directly accessing the rt2x00dev->cap_flags field
to check device capability flags.

This improves readability of the code a bit.

Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
11 years agort2x00: add rt2x00_has_cap_* helpers
Gabor Juhos [Fri, 11 Oct 2013 11:18:40 +0000 (13:18 +0200)]
rt2x00: add rt2x00_has_cap_* helpers

The rt2x00 code directly accesses the 'cap_flags'
field of 'struct rt2x00_dev' when checking presence
of a given capability flag. The direct access needs
long expressions which lowers readability of the code.

Add a few helper functions which can be used to test
device capabilities without directly accessing the
cap_flags filed.

Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
11 years agort2x00: cleanup indentation in rt2800.h
Gabor Juhos [Fri, 11 Oct 2013 10:50:08 +0000 (12:50 +0200)]
rt2x00: cleanup indentation in rt2800.h

Adjust whitespaces to move badly aligned constants
to the right column.

The patch contains no functional changes.

Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
11 years agoBluetooth: Fix updating advertising data needlessly
Johan Hedberg [Mon, 14 Oct 2013 13:20:07 +0000 (16:20 +0300)]
Bluetooth: Fix updating advertising data needlessly

We need to ensure that the advertising data is up-to-date whenever
advertising is enabled, but when disabling advertising we do not need to
worry about it (since it will eventually get fixed as soon as
advertising is enabled again). This patch fixes this in the command
complete callback for set_adv_enable.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
11 years agoBluetooth: Move static advertising functions to avoid forward declarations
Johan Hedberg [Mon, 14 Oct 2013 13:20:06 +0000 (16:20 +0300)]
Bluetooth: Move static advertising functions to avoid forward declarations

These functions will soon be used by set_connectable() so move them to a
location in mgmt.c that doesn't require forward declarations.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
11 years agoBluetooth: Add missing error handling for Set Connectable
Johan Hedberg [Mon, 14 Oct 2013 13:20:05 +0000 (16:20 +0300)]
Bluetooth: Add missing error handling for Set Connectable

If the HCI commands related to the Set Connectable command fail we will
get a non-zero status in the request completion callback. In such a case
we must respond with the appropriate command status message to user space.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
11 years agoBluetooth: Move more logic into set_connectable complete callback
Johan Hedberg [Mon, 14 Oct 2013 13:20:04 +0000 (16:20 +0300)]
Bluetooth: Move more logic into set_connectable complete callback

This patch moves the responsibility of setting/clearing the
HCI_CONNECTABLE flag to the request completion callback of the Set
Connectable command. This will allow us to cleanly add support for LE
Advertising hooks in later patches.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
11 years agoBluetooth: Reorganize set_connectable HCI command sending
Johan Hedberg [Mon, 14 Oct 2013 13:20:03 +0000 (16:20 +0300)]
Bluetooth: Reorganize set_connectable HCI command sending

This patch moves all the decisions of which HCI commands to send (or not
to send) to the code between hci_req_init() and hci_req_run() this
allows us to further extend the request with further commands but still
keep the same logic of handling whether to return a direct mgmt response
in the case that no HCI commands were sent.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
11 years agoBluetooth: Introduce L2CAP channel callback for resuming
Marcel Holtmann [Mon, 14 Oct 2013 09:53:54 +0000 (02:53 -0700)]
Bluetooth: Introduce L2CAP channel callback for resuming

Clearing the BT_SK_SUSPEND socket flag from the L2CAP core is causing
a dependency on the socket. So intead of doing that, use a channel
callback into the socket handling to resume.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Introduce L2CAP channel flag for defer setup
Marcel Holtmann [Mon, 14 Oct 2013 09:45:34 +0000 (02:45 -0700)]
Bluetooth: Introduce L2CAP channel flag for defer setup

The L2CAP core should not look into the socket flags to figure out the
setting of defer setup. So introduce a L2CAP channel flag that mirrors
the socket flag.

Since the defer setup option is only set in one place this becomes a
really easy thing to do.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Adjust header for proc socket information
Marcel Holtmann [Mon, 14 Oct 2013 09:05:25 +0000 (02:05 -0700)]
Bluetooth: Adjust header for proc socket information

The exposed socket information do not contain source or destination
addresses. So adjust the header accordingly.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Increase minor version of core module
Marcel Holtmann [Sun, 13 Oct 2013 20:09:02 +0000 (13:09 -0700)]
Bluetooth: Increase minor version of core module

There have been a lot of changes in the core Bluetooth handling
lately. So it is a good idea to increase the module version.

The module version is not used anywhere, but it makes debugging
a little bit simpler if versions can be distinguished.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Provide msg_name callback for L2CAP connectionless channels
Marcel Holtmann [Sun, 13 Oct 2013 19:55:29 +0000 (12:55 -0700)]
Bluetooth: Provide msg_name callback for L2CAP connectionless channels

The L2CAP connectionless channels use SOCK_DGRAM and recvmsg() and need
to receive the remote BD_ADDR and PSM information via msg_name from
the recvmsg() system call.

So in case the L2CAP socket is for connectionless channels, provide
a msg_name callback that can update the data. Also store the remote
BD_ADDR and PSM in the skb so it can be extracted later on.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Add support for per socket msg_name callback
Marcel Holtmann [Sun, 13 Oct 2013 19:55:28 +0000 (12:55 -0700)]
Bluetooth: Add support for per socket msg_name callback

This allows to add a per socket msg_name callback that can be used
for updating the msg_name information for recvmsg() system calls.

This feature is used by another patch to support address information
on L2CAP connectionless channels.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Use l2cap_pi(sk) directly where possible
Marcel Holtmann [Sun, 13 Oct 2013 18:36:07 +0000 (11:36 -0700)]
Bluetooth: Use l2cap_pi(sk) directly where possible

There are few places where it makes sense to use l2cap_pi(sk) directly
instead of assigning it to temporary structure.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Remove src and dst fields from bt_sock structure
Marcel Holtmann [Sun, 13 Oct 2013 17:34:03 +0000 (10:34 -0700)]
Bluetooth: Remove src and dst fields from bt_sock structure

Every socket protocol now stores its own address information. So
just remove the generic src and dst fields since they are no longer
needed.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Store RFCOMM address information in its own socket structure
Marcel Holtmann [Sun, 13 Oct 2013 17:34:02 +0000 (10:34 -0700)]
Bluetooth: Store RFCOMM address information in its own socket structure

The address information of RFCOMM sockets should be stored in its
own socket structure. Trying to generalize them is not helpful since
different transports have different address types.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Store SCO address information in its own socket structure
Marcel Holtmann [Sun, 13 Oct 2013 17:34:01 +0000 (10:34 -0700)]
Bluetooth: Store SCO address information in its own socket structure

The address information of SCO sockets should be stored in its own
socket structure. Trying to generalize them is not helpful since
different transports have different address types.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Use SCO addresses from HCI connection directly
Marcel Holtmann [Sun, 13 Oct 2013 17:15:22 +0000 (10:15 -0700)]
Bluetooth: Use SCO addresses from HCI connection directly

Instead of storing a pointer to the addresses for the HCI device
and HCI connection, use them directly. With the recent changes
to address tracking of HCI connections, this becomes simple.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Access BNEP session addresses through L2CAP channel
Marcel Holtmann [Sun, 13 Oct 2013 16:49:57 +0000 (09:49 -0700)]
Bluetooth: Access BNEP session addresses through L2CAP channel

The L2CAP socket structure does not contain the address information
anymore. They need to be accessed through the L2CAP channel.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Access HIDP session addresses through L2CAP channel
Marcel Holtmann [Sun, 13 Oct 2013 16:49:56 +0000 (09:49 -0700)]
Bluetooth: Access HIDP session addresses through L2CAP channel

The L2CAP socket structure does not contain the address information
anymore. They need to be accessed through the L2CAP channel.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Access CMTP session addresses through L2CAP channel
Marcel Holtmann [Sun, 13 Oct 2013 16:49:55 +0000 (09:49 -0700)]
Bluetooth: Access CMTP session addresses through L2CAP channel

The L2CAP socket structure does not contain the address information
anymore. They need to be accessed through the L2CAP channel.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Access RFCOMM session addresses through L2CAP channel
Marcel Holtmann [Sun, 13 Oct 2013 16:49:54 +0000 (09:49 -0700)]
Bluetooth: Access RFCOMM session addresses through L2CAP channel

The L2CAP socket structure does not contain the address information
anymore. They need to be accessed through the L2CAP channel.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Return the correct address type for L2CAP sockets
Marcel Holtmann [Sun, 13 Oct 2013 15:50:41 +0000 (08:50 -0700)]
Bluetooth: Return the correct address type for L2CAP sockets

The L2CAP sockets can use BR/EDR public, LE public and LE random
addresses for various combinations of source and destination
devices. So make sure that getsockname(), getpeername() and
accept() return the correct address type.

For this the address type of the source and destination is stored
with the L2CAP channel information. The stored address type is
not the one specific for the HCI protocol. It is the address
type used for the L2CAP sockets and the management interface.

The underlying HCI connections store the HCI address type. If
needed, it gets converted to the socket address type.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Store address information in L2CAP channel structure
Marcel Holtmann [Sun, 13 Oct 2013 15:12:47 +0000 (08:12 -0700)]
Bluetooth: Store address information in L2CAP channel structure

With the effort of abstracting the L2CAP socket from the underlying
L2CAP channel it is important to store the source and destination
address information directly in the L2CAP channel structure.

Direct access to the HCI connection address information is not
possible since they might not be avaiable at L2CAP channel
creation time. The address information will be updated when
the underlying BR/EDR or LE connection status changes.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Update L2CAP socket source address from HCI connection
Marcel Holtmann [Sun, 13 Oct 2013 12:56:37 +0000 (05:56 -0700)]
Bluetooth: Update L2CAP socket source address from HCI connection

When having LE connections, the source address is not always the
public address of the controller. So update the socket address
based on the actual used source address of the HCI connection.

This also remove the pointless source address pointer and adds
a proper lock around the socket structure.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Fix coding style violations in SMP handling
Marcel Holtmann [Sun, 13 Oct 2013 12:43:25 +0000 (05:43 -0700)]
Bluetooth: Fix coding style violations in SMP handling

The SMP source code has a few coding style violations. Fix them up
all at once. No actual code has changed.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Fix input address type for SMP C1 function
Marcel Holtmann [Sun, 13 Oct 2013 12:24:02 +0000 (05:24 -0700)]
Bluetooth: Fix input address type for SMP C1 function

The smp_c1() so far always assumed public addresses as input for its
operation. However it should provide actually the source address type
of the actual connection.

Finally the source address type is tracked in hci_conn->src_type and
so use that one as input.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Use hci_conn->src address for L2CAP functions
Marcel Holtmann [Sun, 13 Oct 2013 12:24:01 +0000 (05:24 -0700)]
Bluetooth: Use hci_conn->src address for L2CAP functions

The source address is now stored in hci_conn->src and so use that
one for L2CAP functions.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Use hci_conn->src address for SMP functions
Marcel Holtmann [Sun, 13 Oct 2013 12:24:00 +0000 (05:24 -0700)]
Bluetooth: Use hci_conn->src address for SMP functions

The source address is now stored in hci_conn->src and so use that
one for SMP functions.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Update source address and type for incoming LE connections
Marcel Holtmann [Sun, 13 Oct 2013 14:25:18 +0000 (07:25 -0700)]
Bluetooth: Update source address and type for incoming LE connections

The incoming LE connections do not have a proper source address and
address type set. The connection needs to be set with the same values
as used for advertising parameters.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Store source address of HCI connections
Marcel Holtmann [Sun, 13 Oct 2013 12:23:59 +0000 (05:23 -0700)]
Bluetooth: Store source address of HCI connections

The source addressed was based on the public address of the HCI device,
but with LE connections this not always the case. For example single
mode LE-only controllers would use a static random address. And this
address is configured by userspace.

To not complicate the lookup of what kind of address is in use, store
the correct source address for each HCI connection.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Store the source address type of LE connections
Marcel Holtmann [Sun, 13 Oct 2013 10:57:39 +0000 (03:57 -0700)]
Bluetooth: Store the source address type of LE connections

When establishing LE connections, it is possible to use a public
address (if available) or a random address. The type of address
is only known when creating connections, so make sure it is
stored in hci_conn structure.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Remove pointless bdaddr_to_le() helper function
Marcel Holtmann [Sun, 13 Oct 2013 10:57:38 +0000 (03:57 -0700)]
Bluetooth: Remove pointless bdaddr_to_le() helper function

The bdaddr_to_le() function tries to convert the internal address
type to one that matches the HCI address type for LE. It does not
handle any address types not used by LE and in the end just make
the code a lot harder to read.

So instead of just hiding behind a magic function, just convert
the internal address type where it needs to be converted. And it
turns out that these are only two cases anyway. One when creating
new LE connections and the other when loading the long term keys.
In both cases this makes it more clear on what it going on.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Remove l2cap_conn->src and l2cap_conn->dst pointers
Marcel Holtmann [Sun, 13 Oct 2013 09:23:41 +0000 (02:23 -0700)]
Bluetooth: Remove l2cap_conn->src and l2cap_conn->dst pointers

The l2cap_conn->src and l2cap_conn->dst pointers are no longer in use
and so just remove them.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Remove l2cap_conn->src and l2cap_conn->dst usage from L2CAP
Marcel Holtmann [Sun, 13 Oct 2013 09:23:40 +0000 (02:23 -0700)]
Bluetooth: Remove l2cap_conn->src and l2cap_conn->dst usage from L2CAP

The l2cap_conn->src and l2cap_conn->dst addresses are just a pointers
to hci_conn structure. Use hci_conn->hdev->bdaddr and hci_conn->dst
directly instead.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Remove l2cap_conn->src and l2cap_conn->dst usage from SMP
Marcel Holtmann [Sun, 13 Oct 2013 09:23:39 +0000 (02:23 -0700)]
Bluetooth: Remove l2cap_conn->src and l2cap_conn->dst usage from SMP

The l2cap_conn->src and l2cap_conn->dst addresses are just a pointer
to hci_conn->hdev->bdaddr and hci_conn->dst structures. Use the data
provided by hci_conn directly. This is done for hci_conn->dst_type
already anyway and with this change it makes it a lot clearer were
the address information comes from.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Remove l2cap_conn->dst usage from AMP manager
Marcel Holtmann [Sun, 13 Oct 2013 09:23:38 +0000 (02:23 -0700)]
Bluetooth: Remove l2cap_conn->dst usage from AMP manager

The l2cap_conn->dst address is just a pointer into the hci_conn->dst
structure. Use hci_conn->dst directly instead.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Unicast connectionless data reception is supported
Marcel Holtmann [Sat, 12 Oct 2013 15:18:19 +0000 (08:18 -0700)]
Bluetooth: Unicast connectionless data reception is supported

The unicast connectionless data reception feature is actually support
and has been supported all along. Mark it as supported in the L2CAP
features bitmask.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: The L2CAP fixed channel connectionless data is supported
Marcel Holtmann [Sat, 12 Oct 2013 15:18:18 +0000 (08:18 -0700)]
Bluetooth: The L2CAP fixed channel connectionless data is supported

The implementation actually supports the L2CAP connectionless data
channel. So set it as supported in the fixed channels bitmask.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Allow 3D profile to use security mode 4 level 0
Marcel Holtmann [Sat, 12 Oct 2013 14:19:32 +0000 (07:19 -0700)]
Bluetooth: Allow 3D profile to use security mode 4 level 0

The PSM 0x0021 is dedicated to the 3D profile and has permission to
use security mode 4 level 0 for L2CAP connectionless unicast data
transfers.

When establishing a L2CAP connectionless channel on PSM 0x0021, it
will no longer force Secure Simple Pairing.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Limit security mode 4 level 0 to connection oriented channels
Marcel Holtmann [Sat, 12 Oct 2013 14:19:31 +0000 (07:19 -0700)]
Bluetooth: Limit security mode 4 level 0 to connection oriented channels

The exception for certain PSM channels when it comes to security
mode 4 level 0 should only be checked when actually a connection
oriented channel is established.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Fix PSM value for L2CAP connectionless data packets
Marcel Holtmann [Sat, 12 Oct 2013 13:01:26 +0000 (06:01 -0700)]
Bluetooth: Fix PSM value for L2CAP connectionless data packets

The put_unaligned() for setting the PSM is missing the (__le16 *)
cast. Without this, the PSM information transmitted over the air
are bogus.

In addition, print the used PSM value in the debug message so this
becomes easier to debug in the future.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Fix HCI init for 1st generation BlueFRITZ! devices
Marcel Holtmann [Fri, 11 Oct 2013 23:42:07 +0000 (16:42 -0700)]
Bluetooth: Fix HCI init for 1st generation BlueFRITZ! devices

The 1st generation of BlueFRITZ! devices from AVM Berlin pretend
to be HCI version 1.2 controllers, but they are not. They are simple
Bluetooth 1.1 devices.

Since this company never created any newer controllers, it is safe
to use the manufacturer ID instead of an USB quirk.

< HCI Command: Read Page Scan Activity (0x03|0x001b) plen 0
> HCI Event: Command Complete (0x0e) plen 8
      Read Page Scan Activity (0x03|0x001b) ncmd 1
        Status: Success (0x00)
        Interval: 1280.000 msec (0x0800)
        Window: 21.250 msec (0x0022)
< HCI Command: Read Page Scan Type (0x03|0x0046) plen 0
> HCI Event: Command Status (0x0f) plen 4
      Read Page Scan Type (0x03|0x0046) ncmd 1
        Status: Unknown HCI Command (0x01)

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Add MGMT_OP_SET_SCAN_PARAMS to supported commands list
Marcel Holtmann [Fri, 11 Oct 2013 21:44:58 +0000 (14:44 -0700)]
Bluetooth: Add MGMT_OP_SET_SCAN_PARAMS to supported commands list

When adding support for MGMT_OP_SET_SCAN_PARAMS command the addition
to the supported commands list has been forgotten. This is needed
for userspace to detect if the command is supported or not.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Don't advertise high speed support without SSP
Marcel Holtmann [Fri, 11 Oct 2013 16:48:47 +0000 (09:48 -0700)]
Bluetooth: Don't advertise high speed support without SSP

It is not allowed to enable high speed support when Secure Simple
Pairing is not available or disabled.

However the support for high speed gets advertised on a controller
that does not even support Secure Simple Pairing. Since there is
no way to enable high speed support on such a controller, do not
even advertise its support.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Fix endless loop with HCI_QUIRK_RESET_ON_CLOSE
Marcel Holtmann [Fri, 11 Oct 2013 16:44:12 +0000 (09:44 -0700)]
Bluetooth: Fix endless loop with HCI_QUIRK_RESET_ON_CLOSE

Really early versions of the Bluetooth specification were unclear
with the behavior of HCI Reset for USB devices. They assumed that
also an USB reset needs to be issued. Later Bluetooth specifications
cleared this out and it is safe to call HCI Reset without affecting
the transport.

For old devices that misbehave, the HCI_QUIRK_RESET_ON_CLOSE quirk
was introduced to postpone the HCI Reset until the device was no
longer in use.

One of these devices is the Digianswer BPA-105 Bluetooth Protocol
Analyzer. The only problem now is that with the quirk set, the
HCI Reset is also executed at the end of the setup phase. So the
controller gets configured and then it disconnects from the USB
bus, connects again, gets configured and of course disconnects
again. This game goes on forever.

For devices that need HCI_QUIRK_RESET_ON_CLOSE it is important
that the HCI Reset is not executed after the setup phase. In
specific when HCI_AUTO_OFF is set, do not call HCI Reset when
closing the device.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Add management command for setting LE scan parameters
Marcel Holtmann [Fri, 11 Oct 2013 15:23:20 +0000 (08:23 -0700)]
Bluetooth: Add management command for setting LE scan parameters

The scan interval and window parameters are used for LE passive
background scanning and connection establishment. This allows
userspace to change the values.

These two values should be kept in sync with whatever is used for
the scan parameters service on remote devices. And it puts the
controlling daemon (for example bluetoothd) in charge of setting
the values.

Main use case would be to switch between two sets of values. One
for foreground applications and one for background applications.

At this moment, the values are only used for manual connection
establishment, but soon that should be extended to background
scanning and automatic connection establishment.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Make LE scan interval and window a controller option
Marcel Holtmann [Fri, 11 Oct 2013 15:23:19 +0000 (08:23 -0700)]
Bluetooth: Make LE scan interval and window a controller option

The scan interval and window for LE passive scanning and connection
establishment should be configurable on a per controller basis. So
introduce a setting that later on will allow modifying it.

This setting does not affect LE active scanning during device
discovery phase. As long as that phase uses interleaved discovery,
it will continuously scan.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Declare ath3k_table[] and ath3k_blist_tbl[] as const
Marcel Holtmann [Fri, 11 Oct 2013 14:46:21 +0000 (07:46 -0700)]
Bluetooth: Declare ath3k_table[] and ath3k_blist_tbl[] as const

The ath3k_table[] and ath3k_blist_tbl[] USB device tables can be
declared as const.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Declare bpa10x_table[] as const
Marcel Holtmann [Fri, 11 Oct 2013 14:46:20 +0000 (07:46 -0700)]
Bluetooth: Declare bpa10x_table[] as const

The bpa10x_table[] device table can be declared as const

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Declare bfusb_table[] as const
Marcel Holtmann [Fri, 11 Oct 2013 14:46:19 +0000 (07:46 -0700)]
Bluetooth: Declare bfusb_table[] as const

The bfusb_table[] device table can be declared as const

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Declare btusb_table[] and blacklist_table[] as const
Marcel Holtmann [Fri, 11 Oct 2013 14:46:18 +0000 (07:46 -0700)]
Bluetooth: Declare btusb_table[] and blacklist_table[] as const

The btusb_table[] and blacklist_table[] USB device tables can be
declared as const.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Remove pointless parameter check in vhci_send_frame()
Marcel Holtmann [Fri, 11 Oct 2013 14:01:04 +0000 (07:01 -0700)]
Bluetooth: Remove pointless parameter check in vhci_send_frame()

The hdev parameter of vhci_send_frame() is always valid. If it were
not valid, then it would have crashed earlier in the call chain.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Remove pointless parameter check in hci_uart_send_frame()
Marcel Holtmann [Fri, 11 Oct 2013 14:01:03 +0000 (07:01 -0700)]
Bluetooth: Remove pointless parameter check in hci_uart_send_frame()

The hdev parameter of hci_uart_send_frame() is always valid. If it
were not valid, then it would have crashed earlier in the call chain.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>