Bluetooth: constify seq_operations

bt_seq_ops is only used with __seq_open_private as
const struct seq_operations *

Signed-off-by: Fabian Frederick <fabf@skynet.be>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: Allow L2CAP getpeername() for BT_CONFIG state

We have all the necessary remote information for getpeername() when we
are in the BT_CONFIG state so this should be allowed. This is
particularly important for LE sockets where changing the security level
will temporarily move the socket into BT_CONFIG state.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: Fallback to SCO on error code 0x10 (Connection Accept Timeout)

This is to support the Motorola HF850 carkit which reports the error
code 0x10 for an eSCO attempt, even though it advertises eSCO support.

With this patch we will retry with a SCO connection, which succeeds.

Signed-off-by: Nick Pelly <npelly@google.com>
Signed-off-by: Kiran Kumar Raparthy <kiran.kumar@linaro.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: Use bool for smp_ltk_encrypt return value

The return value of smp_ltk_encrypt is simple boolean, so just use
bool and make the code a bit more readable.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Bluetooth: Change hci_conn_params_add to return the parameter struct

When adding new connection parameters, it is useful to return either
the existing struct or the newly created one.

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

The hci_conn_params_add function provides the default allocation of
connection parameters. To avoid code duplication, use that code from
hci_conn_params_set to allocate or lookup parameter struct.

As a benefit the connection latency and supervision timeout parameters
are no longer reset to default when calling hci_conn_params_set.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Bluetooth: Remove connection interval parameters from hci_conn_params_set

The connection interval parameter of hci_conn_params_set are always used
with the controller defaults. So just let hci_conn_params_add set the
controller default and not bother resetting them to controller defaults
every time the hci_conn_params_set is called.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Bluetooth: Fix merge of advertising data and scan response data

The advertising data and scan response data are merged in the wrong
order. It should be advertsing data first and then scan response data
and not the other way around.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Cc: stable@vger.kernel.org # 3.16
Bluetooth: Provide flags parameter direct to mgmt_device_found

Providing the flags parameter directly to mgmt_device_found function
makes the core simpler and more readable. With this it becomes a lot
easier to add new flags in the future.

This also changes hci_inquiry_cache_update to just return that flags
needed for mgmt_device_found since that is its only use for the two
return parameters anyway.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Bluetooth: Add support for Not Connectable flag for Device Found events

The Device Found events of the management interface should indicate if
it is possible to connect to a remote device or if it is broadcaster
only advertising. To allow this differentation the Not Connectable flag
is introduced that will be set when it is known that a device can not
be connected.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Bluetooth: Fix redundant encryption when receiving Security Request

If we're already encrypted with a good enough LTK we should just ignore
an incoming SMP Security Request. The code was already taking care of
this in the smp_conn_security function before calling smp_ltk_encrypt
but failed to do the same in smp_cmd_security_req. This patch fixes the
issue by moving up the smp_sufficient_security function and using it in
the Security Request handler before trying to request encryption.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: Add flag to track STK encryption

There are certain subtle differences in behavior when we're encrypted
with the STK, such as allowing re-encryption even though the security
level stays the same. Because of this, add a flag to track whether we're
encrypted with an STK or not.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: Allow re-encryption with LTK when STK is in use

If we're encrypted with the STK we should allow re-encryption with an
LTK even though the achieved security level is the same. This patch adds
the necessary logic to the smp_sufficient_security function which is
used to determine whether to proceed with encryption or not.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: Do not trigger background scanning when HCI_AUTO_OFF is set

When a new controller is initialized, but not powered from userspace
at the moment, the HCI_AUTO_OFF flag is still set. During this period,
userspace might program device for auto-connection, but never power
on the controller. In this case do not try to start background
scanning and leave it for later to be started.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Bluetooth: Ensure that background scanning gets enabled on power on

The background scanning normally gets enabled during power on by
adding devices to the pending connection list. However devices
might be already on that list and the list of devices is empty,
then it is better to trigger the background manually.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Bluetooth: Fix redundant device (un)blocked events

For the Block/Unblock Device mgmt commands we should only emit the
Blocked/Unblocked events on any socket except for the one which received
the command. The code was previously incorrectly trying to look up a
non-existent pending command and thereby ending up not skipping the
command socket for the event.

We can simplify the code a lot by simply sending the event directly from
the command handler functions. We have the reference to the command
socket available there which makes it easy to pass to the mgmt_event
function for skipping.

The only notable side-effect of this is that the old blacklisting
ioctl's no-longer cause mgmt events to be emitted, however as user space
versions using these ioctl's are not mgmt-aware this is acceptable.

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

This patch adds support for LE Connection Parameters Request Link
Layer control procedure introduced in Core spec 4.1. This procedure
allows a Peripheral or Central to update the Link Layer connection
parameters of an established connection.

Regarding the acceptance of connection parameters, the LL procedure
follows the same approach of L2CAP procedure (see l2cap_conn_param_
update_req function). We accept any connection parameters values as
long as they are within the valid range.

Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Bluetooth: Move LE event mask setting into init3 phase

During init2 phase, the LE local features have not be read yet so
we aren't able to rely on hdev->le_features to determine if the
controller supports the Connection Parameters Request Procedure.

For that reason, this patch moves LE event mask setting from init2
into init3 initialization phase.

The hdev->le_features mask will be checked by the next patch in order
to know if "LE Remote Connection Parameter Request Event" should be
enabled.

Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Bluetooth: Enable new LE meta event

The Bluetooth 4.1 introduces a new LE meta event called "LE Remote
Connection Parameter Request" event. In order to the controller
sends this event to host, we should enable it during controller
initialization.

Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Bluetooth: Introduce "New Connection Parameter" Event

This patch introduces a new Mgmt event called "New Connection Parameter".
This event indicates to userspace the connection parameters values the
remote device requested.

The user may store these values and load them into kernel. This way, next
time a connection is established to that device, the kernel will use those
parameters values instead of the default ones.

This event is sent when the remote device requests new connection
parameters through connection parameter update procedure. This event is
not sent for slave connections.

Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>