GitHub/LineageOS/G12/android_kernel_amlogic_linux-4.9.git
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>
11 years agoBluetooth: Remove pointless parameter check in dtl1_hci_send_frame()
Marcel Holtmann [Fri, 11 Oct 2013 14:01:02 +0000 (07:01 -0700)]
Bluetooth: Remove pointless parameter check in dtl1_hci_send_frame()

The hdev parameter of dtl1_hci_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 btuart_hci_send_frame()
Marcel Holtmann [Fri, 11 Oct 2013 14:01:01 +0000 (07:01 -0700)]
Bluetooth: Remove pointless parameter check in btuart_hci_send_frame()

The hdev parameter of btuart_hci_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 btmrvl_send_frame()
Marcel Holtmann [Fri, 11 Oct 2013 14:01:00 +0000 (07:01 -0700)]
Bluetooth: Remove pointless parameter check in btmrvl_send_frame()

The hdev parameter of btmrvl_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 bt3c_hci_send_frame()
Marcel Holtmann [Fri, 11 Oct 2013 14:00:59 +0000 (07:00 -0700)]
Bluetooth: Remove pointless parameter check in bt3c_hci_send_frame()

The hdev parameter of bt3c_hci_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 bluecard_hci_send_frame()
Marcel Holtmann [Fri, 11 Oct 2013 14:00:58 +0000 (07:00 -0700)]
Bluetooth: Remove pointless parameter check in bluecard_hci_send_frame()

The hdev parameter of bluecard_hci_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 bfusb_send_frame()
Marcel Holtmann [Fri, 11 Oct 2013 14:00:57 +0000 (07:00 -0700)]
Bluetooth: Remove pointless parameter check in bfusb_send_frame()

The hdev parameter of bfusb_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: Add hdev parameter to hdev->send driver callback
Marcel Holtmann [Fri, 11 Oct 2013 13:19:18 +0000 (06:19 -0700)]
Bluetooth: Add hdev parameter to hdev->send driver callback

Instead of masking hdev inside the skb->dev parameter, hand it
directly to the driver as a parameter to hdev->send. This makes
the driver interface more clear and simpler.

This patch fixes all drivers to accept and handle the new parameter
of hdev->send callback. Special care has been taken for bpa10x
and btusb drivers that require having skb->dev set to hdev for
the URB transmit complete handlers.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Provide hdev parameter to hci_recv_frame() driver callback
Marcel Holtmann [Thu, 10 Oct 2013 23:52:43 +0000 (16:52 -0700)]
Bluetooth: Provide hdev parameter to hci_recv_frame() driver callback

To avoid casting skb->dev into hdev, just let the drivers provide
the hdev directly when calling hci_recv_frame() function.

This patch also fixes up all drivers to provide the hdev.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Remove unused h4_check_data_len() function
Marcel Holtmann [Thu, 10 Oct 2013 23:52:42 +0000 (16:52 -0700)]
Bluetooth: Remove unused h4_check_data_len() function

The function h4_check_data_len() is actually not used. So just
remove it.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Remove return value from hci_send_frame() function
Marcel Holtmann [Thu, 10 Oct 2013 21:54:19 +0000 (14:54 -0700)]
Bluetooth: Remove return value from hci_send_frame() function

The return value of hci_send_frame() is never checked. So just make
this function void and print an error when the hdev->send driver
callback returns a negative value.

Having the error printed is actually an improvement over the
current situation where any driver error just gets ignored.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Remove pointless check of hci_send_frame parameter
Marcel Holtmann [Thu, 10 Oct 2013 21:54:18 +0000 (14:54 -0700)]
Bluetooth: Remove pointless check of hci_send_frame parameter

The hdev parameter of hci_send_frame must be always valid. If the hdev
is not valid, it would not even make it to this stage. The callers
will have already accessed hdev at that point many times.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Move skb->dev assignment for hdev->send into central place
Marcel Holtmann [Thu, 10 Oct 2013 21:54:17 +0000 (14:54 -0700)]
Bluetooth: Move skb->dev assignment for hdev->send into central place

The assignement of skb->dev is done all over the place. So it makes it
hard to eventually get rid of it. Move it all in one central place so
it gets assigned right before calling hdev->send driver callback.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Move smp.h header file into net/bluetooth/
Marcel Holtmann [Thu, 10 Oct 2013 21:54:16 +0000 (14:54 -0700)]
Bluetooth: Move smp.h header file into net/bluetooth/

The smp.h header file is only used internally by the bluetooth.ko
module and is not a public API. So make it local to the core
Bluetooth module.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Move a2mp.h header file into net/bluetooth/
Marcel Holtmann [Thu, 10 Oct 2013 21:54:15 +0000 (14:54 -0700)]
Bluetooth: Move a2mp.h header file into net/bluetooth/

The a2mp.h header file is only used internally by the bluetooth.ko
module and is not a public API. So make it local to the core
Bluetooth module.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Move amp.h header file into net/bluetooth/
Marcel Holtmann [Thu, 10 Oct 2013 21:54:14 +0000 (14:54 -0700)]
Bluetooth: Move amp.h header file into net/bluetooth/

The amp.h header file is only used internally by the bluetooth.ko
module and is not a public API. So make it local to the core
Bluetooth module.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Remove hdev->ioctl driver callback
Marcel Holtmann [Thu, 10 Oct 2013 17:50:06 +0000 (10:50 -0700)]
Bluetooth: Remove hdev->ioctl driver callback

Since there is no use of hdev->ioctl by any Bluetooth driver since
ever, so just lets remove it.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Remove unused btmrvl_ioctl() callback
Marcel Holtmann [Thu, 10 Oct 2013 17:50:05 +0000 (10:50 -0700)]
Bluetooth: Remove unused btmrvl_ioctl() callback

The btmrvl_ioctl() function is not used and thus remove it.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Remove unused dtl1_hci_ioctl() callback
Marcel Holtmann [Thu, 10 Oct 2013 17:50:04 +0000 (10:50 -0700)]
Bluetooth: Remove unused dtl1_hci_ioctl() callback

The dtl1_hci_ioctl() function is not used and thus remove it.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Remove unused btuart_hci_ioctl() callback
Marcel Holtmann [Thu, 10 Oct 2013 17:50:03 +0000 (10:50 -0700)]
Bluetooth: Remove unused btuart_hci_ioctl() callback

The btuart_hci_ioctl() function is not used and thus remove it.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Remove unused bt3c_hci_ioctl() callback
Marcel Holtmann [Thu, 10 Oct 2013 17:50:02 +0000 (10:50 -0700)]
Bluetooth: Remove unused bt3c_hci_ioctl() callback

The bt3c_hci_ioctl() function is not used and thus remove it.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Remove unused bluecard_hci_ioctl() callback
Marcel Holtmann [Thu, 10 Oct 2013 17:50:01 +0000 (10:50 -0700)]
Bluetooth: Remove unused bluecard_hci_ioctl() callback

The bluecard_hci_ioctl() function is not used and thus remove it.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Remove unused bfusb_ioctl() callback
Marcel Holtmann [Thu, 10 Oct 2013 17:50:00 +0000 (10:50 -0700)]
Bluetooth: Remove unused bfusb_ioctl() callback

The bfusb_ioctl() function is not used and thus remove it.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: AMP contollers do not support the legacy ioctls
Marcel Holtmann [Thu, 10 Oct 2013 17:02:08 +0000 (10:02 -0700)]
Bluetooth: AMP contollers do not support the legacy ioctls

The legacy ioctls for device specific commands including inquiry are
not support by AMP controllers. So just reject them right away instead
of trying to send the HCI command and wait for failure from the
actual hardware.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Use hci_conn_num() instead of direct connection hash access
Marcel Holtmann [Thu, 10 Oct 2013 16:47:55 +0000 (09:47 -0700)]
Bluetooth: Use hci_conn_num() instead of direct connection hash access

When changing the alternate setting for the ISOC endpoints, use the
hci_conn_num() helper function to count currently established SCO
and eSCO connections and store the the value. This avoids direct
access to the connection hash.

In addition use the stored value instead accessing the connection
hash over and over again.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Use hci_conn_num() for checking number of LE connections
Marcel Holtmann [Thu, 10 Oct 2013 16:47:54 +0000 (09:47 -0700)]
Bluetooth: Use hci_conn_num() for checking number of LE connections

When checking for the current number of LE connections, use
hci_conn_num() function instead of a full blown lookup within
the connection hash or direct access of the counters.

In the case of re-enabling advertising, it is more useful to
check for any connection attempt or existing connection.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Fix too long line with set_advertising() function
Marcel Holtmann [Thu, 10 Oct 2013 16:47:53 +0000 (09:47 -0700)]
Bluetooth: Fix too long line with set_advertising() function

The function declaration goes over 80 characters, so break it down.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Fix checking for HCI_SETUP flag when receiving mgmt commands
Johan Hedberg [Thu, 10 Oct 2013 16:06:04 +0000 (18:06 +0200)]
Bluetooth: Fix checking for HCI_SETUP flag when receiving mgmt commands

When the HCI_SETUP flag is set the controller has not yet been announced
over mgmt and therefore doesn't exist from that perspective. If we
nevertheless get a mgmt command for it we should respond with the
appropriate INVALID_INDEX error.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
11 years agoBluetooth: Fix potential double-frees of L2CAP skbs
Johan Hedberg [Thu, 10 Oct 2013 11:33:37 +0000 (13:33 +0200)]
Bluetooth: Fix potential double-frees of L2CAP skbs

The l2cap_recv_frame function is expected to take ownership and
eventually free the skb passed to it. We need to ensure that the
conn->rx_skb pointer is no longer reachable when calling
l2cap_recv_frame so that no other function, such as l2cap_conn_del, may
think that it can free conn->rx_skb.

An actual situation when this can happen is when smp_sig_channel (called
from l2cap_recv_frame) fails and l2cap_conn_del gets called as a
consequence. The l2cap_conn_del function would then try to free
conn->rx_skb, but as the same skb was just passed to smp_sig_channel and
freed we get a double-free.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
11 years agoBluetooth: Restrict high speed support to SSP enabled controllers
Marcel Holtmann [Thu, 10 Oct 2013 10:08:11 +0000 (03:08 -0700)]
Bluetooth: Restrict high speed support to SSP enabled controllers

The support for Bluetooth High Speed can only be enabled on controllers
where also Secure Simple Pairing has been enabled. Trying to enable
high speed when SSP is disabled will result into an error. Disabling
SSP will at the same time disable high speed as well.

It is required to enforce this dependency on SSP since high speed
support is only defined for authenticated, unauthenticated and
debug link keys. These link key types require SSP.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Remove unneeded val variable when setting SSP
Marcel Holtmann [Thu, 10 Oct 2013 10:08:10 +0000 (03:08 -0700)]
Bluetooth: Remove unneeded val variable when setting SSP

The variable val in the set_ssp() function of the management interface
is not needed. Just use cp->val directly since its input values have
already been validated.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Refactor hci_connect_le
Andre Guedes [Tue, 8 Oct 2013 11:21:18 +0000 (08:21 -0300)]
Bluetooth: Refactor hci_connect_le

This patch does some code refactoring in hci_connect_le() by moving
the exception code into if statements and letting the main flow in
first level of function scope. It also adds extra comments to improve
the code readability.

Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
11 years agoBluetooth: Use HCI request for LE connection
Andre Guedes [Tue, 8 Oct 2013 11:21:17 +0000 (08:21 -0300)]
Bluetooth: Use HCI request for LE connection

This patch introduces a new helper, which uses the HCI request
framework, for creating LE connectons. All the handling is now
done by this function so we can remove the hci_cs_le_create_conn()
event handler.

This patch also removes the old hci_le_create_connection() since
it is not used anymore.

Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
11 years agoBluetooth: Fix changing advertising setting while LE is connected
Johan Hedberg [Tue, 8 Oct 2013 13:52:18 +0000 (15:52 +0200)]
Bluetooth: Fix changing advertising setting while LE is connected

We only (re)enable advertising when LE is disconnected. Trying to enable
advertising using mgmt_set_advertising while connected should simply
change the flag but not do anything else (until the connection gets
dropped). This patch fixes this by making an LE connection lookup to
determine whether there are any connected devices or not.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
11 years agoBluetooth: Fix variable shadow warnings
Johannes Berg [Mon, 7 Oct 2013 16:19:16 +0000 (18:19 +0200)]
Bluetooth: Fix variable shadow warnings

Sparse points out three places where variables are shadowed,
rename two of the variables and remove the duplicate third.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
11 years agoBluetooth: Read flow control mode on AMP controller init
Marcel Holtmann [Mon, 7 Oct 2013 10:55:53 +0000 (03:55 -0700)]
Bluetooth: Read flow control mode on AMP controller init

When initializing an AMP controller, read its current flow control
mode so that the correct value is used.

The AMP controller defaults to block based flow control and this
extra command is just to double check.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Read location data on AMP controller init
Marcel Holtmann [Mon, 7 Oct 2013 10:55:52 +0000 (03:55 -0700)]
Bluetooth: Read location data on AMP controller init

When initializing an AMP controller, read its current known location
data so that it can be analyzed later on.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Read supported features and commands on AMP controllers
Marcel Holtmann [Mon, 7 Oct 2013 09:31:39 +0000 (02:31 -0700)]
Bluetooth: Read supported features and commands on AMP controllers

The commands for reading supported features and commands are both
supported by AMP controllers. Issue them during controller init
phase so their values are known.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: List powered down AMP controllers correctly
Marcel Holtmann [Mon, 7 Oct 2013 07:58:34 +0000 (00:58 -0700)]
Bluetooth: List powered down AMP controllers correctly

Within the AMP discover response, list powered down AMP controllers
as powered down. No point in trying to make them look any different.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Make mgmt power down notification for BR/EDR explicit
Marcel Holtmann [Mon, 7 Oct 2013 07:58:33 +0000 (00:58 -0700)]
Bluetooth: Make mgmt power down notification for BR/EDR explicit

The management interface only operates on BR/EDR controllers. The check
for the power down notification is a bit intermixed with the check if
controller auto power off is active. Since there are more than just
BR/EDR controllers supported, make this check explicit since the auto
power off check also applies to AMP controllers and it has to happen
in this exact order. Otherwise the bit will not be cleared.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Power off AMP controllers after setup phase
Marcel Holtmann [Mon, 7 Oct 2013 07:58:32 +0000 (00:58 -0700)]
Bluetooth: Power off AMP controllers after setup phase

Even AMP controllers should be powered off after the setup phase. It
is not a good idea to keep AMP controllers powered on all the time
if they are not in use.

Power on of the AMP controller can either be done manually via
command line commands or directly via A2MP. Especially since there
is an indication in A2MP for powered down controllers that can
be activated.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Make mgmt_discovering() return void
Marcel Holtmann [Mon, 7 Oct 2013 06:55:53 +0000 (23:55 -0700)]
Bluetooth: Make mgmt_discovering() return void

The return value of mgmt_discovering() function is not used
and so just change it to return void.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Make mgmt_remote_name() return void
Marcel Holtmann [Mon, 7 Oct 2013 06:55:52 +0000 (23:55 -0700)]
Bluetooth: Make mgmt_remote_name() return void

The return value of mgmt_remote_name() function is not used
and so just change it to return void.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Make mgmt_device_found() return void
Marcel Holtmann [Mon, 7 Oct 2013 06:55:51 +0000 (23:55 -0700)]
Bluetooth: Make mgmt_device_found() return void

The return value of mgmt_device_found() function is not used
and so just change it to return void.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Make mgmt_device_disconnected() return void
Marcel Holtmann [Mon, 7 Oct 2013 06:55:50 +0000 (23:55 -0700)]
Bluetooth: Make mgmt_device_disconnected() return void

The return value of mgmt_device_disconnected() function is not used
and so just change it to return void.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Make mgmt_device_connected() return void
Marcel Holtmann [Mon, 7 Oct 2013 06:55:49 +0000 (23:55 -0700)]
Bluetooth: Make mgmt_device_connected() return void

The return value of mgmt_device_connected() function is not used
and so just change it to return void.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Make mgmt_connect_failed() return void
Marcel Holtmann [Mon, 7 Oct 2013 06:55:48 +0000 (23:55 -0700)]
Bluetooth: Make mgmt_connect_failed() return void

The return value of mgmt_connect_failed() function is not used
so change it to just return void.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Make mgmt_disconnect_failed() return void
Marcel Holtmann [Mon, 7 Oct 2013 06:55:47 +0000 (23:55 -0700)]
Bluetooth: Make mgmt_disconnect_failed() return void

The return value of mgmt_disconnect_failed() function is not used
so change it to just return void.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Make mgmt_set_powered_failed() return void
Marcel Holtmann [Mon, 7 Oct 2013 06:55:46 +0000 (23:55 -0700)]
Bluetooth: Make mgmt_set_powered_failed() return void

The return value of mgmt_set_powered_failed() function is never used
and so make the function just return void.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Make mgmt_index_added() and mgmt_index_removed() return void
Marcel Holtmann [Mon, 7 Oct 2013 06:55:45 +0000 (23:55 -0700)]
Bluetooth: Make mgmt_index_added() and mgmt_index_removed() return void

The return value from mgmt_index_added() and mgmt_index_removed()
functions is never used. So do not pretend that returning an error
would actually be handled and just make both functions return void.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Send new settings only when pairable changes
Marcel Holtmann [Sun, 6 Oct 2013 23:11:57 +0000 (16:11 -0700)]
Bluetooth: Send new settings only when pairable changes

In case the current value of pairable is already configured, do not
send a new settings event indicating that something has changed while
in reality everything is the same.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Remove mgmt_valid_hdev() helper function
Marcel Holtmann [Sun, 6 Oct 2013 15:25:01 +0000 (08:25 -0700)]
Bluetooth: Remove mgmt_valid_hdev() helper function

The helper function mgmt_valid_hdev() is more obfuscating the code
then it makes it easier to read. So intead of this helper, use the
direct check for BR/EDR device type.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Remove no longer needed mgmt_new_settings() function
Marcel Holtmann [Sun, 6 Oct 2013 11:11:12 +0000 (04:11 -0700)]
Bluetooth: Remove no longer needed mgmt_new_settings() function

The mgmt_new_settings() function was only needed to handle the
error case when re-enabling advertising failed. Since that is
now handled internally inside the management core, this function
is not needed anymore. So just remove it.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Use helper function for re-enabling advertising
Marcel Holtmann [Sun, 6 Oct 2013 11:08:14 +0000 (04:08 -0700)]
Bluetooth: Use helper function for re-enabling advertising

When the all LE connections have been disconneted, then it is up to
the host to re-enable advertising at that point. To ensure that the
correct advertising parameters are used, force the usage of the
common helper to enable advertising.

The change just moves the manual enabling of advertising from the
event handler into the management core so that the helper can
be actually shared.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Set LE advertising parameters before enabling it
Marcel Holtmann [Sun, 6 Oct 2013 10:17:56 +0000 (03:17 -0700)]
Bluetooth: Set LE advertising parameters before enabling it

The LE advertising parameters can only be modified when advertising
is disabled. So before enabling it, make sure the controller has all
the right parameters.

Right now all default values are used and thus this does no change
any existing behavior. One minor exception is that in case of single
mode LE-only controllers without a public address, now the random
address is used for advertising.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Add constants for LE advertising types
Marcel Holtmann [Sun, 6 Oct 2013 10:03:46 +0000 (03:03 -0700)]
Bluetooth: Add constants for LE advertising types

Add constants for ADV_IND, ADV_DIRECT_IND, ADV_SCAN_IND and
ADV_NONCONN_IND advertising types.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Use helper functions for enabling/disabling advertising
Marcel Holtmann [Sun, 6 Oct 2013 09:55:21 +0000 (02:55 -0700)]
Bluetooth: Use helper functions for enabling/disabling advertising

The tasks of enabling and disabling advertising are required in many
cases. So refactor the actual HCI operations into two common helpers
to make the code simpler.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Make it clear that disabling LE disables advertising
Marcel Holtmann [Sun, 6 Oct 2013 09:40:43 +0000 (02:40 -0700)]
Bluetooth: Make it clear that disabling LE disables advertising

This is not a functional change, just change the code to make it easy
to understand that advertising gets disabled before LE support will
be turned off.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Add HCI structure for LE advertising parameters command
Marcel Holtmann [Sun, 6 Oct 2013 09:34:38 +0000 (02:34 -0700)]
Bluetooth: Add HCI structure for LE advertising parameters command

Add the basic HCI structure for building the LE advertising parameters
command.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Use random address if public address is not available
Marcel Holtmann [Sun, 6 Oct 2013 09:08:36 +0000 (02:08 -0700)]
Bluetooth: Use random address if public address is not available

For single mode LE-only controllers, it is possible that they come
without a public address. If a public address is not available,
then use the random address for connection establishment and
scanning.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Simplify device type check for AMP discover response
Marcel Holtmann [Sun, 6 Oct 2013 09:08:35 +0000 (02:08 -0700)]
Bluetooth: Simplify device type check for AMP discover response

When counting the number for AMP controllers, a positive check is
used. To be consistent, use the same check when actually adding
the data for the AMP contollers.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Use explicit check for BR/EDR device type
Marcel Holtmann [Sun, 6 Oct 2013 08:16:22 +0000 (01:16 -0700)]
Bluetooth: Use explicit check for BR/EDR device type

The BR/EDR and LE setup procedures apply only to BR/EDR device types
and so check for that explicitly. Checking that it is not an AMP
controller is dangerous in case there will be ever a third device
type.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Reject enabling controllers without valid addresses
Marcel Holtmann [Sun, 6 Oct 2013 08:08:57 +0000 (01:08 -0700)]
Bluetooth: Reject enabling controllers without valid addresses

In case of a single mode LE-only controller it is possible that no
public address is used. These type of controllers require a random
address to be configured.

Without a configured static random address, such a controller is
not functional. So reject powering on the controller in this case
until it gets configured with a random address.

The controller setup stage is still run since it is the only way
to determinate if a public address is available or not. So it is
similar on how RFKILL gets handled during initial setup of the
controller.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Check for non BR/EDR controller in AMP discover response
Marcel Holtmann [Sat, 5 Oct 2013 20:57:53 +0000 (13:57 -0700)]
Bluetooth: Check for non BR/EDR controller in AMP discover response

Within the AMP discover response, all controllers that are not the
primary BR/EDR controller are valid.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Simplify check if L2CAP connection is AMP capable
Marcel Holtmann [Sat, 5 Oct 2013 18:47:49 +0000 (11:47 -0700)]
Bluetooth: Simplify check if L2CAP connection is AMP capable

The check if a L2CAP connection is AMP capable was a little bit
complicated. This changes the code to make it simpler and more
readable.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Move hci_amp_capable() function into L2CAP core
Marcel Holtmann [Sat, 5 Oct 2013 18:47:48 +0000 (11:47 -0700)]
Bluetooth: Move hci_amp_capable() function into L2CAP core

The hci_amp_capable() function has only a single user inside the L2CAP
core. Instead of exporting the function, place it next to its user.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Remove check for number of AMP controller
Marcel Holtmann [Sat, 5 Oct 2013 18:47:47 +0000 (11:47 -0700)]
Bluetooth: Remove check for number of AMP controller

The number of controllers for the AMP discover response has already
been calculated. And since the hci_dev_list lock is held, it can not
change. So there is no need for any extra checks.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Remove pointless inline function
Marcel Holtmann [Sat, 5 Oct 2013 18:47:46 +0000 (11:47 -0700)]
Bluetooth: Remove pointless inline function

The inline function for BR/EDR controller AMP discover response
info is rather useless. Just include the code into the function
that builds the whole response.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Rename AMP status constants and use them
Marcel Holtmann [Sat, 5 Oct 2013 18:47:45 +0000 (11:47 -0700)]
Bluetooth: Rename AMP status constants and use them

The AMP controller status constants need to be actually used to avoid
crypted hardcoded numbers.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Use explicit AMP controller id value for BR/EDR
Marcel Holtmann [Sat, 5 Oct 2013 18:47:44 +0000 (11:47 -0700)]
Bluetooth: Use explicit AMP controller id value for BR/EDR

The special AMP controller id 0 is reserved for the BR/EDR controller
that has the main link. It is a fixed value and so use a constant for
this throughout the code to make it more visible when the handling is
for the BR/EDR channel or when it is for the AMP channel.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Separate AMP controller type from HCI device type
Marcel Holtmann [Sat, 5 Oct 2013 18:47:43 +0000 (11:47 -0700)]
Bluetooth: Separate AMP controller type from HCI device type

There are two defined HCI device types. One is for BR/EDR controllers
and the other is for AMP controllers. The HCI device type is not the
same as the AMP controller type. It just happens that currently the
defined types match, but that is not guaranteed.

Split the usage of AMP controller type into its own domain so that
it is possible to separate between BR/EDR controllers, 802.11 AMP
controllers and any other AMP technology that might be defined in
the future.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Add constants for AMP controller type
Marcel Holtmann [Sat, 5 Oct 2013 18:47:42 +0000 (11:47 -0700)]
Bluetooth: Add constants for AMP controller type

Add the constants for BR/EDR and 802.11 AMP controller types.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Remove useless external function to count controllers
Marcel Holtmann [Sat, 5 Oct 2013 18:47:41 +0000 (11:47 -0700)]
Bluetooth: Remove useless external function to count controllers

The list of controllers can be counted ahead of time and inline
inside the AMP discover handling. There is no need to export such
a function at all.

In addition just count the AMP controller and only allocated space
for a single mandatory BR/EDR controller. No need to allocate more
space than needed.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Fix controller list for AMP discover response
Marcel Holtmann [Sat, 5 Oct 2013 18:47:40 +0000 (11:47 -0700)]
Bluetooth: Fix controller list for AMP discover response

The AMP discover response should list exactly one BR/EDR controller
and ignore all other BR/EDR controller.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Fix re-enabling advertising after a connection
Johan Hedberg [Sat, 5 Oct 2013 10:01:06 +0000 (12:01 +0200)]
Bluetooth: Fix re-enabling advertising after a connection

LE controllers will automatically disable advertising whenever they
accept a new connection. In order not to fall out of sync with the
advertising setting we need to re-enable advertising whenever the last
LE connection drops. A failure to re-enable advertising should cause the
setting to be disabled, so this patch also calls mgmt_new_settings()
when this happens.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
11 years agoBluetooth: Add public mgmt function to send New Settings event
Johan Hedberg [Sat, 5 Oct 2013 10:01:05 +0000 (12:01 +0200)]
Bluetooth: Add public mgmt function to send New Settings event

A function is needed so that the HCI event processing can ask the mgmt
code to emit a new settings event. This is necessary e.g. when the event
processing does updates to mgmt related states without any dependency of
actual mgmt commands.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
11 years agoBluetooth: Rename HCI_LE_PERIPHERAL to HCI_ADVERTISING
Johan Hedberg [Sat, 5 Oct 2013 10:01:04 +0000 (12:01 +0200)]
Bluetooth: Rename HCI_LE_PERIPHERAL to HCI_ADVERTISING

This flag is used to indicate whether we want to have advertising
enabled or not, so give it a more suitable name.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
11 years agoBluetooth: Initialize hci_conn fields in hci_connect_le
Andre Guedes [Thu, 3 Oct 2013 21:25:45 +0000 (18:25 -0300)]
Bluetooth: Initialize hci_conn fields in hci_connect_le

This patch moves some hci_conn fields initialization from hci_le_
create_connection() to hci_connect_le(). It makes more sense to
initialize these fields within the function that creates the hci_
conn object.

Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
11 years agoBluetooth: Rename hci_conn variable in hci_connect_le()
Andre Guedes [Thu, 3 Oct 2013 21:25:44 +0000 (18:25 -0300)]
Bluetooth: Rename hci_conn variable in hci_connect_le()

This patch simply rename the hci_conn variable "le" to "conn"
since it is a better name.

Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
11 years agoBluetooth: Only one command per L2CAP LE signalling is supported
Marcel Holtmann [Thu, 3 Oct 2013 08:26:37 +0000 (01:26 -0700)]
Bluetooth: Only one command per L2CAP LE signalling is supported

The Bluetooth specification makes it clear that only one command
should be present in the L2CAP LE signalling packet. So tighten
the checks here and restrict it to exactly one command.

This is different from L2CAP BR/EDR signalling where multiple
commands can be part of the same packet.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Check minimum length of SMP packets
Marcel Holtmann [Thu, 3 Oct 2013 08:23:08 +0000 (01:23 -0700)]
Bluetooth: Check minimum length of SMP packets

When SMP packets are received, make sure they contain at least 1 byte
header for the opcode. If not, drop the packet and disconnect the link.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Drop packets on ATT fixed channel on BR/EDR
Marcel Holtmann [Thu, 3 Oct 2013 09:54:11 +0000 (02:54 -0700)]
Bluetooth: Drop packets on ATT fixed channel on BR/EDR

The ATT fixed channel is only valid when using LE connections. On
BR/EDR it is required to go through L2CAP connection oriented
channel for ATT.

Drop ATT packets when they are received on a BR/EDR connection.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: L2CAP connectionless channels are only valid for BR/EDR
Marcel Holtmann [Thu, 3 Oct 2013 07:03:39 +0000 (00:03 -0700)]
Bluetooth: L2CAP connectionless channels are only valid for BR/EDR

When receiving connectionless packets on a LE connection, just drop
the packet. There is no concept of connectionless channels for LE.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: SMP packets are only valid on LE connections
Marcel Holtmann [Thu, 3 Oct 2013 07:00:57 +0000 (00:00 -0700)]
Bluetooth: SMP packets are only valid on LE connections

When receiving SMP packets on a BR/EDR connection, then just drop
the packet and do not try to process it.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Don't copy L2CAP LE signalling to raw sockets
Marcel Holtmann [Thu, 3 Oct 2013 06:51:49 +0000 (23:51 -0700)]
Bluetooth: Don't copy L2CAP LE signalling to raw sockets

The L2CAP raw sockets are only used for BR/EDR signalling. Packets
on LE links should not be forwarded there.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Fix switch statement order for L2CAP fixed channels
Marcel Holtmann [Thu, 3 Oct 2013 06:46:54 +0000 (23:46 -0700)]
Bluetooth: Fix switch statement order for L2CAP fixed channels

The switch statement for the various L2CAP fixed channel handlers
is not really ordered.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Allow changing device class when BR/EDR is disabled
Marcel Holtmann [Thu, 3 Oct 2013 06:37:29 +0000 (23:37 -0700)]
Bluetooth: Allow changing device class when BR/EDR is disabled

Changing the device class when BR/EDR is disabled has no visible
effect for remote devices. However to simplify the logic allow it
as long as the controller supports BR/EDR operations.

If it is not allowed, then the overall logic becomes rather
complicated since the class of device values would need clearing
or restoring when BR/EDR setting changes.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Restrict loading of long term keys to LE capable controllers
Marcel Holtmann [Thu, 3 Oct 2013 04:16:08 +0000 (21:16 -0700)]
Bluetooth: Restrict loading of long term keys to LE capable controllers

Loading long term keys into a BR/EDR only controller make no sense.
The kernel would never use any of these keys. So instead of allowing
userspace to waste memory, reject such operation with a not supported
error message.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Restrict loading of link keys to BR/EDR capable controllers
Marcel Holtmann [Thu, 3 Oct 2013 04:16:07 +0000 (21:16 -0700)]
Bluetooth: Restrict loading of link keys to BR/EDR capable controllers

Loading link keys into a LE only controller make no sense. The kernel
would never use any of these keys. So instead of allowing userspace
to waste memory, reject such operation with a not supported error
message.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Allow setting static address even if LE is disabled
Marcel Holtmann [Thu, 3 Oct 2013 05:10:32 +0000 (22:10 -0700)]
Bluetooth: Allow setting static address even if LE is disabled

Setting the static address does not depend on LE beeing enabled. It
only depends on a controller with LE support.

When depending on LE enabled this command becomes really complicated
since in case LE gets disabled, it would be required to clear the
static address and also its random address representation inside
the controller. With future support for private addresses such
complex setup should be avoided.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Restrict SSP setting changes to BR/EDR enabled controllers
Marcel Holtmann [Thu, 3 Oct 2013 04:31:52 +0000 (21:31 -0700)]
Bluetooth: Restrict SSP setting changes to BR/EDR enabled controllers

Only when BR/EDR is supported and enabled, allow changing of the SSP
setting. Just checking if the hardware supports SSP is not enough
since it might be the case that BR/EDR is disabled.

In the case that BR/EDR is disabled, but SSP supported by the
controller the not supported error message is now returned.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Fix memory leak with L2CAP signal channels
Marcel Holtmann [Wed, 2 Oct 2013 15:28:21 +0000 (08:28 -0700)]
Bluetooth: Fix memory leak with L2CAP signal channels

The wrong type of L2CAP signalling packets on the wrong type of
either BR/EDR or LE links need to be dropped. When that happens
the packet is dropped, but the memory not freed. So actually
free the memory as well.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
11 years agoBluetooth: Add the definition for Slave Page Response Timeout
DoHyun Pyun [Wed, 2 Oct 2013 12:54:53 +0000 (21:54 +0900)]
Bluetooth: Add the definition for Slave Page Response Timeout

The Slave Page Response Timeout event indicates to the Host that a
slave page response timeout has occurred in the BR/EDR Controller.

The Core Spec Addendum 4 adds this command in part B Connectionless
Slave Broadcast.

Bluetooth Core Specification Addendum 4 - Page 110

"7.7.72 Slave Page Response Timeout Event [New Section]
...
Note: this event will be generated if the slave BR/EDR Controller
responds to a page but does not receive the master FHS packet
(see Baseband, Section 8.3.3) within pagerespTO.

Event Parameters: NONE"

Signed-off-by: Dohyun Pyun <dh79.pyun@samsung.com>
Signed-off-by: C S Bhargava <cs.bhargava@samsung.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
11 years agoBluetooth: Add the definition and stcuture for Sync Train Complete
DoHyun Pyun [Wed, 2 Oct 2013 12:54:52 +0000 (21:54 +0900)]
Bluetooth: Add the definition and stcuture for Sync Train Complete

The Synchronization Train Complete event indicates that the Start
Synchronization Train command has completed.

The Core Spec Addendum 4 adds this command in part B Connectionless
Slave Broadcast.

Bluetooth Core Specification Addendum 4 - Page 103

"7.7.67 Synchronization Train Complete Event [New Section]
...

Event Parameters:

Status 0x00       Start Synchronization Train command completed
                  successfully.
       0x01-0xFF  Start Synchronization Train command failed.
                  See Part D, Error Codes, for error codes and
                  descriptions."

Signed-off-by: Dohyun Pyun <dh79.pyun@samsung.com>
Signed-off-by: C S Bhargava <cs.bhargava@samsung.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>