platform/kernel/linux-rpi.git
10 years agoBluetooth: Add support for using controller white list filtering
Marcel Holtmann [Thu, 24 Jul 2014 13:20:57 +0000 (15:20 +0200)]
Bluetooth: Add support for using controller white list filtering

The Bluetooth controller can use a white list filter when scanning
to avoid waking up the host for devices that are of no interest.

Devices marked as reporting, direct connection (incoming) or general
connection are now added to the controller white list. The update of
the white list happens just before enabling passive scanning.

In case the white list is full and can not hold all devices, the
white list is not used and the filter policy set to accept all
advertisements.

Using the white list for scanning allows for power saving with
controllers that do not handle the duplicate filtering correctly.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
10 years agoBluetooth: Fix issue with ADV_IND reports and auto-connection handling
Marcel Holtmann [Wed, 23 Jul 2014 19:55:23 +0000 (21:55 +0200)]
Bluetooth: Fix issue with ADV_IND reports and auto-connection handling

When adding remote devices to the kernel using the Add Device management
command, these devices are explicitly allowed to connect. This kind of
incoming connections are possible even when the controller itself is
not connectable.

For BR/EDR this distinction is pretty simple since there is only one
type of incoming connections. With LE this is not that simple anymore
since there are ADV_IND and ADV_DIRECT_IND advertising events.

The ADV_DIRECT_IND advertising events are send for incoming (slave
initiated) connections only. And this is the only thing the kernel
should allow when adding devices using action 0x01. This meaning
of incoming connections is coming from BR/EDR and needs to be
mapped to LE the same way.

Supporting the auto-connection of devices using ADV_IND advertising
events is an important feature as well. However it does not map to
incoming connections. So introduce a new action 0x02 that allows
the kernel to connect to devices using ADV_DIRECT_IND and in addition
ADV_IND advertising reports.

This difference is represented by the new HCI_AUTO_CONN_DIRECT value
for only connecting to ADV_DIRECT_IND. For connection to ADV_IND and
ADV_DIRECT_IND the old value HCI_AUTO_CONN_ALWAYS is used.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
10 years agoBluetooth: Ignore ADV_DIRECT_IND attempts from unknown devices
Marcel Holtmann [Wed, 23 Jul 2014 19:55:22 +0000 (21:55 +0200)]
Bluetooth: Ignore ADV_DIRECT_IND attempts from unknown devices

Unconditionally connecting to devices sending ADV_DIRECT_IND when
the controller is in CONNECTABLE mode is a feature that is not
fully working. The background scanning trigger for this has been
removed, but the statement allowing it to happen in case some
other part triggers is still present. So remove that code part
as well to avoid unwanted connections.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
10 years agoBluetooth: Get MWS transport configuration of the controller
Marcel Holtmann [Wed, 23 Jul 2014 17:24:57 +0000 (19:24 +0200)]
Bluetooth: Get MWS transport configuration of the controller

If the Bluetooth controller supports Get MWS Transport Layer
Configuration command, then issue it during initialization.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
10 years agoBluetooth: Read list of local codecs supported by the controller
Marcel Holtmann [Wed, 23 Jul 2014 17:24:56 +0000 (19:24 +0200)]
Bluetooth: Read list of local codecs supported by the controller

If the Bluetooth controller supports Read Local Supported Codecs
command, then issue it during initialization so that the list of
codecs is known.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
10 years agoBluetooth: Avoid use of session socket after the session gets freed
Vignesh Raman [Tue, 22 Jul 2014 13:54:25 +0000 (19:24 +0530)]
Bluetooth: Avoid use of session socket after the session gets freed

The commits 08c30aca9e698faddebd34f81e1196295f9dc063 "Bluetooth: Remove
RFCOMM session refcnt" and 8ff52f7d04d9cc31f1e81dcf9a2ba6335ed34905
"Bluetooth: Return RFCOMM session ptrs to avoid freed session"
allow rfcomm_recv_ua and rfcomm_session_close to delete the session
(and free the corresponding socket) and propagate NULL session pointer
to the upper callers.

Additional fix is required to terminate the loop in rfcomm_process_rx
function to avoid use of freed 'sk' memory.

The issue is only reproducible with kernel option CONFIG_PAGE_POISONING
enabled making freed memory being changed and filled up with fixed char
value used to unmask use-after-free issues.

Signed-off-by: Vignesh Raman <Vignesh_Raman@mentor.com>
Signed-off-by: Vitaly Kuzmichev <Vitaly_Kuzmichev@mentor.com>
Acked-by: Dean Jenkins <Dean_Jenkins@mentor.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Cc: stable@vger.kernel.org
10 years agoBluetooth: Add support for Broadcom device of Asus Z97-DELUXE motherboard
Marcel Holtmann [Mon, 21 Jul 2014 12:02:33 +0000 (14:02 +0200)]
Bluetooth: Add support for Broadcom device of Asus Z97-DELUXE motherboard

The Asus Z97-DELUXE motherboard contains a Broadcom based Bluetooth
controller on the USB bus. However vendor and product ID are listed
as ASUSTek Computer.

T:  Bus=01 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#=  3 Spd=12   MxCh= 0
D:  Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=0b05 ProdID=17cf Rev= 1.12
S:  Manufacturer=Broadcom Corp
S:  Product=BCM20702A0
S:  SerialNumber=54271E910064
C:* #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
I:  If#= 1 Alt= 1 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
I:  If#= 1 Alt= 2 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
I:  If#= 1 Alt= 3 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
I:  If#= 1 Alt= 4 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
I:  If#= 1 Alt= 5 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E:  Ad=84(I) Atr=02(Bulk) MxPS=  32 Ivl=0ms
E:  Ad=04(O) Atr=02(Bulk) MxPS=  32 Ivl=0ms
I:* If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)

Reported-by: Jerome Leclanche <jerome@leclan.ch>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
10 years agoBluetooth: Prefer sizeof(*ptr) when allocating memory
Johan Hedberg [Mon, 21 Jul 2014 07:50:06 +0000 (10:50 +0300)]
Bluetooth: Prefer sizeof(*ptr) when allocating memory

It's safer practice to use sizeof(*ptr) instead of sizeof(ptr_type) when
allocating memory in case the type changes. This also fixes the
following style of warnings from static analyzers:

CHECK: Prefer kzalloc(sizeof(*ie)...) over kzalloc(sizeof(struct inquiry_entry)...)
+ ie = kzalloc(sizeof(struct inquiry_entry), GFP_KERNEL);

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
10 years agoBluetooth: Remove unneeded variable assignment in hmac_sha256
Marcel Holtmann [Sun, 20 Jul 2014 15:43:07 +0000 (17:43 +0200)]
Bluetooth: Remove unneeded variable assignment in hmac_sha256

The variable ret does not need to be assigned when declaring it. So
remove this initial assignment.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
10 years agoBluetooth: Fix endian and alignment issue with ath3k version handling
Marcel Holtmann [Sun, 20 Jul 2014 15:29:59 +0000 (17:29 +0200)]
Bluetooth: Fix endian and alignment issue with ath3k version handling

The ath3k driver is treating the version information badly when it
comes to loading the right firmware version and comparing that it
actually matches with the hardware.

Initially this showed up as this:

  CHECK   drivers/bluetooth/ath3k.c
drivers/bluetooth/ath3k.c:373:17: warning: cast to restricted __le32
drivers/bluetooth/ath3k.c:435:17: warning: cast to restricted __le32

However when fixing this by actually using __packed and __le32 for
the ath3_version structure, more issues came up:

  CHECK   drivers/bluetooth/ath3k.c
drivers/bluetooth/ath3k.c:381:32: warning: incorrect type in assignment (different base types)
drivers/bluetooth/ath3k.c:381:32:    expected restricted __le32 [usertype] rom_version
drivers/bluetooth/ath3k.c:381:32:    got int [signed] <noident>
drivers/bluetooth/ath3k.c:382:34: warning: incorrect type in assignment (different base types)
drivers/bluetooth/ath3k.c:382:34:    expected restricted __le32 [usertype] build_version
drivers/bluetooth/ath3k.c:382:34:    got int [signed] <noident>
drivers/bluetooth/ath3k.c:386:28: warning: restricted __le32 degrades to integer
drivers/bluetooth/ath3k.c:386:56: warning: restricted __le32 degrades to integer

This patch fixes every instance of the firmware version handling and
makes sure it is endian safe and uses proper unaligned access.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
10 years agoBluetooth: Disable HCI_CONNECTABLE based passive scanning for now
Johan Hedberg [Sun, 20 Jul 2014 14:10:45 +0000 (17:10 +0300)]
Bluetooth: Disable HCI_CONNECTABLE based passive scanning for now

When HCI_CONNECTABLE is set the code has been enabling passive scanning
in order to be consistent with BR/EDR and accept connections from any
device doing directed advertising to us. However, some hardware
(particularly CSR) can get very noisy even when doing duplicates
filtering, making this feature waste resources.

Considering that the feature is for fairly corner-case use (devices
who'd use directed advertising would likely be in the whitelist anyway)
it's better to disable it for now. It may still be brought back later,
possibly with a better implementation (e.g. through improved scan
parameters).

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
10 years agoBluetooth: btmrvl: add public address configuration support
Amitkumar Karwar [Fri, 18 Jul 2014 21:47:07 +0000 (14:47 -0700)]
Bluetooth: btmrvl: add public address configuration support

.set_bdaddr handler is implemented for public address configuration.
A reboot restores the bdaddr to its original address.

Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
10 years agoBluetooth: add public address configuration for Marvell USB devices
Amitkumar Karwar [Fri, 18 Jul 2014 21:47:06 +0000 (14:47 -0700)]
Bluetooth: add public address configuration for Marvell USB devices

Implemented .set_bdaddr handler provided by bluetooth stack for
Marvell devices for public address configuration.
A reboot restores the bdaddr to its original address.

Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
10 years agoBluetooth: Use EOPNOTSUPP instead of ENOTSUPP
Johan Hedberg [Fri, 18 Jul 2014 08:15:26 +0000 (11:15 +0300)]
Bluetooth: Use EOPNOTSUPP instead of ENOTSUPP

The EOPNOTSUPP and ENOTSUPP errors are very similar in meaning, but
ENOTSUPP is a fairly new addition to POSIX. Not all libc versions know
about the value the kernel uses for ENOTSUPP so it's better to use
EOPNOTSUPP to ensure understandable error messages.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
10 years agoBluetooth: Fix allowing initiating pairing when not pairable
Johan Hedberg [Thu, 17 Jul 2014 12:35:40 +0000 (15:35 +0300)]
Bluetooth: Fix allowing initiating pairing when not pairable

When we're not pairable we should still allow us to act as initiators
for pairing, i.e. the HCI_PAIRABLE flag should only be affecting
incoming pairing attempts. This patch fixes the relevant checks for the
hci_io_capa_request_evt() and hci_pin_code_request_evt() functions.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
10 years agoBluetooth: Introduce a flag to track who really initiates authentication
Johan Hedberg [Thu, 17 Jul 2014 12:35:39 +0000 (15:35 +0300)]
Bluetooth: Introduce a flag to track who really initiates authentication

Even though our side requests authentication, the original action that
caused it may be remotely triggered, such as an incoming L2CAP or RFCOMM
connect request. To track this information introduce a new hci_conn flag
called HCI_CONN_AUTH_INITIATOR.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
10 years agoBluetooth: Pass initiator/acceptor information to hci_conn_security()
Johan Hedberg [Thu, 17 Jul 2014 12:35:38 +0000 (15:35 +0300)]
Bluetooth: Pass initiator/acceptor information to hci_conn_security()

We're interested in whether an authentication request is because of a
remote or local action. So far hci_conn_security() has been used both
for incoming and outgoing actions (e.g. RFCOMM or L2CAP connect
requests) so without some modifications it cannot know which peer is
responsible for requesting authentication.

This patch adds a new "bool initiator" parameter to hci_conn_security()
to indicate which side is responsible for the request and updates the
current users to pass this information correspondingly.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
10 years agoBluetooth: Fix resetting remote authentication requirement after pairing
Johan Hedberg [Thu, 17 Jul 2014 12:14:50 +0000 (15:14 +0300)]
Bluetooth: Fix resetting remote authentication requirement after pairing

When a new hci_conn object is created the remote SSP authentication
requirement is set to the invalid value 0xff to indicate that it is
unknown. Once pairing completes however the code was leaving it as-is.
In case a new pairing happens over the same connection it is important
that we reset the value back to unknown so that the pairing code doesn't
make false assumptions about the requirements.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
10 years agoBluetooth: never linger on process exit
Vladimir Davydov [Tue, 15 Jul 2014 08:25:28 +0000 (12:25 +0400)]
Bluetooth: never linger on process exit

If the current process is exiting, lingering on socket close will make
it unkillable, so we should avoid it.

Reproducer:

  #include <sys/types.h>
  #include <sys/socket.h>

  #define BTPROTO_L2CAP   0
  #define BTPROTO_SCO     2
  #define BTPROTO_RFCOMM  3

  int main()
  {
          int fd;
          struct linger ling;

          fd = socket(PF_BLUETOOTH, SOCK_STREAM, BTPROTO_RFCOMM);
          //or: fd = socket(PF_BLUETOOTH, SOCK_DGRAM, BTPROTO_L2CAP);
          //or: fd = socket(PF_BLUETOOTH, SOCK_SEQPACKET, BTPROTO_SCO);

          ling.l_onoff = 1;
          ling.l_linger = 1000000000;
          setsockopt(fd, SOL_SOCKET, SO_LINGER, &ling, sizeof(ling));

          return 0;
  }

Signed-off-by: Vladimir Davydov <vdavydov@parallels.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Cc: stable@vger.kernel.org
10 years agoBluetooth: Don't bother user space without IO capabilities
Johan Hedberg [Wed, 16 Jul 2014 12:09:13 +0000 (15:09 +0300)]
Bluetooth: Don't bother user space without IO capabilities

If user space has a NoInputNoOutput IO capability it makes no sense to
bother it with confirmation requests. This patch updates both SSP and
SMP to check for the local IO capability before sending a user
confirmation request to user space.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
10 years agoBluetooth: Fix using uninitialized variable when pairing
Johan Hedberg [Thu, 17 Jul 2014 08:56:33 +0000 (11:56 +0300)]
Bluetooth: Fix using uninitialized variable when pairing

Commit 6c53823ae0e10e723131055e1e65dd6a328a228e reshuffled the way the
authentication requirement gets set in the hci_io_capa_request_evt()
function, but at the same time it failed to update an if-statement where
cp.authentication is used before it has been initialized. The correct
value the code should be looking for in this if-statement is
conn->auth_type.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Cc: stable@vger.kernel.org # 3.16
10 years agoBluetooth: Fix always checking the blacklist for incoming connections
Johan Hedberg [Wed, 16 Jul 2014 13:19:21 +0000 (16:19 +0300)]
Bluetooth: Fix always checking the blacklist for incoming connections

We should check the blacklist no matter what, meaning also when we're
not connectable. This patch fixes the respective logic in the function
making the decision whether to accept a connection or not.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
10 years agoBluetooth: Fix trying to initiate connections when acting as LE slave
Johan Hedberg [Wed, 16 Jul 2014 08:56:09 +0000 (11:56 +0300)]
Bluetooth: Fix trying to initiate connections when acting as LE slave

When we have at least one LE slave connection most (probably all)
controllers will refuse to initiate any new connections. To avoid
unnecessary failures simply check for this situation up-front and skip
the connection attempt.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
10 years agoBluetooth: Track number of LE slave connections
Johan Hedberg [Wed, 16 Jul 2014 08:56:08 +0000 (11:56 +0300)]
Bluetooth: Track number of LE slave connections

Most (probably all) controllers can only deal with a single slave LE
connection at a time. This patch adds a counter for such connections so
that the number can be quickly looked up without iterating the
connections list.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
10 years agoBluetooth: Add a role parameter to hci_conn_add()
Johan Hedberg [Wed, 16 Jul 2014 08:56:07 +0000 (11:56 +0300)]
Bluetooth: Add a role parameter to hci_conn_add()

We need to be able to track slave vs master LE connections in
hci_conn_hash, and to be able to do that we need to know the role of the
connection by the time hci_conn_add_has() is called. This means in
practice the hci_conn_add() call that creates the hci_conn_object.

This patch adds a new role parameter to hci_conn_add() function to give
the object its initial role value, and updates the callers to pass the
appropriate role to it. Since the function now takes care of
initializing both conn->role and conn->out values we can remove some
other unnecessary assignments.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
10 years agoBluetooth: Use explicit role instead of a bool in function parameters
Johan Hedberg [Wed, 16 Jul 2014 08:42:28 +0000 (11:42 +0300)]
Bluetooth: Use explicit role instead of a bool in function parameters

To make the code more understandable it makes sense to use the new HCI
defines for connection role instead of a "bool master" parameter. This
makes it immediately clear when looking at the function calls what the
last parameter is describing.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
10 years agoBluetooth: Convert HCI_CONN_MASTER flag to a conn->role variable
Johan Hedberg [Wed, 16 Jul 2014 08:42:27 +0000 (11:42 +0300)]
Bluetooth: Convert HCI_CONN_MASTER flag to a conn->role variable

Having a dedicated u8 role variable in the hci_conn struct greatly
simplifies tracking of the role, since this is the native way that it's
represented on the HCI level.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
10 years agoBluetooth: Add proper defines for HCI connection role
Johan Hedberg [Wed, 16 Jul 2014 08:42:26 +0000 (11:42 +0300)]
Bluetooth: Add proper defines for HCI connection role

All HCI commands and events, including LE ones, use 0x00 for master role
and 0x01 for slave role. It makes therefore sense to add generic defines
for these instead of the current LE_CONN_ROLE_MASTER. Having clean
defines will also make it possible to provide simpler internal APIs.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
10 years agoBluetooth: Don't try to reject failed LE connections
Johan Hedberg [Tue, 15 Jul 2014 08:51:28 +0000 (11:51 +0300)]
Bluetooth: Don't try to reject failed LE connections

The check for the blacklist in hci_le_conn_complete_evt() should be when
we know that we have an actual successful connection (ev->status being
non-zero). This patch fixes this ordering.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
10 years agoBluetooth: Remove unnecessary params variable from process_adv_report()
Johan Hedberg [Tue, 15 Jul 2014 05:07:59 +0000 (08:07 +0300)]
Bluetooth: Remove unnecessary params variable from process_adv_report()

The params variable was just used for storing the return value from the
hci_pend_le_action_lookup() function and then checking whether it's NULL
or not. We can simplify the code by checking the return value directly.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
10 years agoBluetooth: btmrvl: avoid sending data to firmware after hs_activated
Chin-Ran Lo [Tue, 15 Jul 2014 04:05:37 +0000 (21:05 -0700)]
Bluetooth: btmrvl: avoid sending data to firmware after hs_activated

We should suspend hci device and purge remaining data in tx queue
before enabling host sleep in firmware. If any data is sent to
firmware after host sleep is activated, firmware may end up
sending a TX_DONE interrupt to driver. If this interrupt gets
delivered to host while the SDIO host controller is suspending,
it may crash the system.

Conversely, in resume handler, we should resume hci device after
host sleep is de-activated.

Signed-off-by: Chin-Ran Lo <crlo@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
10 years agoBluetooth: cmtp: Remove unnecessary null test
Himangi Saraogi [Mon, 14 Jul 2014 20:34:13 +0000 (02:04 +0530)]
Bluetooth: cmtp: Remove unnecessary null test

This patch removes the null test on ctrl. ctrl is initialized at the
beginning of the function to &session->ctrl. Since session is
dereferenced prior to the null test, session must be a valid pointer,
and &session->ctrl cannot be null.

The following Coccinelle script is used for detecting the change:

@r@
expression e,f;
identifier g,y;
statement S1,S2;
@@

*e = &f->g
<+...
 f->y
 ...+>
*if (e != NULL || ...)
 S1 else S2

Signed-off-by: Himangi Saraogi <himangi774@gmail.com>
Acked-by: Julia Lawall <julia.lawall@lip6.fr>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
10 years agoBluetooth: Fix trying LTK re-encryption when we don't have an LTK
Johan Hedberg [Mon, 14 Jul 2014 11:34:55 +0000 (14:34 +0300)]
Bluetooth: Fix trying LTK re-encryption when we don't have an LTK

In the case that the key distribution bits cause us not to generate a
local LTK we should not try to re-encrypt if we're currently encrypted
with an STK. This patch fixes the check for this in the
smp_sufficient_security function.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
10 years agoBluetooth: Remove sco_chan_get helper function
Marcel Holtmann [Sun, 13 Jul 2014 23:30:15 +0000 (01:30 +0200)]
Bluetooth: Remove sco_chan_get helper function

The sco_chan_get helper function is only used in two places and really
only protects conn->sk with a lock. So instead of hiding that fact,
just put the actual code in place where it is used.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
10 years agoBluetooth: Convert L2CAP ident spinlock into a mutex
Marcel Holtmann [Sun, 13 Jul 2014 18:50:15 +0000 (20:50 +0200)]
Bluetooth: Convert L2CAP ident spinlock into a mutex

The spinlock protecting the L2CAP ident number can be converted into
a mutex since the whole processing is run in a workqueue. So instead
of using a spinlock, just use a mutex here.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
10 years agoBluetooth: Remove unneeded forward declaration of sco_chan_del
Marcel Holtmann [Sun, 13 Jul 2014 17:54:49 +0000 (19:54 +0200)]
Bluetooth: Remove unneeded forward declaration of sco_chan_del

The forward declaration of sco_chan_del is not needed and thus just
remove it. Move sco_chan_del into the proper location.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
10 years agoBluetooth: Remove unneeded forward declaration of __sco_chan_add
Marcel Holtmann [Sun, 13 Jul 2014 17:54:48 +0000 (19:54 +0200)]
Bluetooth: Remove unneeded forward declaration of __sco_chan_add

The forward declaration of __sco_chan_add is not needed and thus just
remove it. Move __sco_chan_add into the proper location.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
10 years agoBluetooth: Allocate struct inquiry_entry with GFP_KERNEL
Marcel Holtmann [Sun, 13 Jul 2014 15:22:25 +0000 (17:22 +0200)]
Bluetooth: Allocate struct inquiry_entry with GFP_KERNEL

The allocation of inquiry cache entries is triggered as a result of
processing HCI events. Since the processing is done in the context
of a workqueue, there is no needed to allocate with GFP_ATOMIC in
that case. Switch it to GFP_KERNEL.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
10 years agoBluetooth: Enable LE Long Term Key Request event only when supported
Marcel Holtmann [Sat, 12 Jul 2014 22:29:22 +0000 (00:29 +0200)]
Bluetooth: Enable LE Long Term Key Request event only when supported

The support for LE encryption is optional and with that also the
LE Long Term Key Request event. If encryption is not supported, then
do not bother enabling this event.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
10 years agoBluetooth: Enable LE encryption events only when supported
Marcel Holtmann [Sat, 12 Jul 2014 21:36:16 +0000 (23:36 +0200)]
Bluetooth: Enable LE encryption events only when supported

The support for LE encryption is optional. When encryption is not
supported then also do not enable the encryption related events.

This moves the event mask setting to the third initialization
stage to ensure that the LE features are available.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
10 years agoBluetooth: Read LE Advertising Channel TX Power only when available
Marcel Holtmann [Sat, 12 Jul 2014 21:20:50 +0000 (23:20 +0200)]
Bluetooth: Read LE Advertising Channel TX Power only when available

The Read LE Advertising Channel TX Power command is not mandatory for
a Bluetooth HCI controller only supporting receiption. Move the command
to the third stage of the controller initialization and only execute it
when support for it has been indicated.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
10 years agoBluetooth: Fix HCIUARTGETDEVICE ioctl when UART is not registered
Marcel Holtmann [Sat, 12 Jul 2014 15:00:29 +0000 (17:00 +0200)]
Bluetooth: Fix HCIUARTGETDEVICE ioctl when UART is not registered

The protocol for the UART might be configured, but that does not
mean the HCI device is registered. Return an error in that case
and only return the index number when HCI_UART_REGISTERED is set.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
10 years agoMAINTAINERS: add net/6lowpan/ maintainer entry
Alexander Aring [Fri, 11 Jul 2014 08:24:19 +0000 (10:24 +0200)]
MAINTAINERS: add net/6lowpan/ maintainer entry

This patch add a maintainer entry for "net/6lowpan". Also add the current
IEEE 802.15.4 mailing list and bluetooth mailinglist to this branch,
because this code is shared between them.

Signed-off-by: Alexander Aring <alex.aring@gmail.com>
Acked-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
10 years ago6lowpan: introduce new net/6lowpan directory
Alexander Aring [Fri, 11 Jul 2014 08:24:18 +0000 (10:24 +0200)]
6lowpan: introduce new net/6lowpan directory

This patch moves generic code which is used by bluetooth and ieee802154
6lowpan to a new net/6lowpan directory. This directory contains generic
6LoWPAN code which is shared between bluetooth and ieee802154 MAC-Layer.

This is the IPHC - "IPv6 Header Compression" format at the moment. Which
is described by RFC 6282 [0]. The BLTE 6LoWPAN draft describes that the
IPHC is the same format like IEEE 802.15.4, see [1].

Futuremore we can put more code into this directory which is shared
between BLTE and IEEE 802.15.4 6LoWPAN like RFC 6775 or the routing
protocol RPL RFC 6550.

To avoid naming conflicts I renamed 6lowpan-y to ieee802154_6lowpan-y
in net/ieee802154/Makefile.

[0] http://tools.ietf.org/html/rfc6282
[1] http://tools.ietf.org/html/draft-ietf-6lowpan-btle-12#section-3.2
[2] http://tools.ietf.org/html/rfc6775
[3] http://tools.ietf.org/html/rfc6550

Signed-off-by: Alexander Aring <alex.aring@gmail.com>
Acked-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
10 years agoBluetooth: Fix tracking local SSP authentication requirement
Johan Hedberg [Fri, 11 Jul 2014 12:32:23 +0000 (15:32 +0300)]
Bluetooth: Fix tracking local SSP authentication requirement

When we need to make the decision whether to perform just-works or real
user confirmation we need to know the exact local authentication
requirement that was passed to the controller. So far conn->auth_type
(the local requirement) wasn't in one case updated appropriately in fear
of the user confirmation being rejected later.

The real problem however was not really that conn->auth_type couldn't
represent the true value but that we were checking the local MITM
requirement in an incorrect way. It's perfectly fine to let auth_type
follow what we tell the controller since we're still tracking the target
security level with conn->pending_sec_level.

This patch updates the check for local MITM requirement in the
hci_user_confirm_request_evt function to use the locally requested
security level and ensures that auth_type always represents what we tell
the controller. All other code in hci_user_confirm_request_evt still
uses the auth_type instead of pending_sec_level for determining whether
to do just-works or not, since that's the only value that's in sync with
what the remote device knows.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Tested-by: Szymon Janc <szymon.janc@tieto.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Cc: stable@vger.kernel.org # 3.16
10 years agoBluetooth: Add support for external configuration with UART driver
Marcel Holtmann [Fri, 11 Jul 2014 05:12:58 +0000 (07:12 +0200)]
Bluetooth: Add support for external configuration with UART driver

The quirk for enabling external configuration with UART needs to be
provided via the HCI UART flags. Add a new flag for it and declare
it as valid.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
10 years agoBluetooth: Check for valid HCI UART driver flags
Marcel Holtmann [Fri, 11 Jul 2014 05:12:57 +0000 (07:12 +0200)]
Bluetooth: Check for valid HCI UART driver flags

Providing unknown or invalid flags to the HCI UART driver should
result in an error. So check which flags are valid and otherwise
return an error.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
10 years agoBluetooth: Move SCO timeout constants into net/bluetooth/sco.c
Marcel Holtmann [Fri, 11 Jul 2014 04:19:44 +0000 (06:19 +0200)]
Bluetooth: Move SCO timeout constants into net/bluetooth/sco.c

There is no external user of the SCO timeout constants and thus
move them into net/bluetooth/sco.c where they are actuallu used.

In addition just remove SCO_CONN_IDLE_TIMEOUT since it is unused.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
10 years agoBluetooth: Remove unused SCO_DEFAULT_FLUSH_TO constant
Marcel Holtmann [Fri, 11 Jul 2014 04:19:43 +0000 (06:19 +0200)]
Bluetooth: Remove unused SCO_DEFAULT_FLUSH_TO constant

The SCO_DEFAULT_FLUSH_TO constant has been defined, but it is not
used anywhere and so just remove it.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
10 years agoBluetooth: Move struct sco_conn into net/bluetooth/sco.c
Marcel Holtmann [Fri, 11 Jul 2014 04:19:42 +0000 (06:19 +0200)]
Bluetooth: Move struct sco_conn into net/bluetooth/sco.c

There exists no external user of struct sco_conn and thus move
it into the one place that is actually using it.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
10 years agoBluetooth: Move struct sco_pinfo into net/bluetooth/sco.c
Marcel Holtmann [Fri, 11 Jul 2014 04:19:41 +0000 (06:19 +0200)]
Bluetooth: Move struct sco_pinfo into net/bluetooth/sco.c

There exists no external user of struct sco_pinfo and sco_pi and
thus move it into the one place that is actually using it.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
10 years agoBluetooth: Update the list of L2CAP fixed channels
Marcel Holtmann [Fri, 11 Jul 2014 04:03:08 +0000 (06:03 +0200)]
Bluetooth: Update the list of L2CAP fixed channels

The list of L2CAP fixed channels increased with newer versions of the
specification. This just updates the constants for it.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
10 years agoBluetooth: Move HCI request internals to net/bluetooth/hci_core.c
Marcel Holtmann [Fri, 11 Jul 2014 03:51:58 +0000 (05:51 +0200)]
Bluetooth: Move HCI request internals to net/bluetooth/hci_core.c

The internals of the HCI request framework should not be leaking to
its users. Move them all into net/bluetooth/hci_core.c and provide
a simple hci_req_pending helper function for the one user outside
the framework.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
10 years agoBluetooth: Move struct hci_pinfo into net/bluetooth/hci_sock.c
Marcel Holtmann [Fri, 11 Jul 2014 03:41:00 +0000 (05:41 +0200)]
Bluetooth: Move struct hci_pinfo into net/bluetooth/hci_sock.c

There exists no external user of struct hci_pinfo and hci_pi and thus
move it into the one place that is actually using it.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
10 years agoBluetooth: Delcare the hci_sec_filter as const
Marcel Holtmann [Fri, 11 Jul 2014 03:36:40 +0000 (05:36 +0200)]
Bluetooth: Delcare the hci_sec_filter as const

The hci_sec_filter socket filter details do not change. They are fixed
and with that they can also be delcared as const.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
10 years agoBluetooth: Move struct hci_sec_filter next to its user
Marcel Holtmann [Fri, 11 Jul 2014 03:36:39 +0000 (05:36 +0200)]
Bluetooth: Move struct hci_sec_filter next to its user

There is only single location using struct hci_sec_filter and with
that there is no point in putting this declaration into a global
header file. So move it right next to its user and make the code
a lot more simpler.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
10 years agoBluetooth: Move HCI socket definitions into its own header file
Marcel Holtmann [Fri, 11 Jul 2014 02:58:29 +0000 (04:58 +0200)]
Bluetooth: Move HCI socket definitions into its own header file

All the HCI sockets and ioctl based definitions have been in a global
header file that also includes all the HCI protocol structures. To
make this a bit cleaner, move them into its own file.

This also adjusts fs/compat_ioctl.c to only include this new file
and not all the protocol structures that are not needed.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
10 years agoBluetooth: Set HCI_PAIRABLE during power on for legacy ioctl
Marcel Holtmann [Thu, 10 Jul 2014 13:25:22 +0000 (15:25 +0200)]
Bluetooth: Set HCI_PAIRABLE during power on for legacy ioctl

When the controller is brought up using legacy ioctl, the setting of
the HCI_PAIRABLE flag should happen then. Previously it was set during
enumeration and when retrieving device information.

This change also will not set the HCI_PAIRABLE flag when the controller
is used with the HCI User Channel operation.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
10 years agoBluetooth: Mark controller is down when HCI_AUTO_OFF is set
Marcel Holtmann [Thu, 10 Jul 2014 11:17:37 +0000 (13:17 +0200)]
Bluetooth: Mark controller is down when HCI_AUTO_OFF is set

During the initial setup phase, the controller is powered on and will
be powered off again if it is not used within the auto-off timeout.

Userspace using ioctl does not know about the difference between the
initial setup phase and a controller being present. It is a bad idea
to keep the controller powered by just looking at the device list or
device information. Instead just tell userspace that the controller
is still down.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
10 years agoBluetooth: Remove unneeded mgmt_write_scan_failed function
Johan Hedberg [Thu, 10 Jul 2014 09:09:09 +0000 (12:09 +0300)]
Bluetooth: Remove unneeded mgmt_write_scan_failed function

The Set Connectable/Discoverable mgmt handlers use a hci_request with a
proper callback to handle the HCI command sending. It makes therefore
little sense to have this extra function to be called from hci_event.c
for command failures.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
10 years agoBluetooth: Remove unneeded mgmt_discoverable function
Johan Hedberg [Thu, 10 Jul 2014 09:09:08 +0000 (12:09 +0300)]
Bluetooth: Remove unneeded mgmt_discoverable function

Since the HCISETSCAN ioctl is the only non-mgmt user we care about for
setting the right discoverable state we can simply do the necessary
updates in the ioctl handler function instead. This then allows the
removal of the mgmt_discoverable function and should simplify that state
handling considerably.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
10 years agoBluetooth: Refactor ioctl scan state update to its own function
Johan Hedberg [Thu, 10 Jul 2014 09:09:07 +0000 (12:09 +0300)]
Bluetooth: Refactor ioctl scan state update to its own function

With subsequent patches we'll also need to update the discoverable
state. As the code grows bigger it's better to move this out from the
switch statement into its own function.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
10 years agoBluetooth: Remove unneeded mgmt_connectable function
Johan Hedberg [Thu, 10 Jul 2014 09:09:06 +0000 (12:09 +0300)]
Bluetooth: Remove unneeded mgmt_connectable function

The mgmt_connectable function has been used to ensure that the right
actions to HCI_CONNECTABLE are taken when the HCI_Write_Scan_Enable
command is triggered by something else than mgmt. The only other user
that we really care about is the HCISETSCAN ioctl code, so we can
actually more simply perform the needed changes there instead.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
10 years agoBluetooth: Fix using test_and_clear instead of test_and_set
Johan Hedberg [Thu, 10 Jul 2014 08:50:27 +0000 (11:50 +0300)]
Bluetooth: Fix using test_and_clear instead of test_and_set

The code for updating the HCI_CONNECTABLE flag was incorrectly using
test_and_set_bit instead of test_and_clear_bit when HCI_CONNECTABLE is
to be cleared.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
10 years agoBluteooth: Reject SMP bonding if HCI_PAIRABLE is not set
Johan Hedberg [Thu, 10 Jul 2014 08:02:07 +0000 (11:02 +0300)]
Bluteooth: Reject SMP bonding if HCI_PAIRABLE is not set

If the remote device tries to initiate bonding with us and we don't have
HCI_PAIRABLE set we should just flat out reject the request. This brings
SMP in line with how the flag is used for BR/EDR SSP.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
10 years agoBluetooth: Fix advertising parameter update when toggling connectable
Johan Hedberg [Thu, 10 Jul 2014 07:51:27 +0000 (10:51 +0300)]
Bluetooth: Fix advertising parameter update when toggling connectable

When we change the connectable state and have advertising enabled we
should update the advertising parameters no matter what. The code was
incorrectly only updating them if advertising was not already active.
This patch fixes the issue.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
10 years agoBluetooth: Fix incorrect clearing of SMP_FLAG_INITIATOR
Johan Hedberg [Wed, 9 Jul 2014 16:18:11 +0000 (19:18 +0300)]
Bluetooth: Fix incorrect clearing of SMP_FLAG_INITIATOR

When the SMP context is created all flags default to zero. To determine
that we are the initiators it's therefore best to simply change the flag
value when we know we're sending the first SMP PDU. Clearing the flag
when receiving a Pairing Request is not correct since the request may be
a response to a previous Security Request from us (for which we would
already have correctly set the flag). Same goes for receiving a Security
Request which may be coming after us already starting pairing by sending
a Pairing Request.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
10 years agoBluetooth: Fix forcing SMP just-works with no-bonding
Johan Hedberg [Wed, 9 Jul 2014 16:18:10 +0000 (19:18 +0300)]
Bluetooth: Fix forcing SMP just-works with no-bonding

Whether we bond or not should not have any impact on the user
interaction model. This patch removes an incorrect fall-back from
JUST_CFM to JUST_WORKS in case we're not bonding.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
10 years agoBluetooth: Always confirm incoming SMP just-works requests
Johan Hedberg [Wed, 9 Jul 2014 16:18:09 +0000 (19:18 +0300)]
Bluetooth: Always confirm incoming SMP just-works requests

For incoming requests we want to let the user know that pairing is
happening since otherwise there could be access to MEDIUM security
services without any user interaction at all. Therefore, set the
selected method to JUST_CFM instead of JUST_WORKS and let it be
converted back to JUST_WORKS later if we are the initators.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
10 years agoBluetooth: Don't send ERTM configuration option when disabled
Marcel Holtmann [Wed, 9 Jul 2014 09:53:35 +0000 (11:53 +0200)]
Bluetooth: Don't send ERTM configuration option when disabled

When ERTM support is disabled, then do not even send ERTM configuration
option even if the remote side supports it.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
10 years agoBluetooth: Fix setting HCI_CONNECTABLE from ioctl code
Johan Hedberg [Wed, 9 Jul 2014 10:28:26 +0000 (13:28 +0300)]
Bluetooth: Fix setting HCI_CONNECTABLE from ioctl code

When the white list is in use the code would not update the
HCI_CONNECTABLE flag if it gets changed through the ioctl code (e.g.
hciconfig hci0 pscan). Since the flag is important for properly
accepting incoming connections add code to fix it up if necessary and
emit a New Settings mgmt event.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
10 years agoBluetooth: Add white list lookup for incoming connection requests
Johan Hedberg [Wed, 9 Jul 2014 09:59:19 +0000 (12:59 +0300)]
Bluetooth: Add white list lookup for incoming connection requests

This patch adds support for looking up entries in the white list when
HCI_CONNECTABLE is not set. The logic is fairly simple: if we're
connectable check the black list, if we're not connectable check the
white list.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
10 years agoBluetooth: Enable page scan also if there are white list entries
Johan Hedberg [Wed, 9 Jul 2014 09:59:18 +0000 (12:59 +0300)]
Bluetooth: Enable page scan also if there are white list entries

Page scan should be enabled either if the connectable setting is set or
if there are any entries in the BR/EDR white list. This patch implements
such behavior by updating the two places that were making decisions on
whether to enable page scan or not.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
10 years agoBluetooth: Refactor connection request handling
Johan Hedberg [Wed, 9 Jul 2014 09:59:17 +0000 (12:59 +0300)]
Bluetooth: Refactor connection request handling

The conditions for accepting an incoming connections are already
non-trivial and will become more so once a white list is added. This
patch breaks up the checks for when to reject the request by creating a
helper function for it.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
10 years agoBluetooth: Fix incorrectly setting HCI_CONNECTABLE
Johan Hedberg [Wed, 9 Jul 2014 09:59:16 +0000 (12:59 +0300)]
Bluetooth: Fix incorrectly setting HCI_CONNECTABLE

Since page scan might be enabled by Add Device we should not implicitly
set connectable whenever something else than Set Connectable changes it.
This patch makes sure that we don't set HCI_CONNECTABLE for these cases
if there are any entries in the white list.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
10 years agoBluetooth: Update page scan when necessary for Add/Remove Device
Johan Hedberg [Wed, 9 Jul 2014 09:59:15 +0000 (12:59 +0300)]
Bluetooth: Update page scan when necessary for Add/Remove Device

When we're removing the last item in the white list or adding the first
one to it and HCI_CONNECTABLE is not set we need to update the current
page scan. This patch adds a simple helper function for the purpose and
calls it from the respective mgmt command handlers.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
10 years agoBluetooth: Introduce a whitelist for BR/EDR devices
Johan Hedberg [Wed, 9 Jul 2014 09:59:14 +0000 (12:59 +0300)]
Bluetooth: Introduce a whitelist for BR/EDR devices

This patch extends the Add/Remove device commands by letting user space
pass BR/EDR addresses to them. The resulting entries get stored in a new
hdev->whitelist list. The idea is that we can now selectively accept
connections from devices in the list even though HCI_CONNECTABLE is not
set (the actual implementation of this is coming in a subsequent patch).

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
10 years agoBluetooth: Unify helpers for bdaddr_list manipulations
Johan Hedberg [Wed, 9 Jul 2014 09:59:13 +0000 (12:59 +0300)]
Bluetooth: Unify helpers for bdaddr_list manipulations

We already have several lists with struct bdaddr_list entries, and there
will be more in the future. Since the operations for adding, removing,
looking up and clearing entries in these lists are exactly the same it
doesn't make sense to define new functions for every single list. This
patch unifies the functions by passing the list_head to them instead of
a hci_dev pointer.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
10 years agoBluetooth: Fix enabling Authenticated Payload Timeout Expired event
Marcel Holtmann [Wed, 9 Jul 2014 07:49:05 +0000 (09:49 +0200)]
Bluetooth: Fix enabling Authenticated Payload Timeout Expired event

The Authenticated Payload Timeout Expired event is valid for
controllers with BR/EDR Secure Connections support, but also for
LE only controllers supporting LE Ping feature. When either of them
is available enable this event. Previous it was not enabled when
the controller was only supporting LE operation.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
10 years agoBluetooth: Add support for Acer [13D3:3432]
Anantha Krishnan [Tue, 8 Jul 2014 13:55:08 +0000 (19:25 +0530)]
Bluetooth: Add support for Acer [13D3:3432]

Add support for the QCA6174 chip.

    T:  Bus=04 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 30 Spd=12  MxCh= 0
    D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=13d3 ProdID=3432 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: Anantha Krishnan <ananthk@codeaurora.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
10 years agoBluetooth: Fix clearing HCI_LE_ADV for LE connections
Johan Hedberg [Tue, 8 Jul 2014 14:21:51 +0000 (17:21 +0300)]
Bluetooth: Fix clearing HCI_LE_ADV for LE connections

All LE controllers always implicitly stop advertising when establishing
connections. Therefore, be sure to clear the flag in the event handler
for new LE connections.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
10 years agoBluetooth: Fix toggling background scan when changing connectable state
Johan Hedberg [Tue, 8 Jul 2014 13:35:34 +0000 (16:35 +0300)]
Bluetooth: Fix toggling background scan when changing connectable state

If the connectable state change doesn't require any special HCI commands
the set_connectable_update_settings() function is used instead of the
set_connectable_complete() function. We must therefore make sure to call
hci_update_background_scan() there as well. This code path is used also
when we're powered off, but that's fine since hci_update_background_scan()
has the necessary checks for it.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
10 years agoBluetooth: Fix connectable and discoverable supported settings values
Johan Hedberg [Tue, 8 Jul 2014 13:07:34 +0000 (16:07 +0300)]
Bluetooth: Fix connectable and discoverable supported settings values

The connectable and discoverable mgmt settings are supported both for LE
and BR/EDR controllers so they do not belong behind a lmp_bredr_capable()
condition. This patch fixes the issue in get_supported_settings().

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
10 years agoBluetooth: Fix setting STOPPING state for discovery
Johan Hedberg [Tue, 8 Jul 2014 13:05:06 +0000 (16:05 +0300)]
Bluetooth: Fix setting STOPPING state for discovery

If any of the HCI commands from the hci_stop_discovery function were
successfully sent we need to set the discovery state to STOPPING. The
Stop Discovery code was already handling this, but the code in
clean_up_hci_state was not. This patch updates the hci_stop_discovery to
return a bool to indicate whether it queued any commands and the
clean_up_hci_state() function respectively to look at the return value
and call hci_discovery_set_state() if necessary.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
10 years agoBluetooth: Fix check for re-enabling advertising
Johan Hedberg [Tue, 8 Jul 2014 13:05:05 +0000 (16:05 +0300)]
Bluetooth: Fix check for re-enabling advertising

There are many different places that can disable LE scanning but we only
want to re-enable advertising in hci_cc_le_set_scan_enable() for a very
specific use case, which is when the active scanning part of Start
Discovery is complete. Because of this, fix the discovery state check to
test for the exact state.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
10 years agoBluetooth: Fix advertising and active scanning co-existence
Johan Hedberg [Tue, 8 Jul 2014 12:07:53 +0000 (15:07 +0300)]
Bluetooth: Fix advertising and active scanning co-existence

Many controllers allow simultaneous active scanning and advertising
(e.g. Intel and Broadcom) but some do not (e.g. CSR). It's therefore
safest to implement mutual exclusion of these states in the kernel.

This patch ensures that the two states are never entered simultaneously.
Extra precaution needs to be taken for outgoing connection attempts in
slave role (i.e. through directed advertising) in which case the
operation that came first has precedence and the one that comes after
gets a rejection.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
10 years agoBluetooth: Stop advertising always before initiating a connection
Johan Hedberg [Tue, 8 Jul 2014 12:07:52 +0000 (15:07 +0300)]
Bluetooth: Stop advertising always before initiating a connection

Most controllers do not support advertising while initiating an LE
connection. We also have to first disable current advertising if the
initiation is going to happen through direct advertising. Therefore,
simply stop advertising as the first thing when starting to issue
commands to establish an LE connection.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
10 years agoBluetooth: Use the correct flag to decide to disable advertising
Johan Hedberg [Tue, 8 Jul 2014 12:07:51 +0000 (15:07 +0300)]
Bluetooth: Use the correct flag to decide to disable advertising

When deciding to call disable_advertising() we're interested in the real
state instead of the mgmt setting. Use therefore HCI_LE_ADV instead of
the HCI_ADVERTISING flag.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
10 years agoBluetooth: Simplify usage of the enable_advertising function
Johan Hedberg [Tue, 8 Jul 2014 12:07:50 +0000 (15:07 +0300)]
Bluetooth: Simplify usage of the enable_advertising function

By adding support for disabling advertising when necessary and doing the
checks for existing LE connections inside the enable_advertising
function we can simplify the calling code quite a lot.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
10 years agoBluetooth: Use real advertising state to random address update decision
Johan Hedberg [Tue, 8 Jul 2014 12:07:49 +0000 (15:07 +0300)]
Bluetooth: Use real advertising state to random address update decision

Now that we have a flag for tracking the real advertising state we
should use that to determine whether it's safe to update the random
address or not. The couple of places that were clearing the flag due to
a pending request need to be updated too.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
10 years agoBluetooth: Remove unnecessary mgmt_advertising function
Johan Hedberg [Tue, 8 Jul 2014 12:07:48 +0000 (15:07 +0300)]
Bluetooth: Remove unnecessary mgmt_advertising function

Since the real advertising state is now tracked with its own flag we can
simply set/unset the HCI_ADVERTISING flag in the
set_advertising_complete function.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
10 years agoBluetooth: Add flag to track the real advertising state
Johan Hedberg [Tue, 8 Jul 2014 12:07:47 +0000 (15:07 +0300)]
Bluetooth: Add flag to track the real advertising state

Having a single HCI_ADVERTISING flag is problematic since it tries to
track both the real advertising state and the corresponding mgmt
setting. To make the logic simpler and more reliable add a new flag that
only tracks the actual advertising state that has been written to the
controller.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
10 years agoBluetooth: Don't try background scanning if LE is not enabled
Johan Hedberg [Mon, 7 Jul 2014 12:19:50 +0000 (15:19 +0300)]
Bluetooth: Don't try background scanning if LE is not enabled

For adapters that do not support LE and ones where LE hasn't been
enabled we shouldn't be trying to initiate background scanning. This
patch adds an extra check to the hci_update_background_scan() to ensure
that we bail out if HCI_LE_ENABLED is not set.

Since we do allow user space to feed the kernel with LE connection
parameters even when LE is not enabled we now need to also call
hci_update_background_scan() as soon as LE gets enabled so that scanning
gets started if necessary.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
10 years agoBluetooth: Pass desired connection role to hci_connect_le()
Johan Hedberg [Mon, 7 Jul 2014 12:02:28 +0000 (15:02 +0300)]
Bluetooth: Pass desired connection role to hci_connect_le()

If we have both LE scanning and advertising simultaneously enabled we
need a way to tell hci_connect_le() in which role to initiate a
connection. This patch adds a new parameter to the function to give it
the necessary information. For auto-connect and mgmt_pair_device we
always use master role, whereas for L2CAP users (in practice sockets) we
use slave role whenever HCI_ADVERTISING is set and master role
otherwise.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
10 years agoBluetooth: Remove auth_type parameter from hci_connect_le()
Johan Hedberg [Mon, 7 Jul 2014 12:02:27 +0000 (15:02 +0300)]
Bluetooth: Remove auth_type parameter from hci_connect_le()

The auth_type value which gets assigned to hci_conn->auth_type is
something that's only used for BR/EDR connections and is of no value for
LE connections. It makes therefore little sense to pass it to the
hci_connect_le() function. This patch removes the parameter from the
function.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
10 years agoBluetooth: Enable passive scanning whenever we're connectable
Johan Hedberg [Mon, 7 Jul 2014 11:40:22 +0000 (14:40 +0300)]
Bluetooth: Enable passive scanning whenever we're connectable

Enabling passive scanning always when we're connectable aligns us with
the BR/EDR page scanning. This is also consistent with the fact that the
code dealing with passive scanning results will actively try to connect
any direct advertising event when we're connectable.

This patch implements the feature by adding the connectable condition to
hci_update_background_scan() checks for starting scanning and by calling
hci_update_background_scan() whenever the connectable state changes.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
10 years agoBluetooth: Don't let background scanning interfering with discovery
Johan Hedberg [Mon, 7 Jul 2014 10:24:59 +0000 (13:24 +0300)]
Bluetooth: Don't let background scanning interfering with discovery

If we have an active discovery going on we shouldn't do any changes to
LE scanning when hci_update_background_scan() is called (a call which
can happen for many different reasons). This patch fixes the issue by
returning from the function if the discovery state is anything else
except DISCOVERY_STOPPED.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
10 years agoBluetooth: Update discovery state earlier in hci_discovery_set_state
Johan Hedberg [Mon, 7 Jul 2014 10:24:58 +0000 (13:24 +0300)]
Bluetooth: Update discovery state earlier in hci_discovery_set_state

In a subsequent patch the hci_update_background_scan() function will
depend on being able to know the current discovery state. For this to be
possible we need to set the new state early in the function. Since we
also need to check what the old state was this patch introduces an extra
variable for tracking it.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
10 years agoBluetooth: Remove unnecessary return value from check_pending_le_conn
Johan Hedberg [Mon, 7 Jul 2014 09:45:55 +0000 (12:45 +0300)]
Bluetooth: Remove unnecessary return value from check_pending_le_conn

Since the only caller of this function doesn't care about the return
value anymore let's just remove it.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
10 years agoBluetooth: Remove redundant IRK lookup in mgmt_device_found()
Johan Hedberg [Mon, 7 Jul 2014 09:45:54 +0000 (12:45 +0300)]
Bluetooth: Remove redundant IRK lookup in mgmt_device_found()

Now that we have the process_adv_report() function doing the IRK lookup
and updating the bdaddr we don't need to do this anymore in mgmt.c in
the mgmt_device_found() function.

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