sdk/emulator/emulator-kernel.git
11 years agoBluetooth: Add l2cap_state_change_and_error()
Gustavo Padovan [Tue, 15 Oct 2013 22:24:46 +0000 (19:24 -0300)]
Bluetooth: Add l2cap_state_change_and_error()

l2cap_state_change_and_error() introduces the ability to update a
l2cap_user with changes in channel's state and error code with just one
call. The main reason for this is to avoid race conditions between and
setting the state and then the error. Otherwise we would need to release
the lock between both operations.

This is another step of an ongoing work to make l2cap_core.c totally
independent from l2cap's struct sock.

Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
11 years agoBluetooth: Extend state_change() call to report errors too
Gustavo Padovan [Tue, 15 Oct 2013 22:24:45 +0000 (19:24 -0300)]
Bluetooth: Extend state_change() call to report errors too

Instead of creating an new function pointer to report errors we are just
reusing state_change for that and there is a simple reason for this, one
place in the l2cap_core.c code needs, in a locked sk, set both the sk_state
and sk_err. If we create two different functions for this we would need to
release the lock between the two operation putting the socket in non
desired state.

The change is transparent to the l2cap_core.c code, user that only needs
to set the state won't need any modification.

This is another step of an ongoing work to make l2cap_core.c totally
independent from l2cap's struct sock.

Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
11 years agoBluetooth: Update class of device on discoverable timeout
Marcel Holtmann [Tue, 15 Oct 2013 17:57:40 +0000 (10:57 -0700)]
Bluetooth: Update class of device on discoverable timeout

When the discoverable timeout triggers and limited discoverable mode
was used, then the class of device needs to be updated to remove
the limited discoverable bit.

To keep the class of device logic in a central place, expose a new
function mgmt_discoverable_timeout that can be called from the
timeout callback. In case the class of device value needs updating,
it will add the HCI command to the transaction.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Move eir_get_length() function into hci_event.c
Marcel Holtmann [Tue, 15 Oct 2013 17:31:12 +0000 (10:31 -0700)]
Bluetooth: Move eir_get_length() function into hci_event.c

The eir_get_length() function is only used from hci_event.c and so
instead of having a public function move it to the location where
it is used.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Move eir_append_data() function into mgmt.c
Marcel Holtmann [Tue, 15 Oct 2013 17:26:39 +0000 (10:26 -0700)]
Bluetooth: Move eir_append_data() function into mgmt.c

The eir_append_data() function is only used from mgmt.c and so
instead of having a public function move it to the location where
it is used.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Make mgmt_new_link_key() return void
Marcel Holtmann [Tue, 15 Oct 2013 17:15:57 +0000 (10:15 -0700)]
Bluetooth: Make mgmt_new_link_key() return void

The return value of mgmt_new_link_key() 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: Add support for entering limited discoverable mode
Marcel Holtmann [Tue, 15 Oct 2013 16:13:39 +0000 (09:13 -0700)]
Bluetooth: Add support for entering limited discoverable mode

The limited discoverable mode should be used when a device is only
discoverable for a certain amount of time and after that it returns
back into being non-discoverable.

This adds another option to the set discoverable management command
to clearly distinguish limited discoverable from general discoverable
mode.

While the general discoverable mode can be set with a specific
timeout or as permanent setting, the limited discoverable mode
requires a timeout. The timeout is flexible and the kernel will
not enforce any specific limitations. That GAP part of this is
required by userspace to enforce according to the Bluetooth core
specification.

Devices in limited discoverable mode can still be found by the
general discovery procedure. It is mandatory that a device sets
both GIAC and LIAC when entering limited discoverable mode.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Add HCI command structure for writing current IAC LAP
Marcel Holtmann [Tue, 15 Oct 2013 15:34:15 +0000 (08:34 -0700)]
Bluetooth: Add HCI command structure for writing current IAC LAP

This patch just adds the HCI command structure for configuring the
current IAC LAP setting. The length of the command is variable and
supports more than two IAC. However since there is only general
discoverable and limited discoverable modes, this can be limited
to two possible IACs.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Simplify the code for re-arming discoverable timeout
Marcel Holtmann [Tue, 15 Oct 2013 15:28:51 +0000 (08:28 -0700)]
Bluetooth: Simplify the code for re-arming discoverable timeout

When only the discoverable timeout gets updated, just cancel the current
timeout, store the new timeout value. If the new timeout is valid, then
arm the discoverable timeout again.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Move arming of discoverable timeout to complete handler
Marcel Holtmann [Tue, 15 Oct 2013 15:11:02 +0000 (08:11 -0700)]
Bluetooth: Move arming of discoverable timeout to complete handler

The discoverable timeout is currently armed from hci_event.c and causes
some side effects when using HCI commands instead of the management
interface. To make this clear, only arm the discoverable timeout from
the management command complete handler.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Update class of device after changing discoverable mode
Marcel Holtmann [Tue, 15 Oct 2013 13:33:57 +0000 (06:33 -0700)]
Bluetooth: Update class of device after changing discoverable mode

When the discoverable mode gets changed, ensure that the class of
device value has the correct limited discoverable bit value set.

Since the class of device HCI command will only be send to the
controller when the value changes, it is safe to just always
trigger the update.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Make mgmt_write_scan_failed() return void
Marcel Holtmann [Tue, 15 Oct 2013 13:33:56 +0000 (06:33 -0700)]
Bluetooth: Make mgmt_write_scan_failed() return void

The return value of mgmt_write_scan_failed() 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_connectable() return void
Marcel Holtmann [Tue, 15 Oct 2013 13:33:55 +0000 (06:33 -0700)]
Bluetooth: Make mgmt_connectable() return void

The return value of mgmt_connectable() 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_discoverable() return void
Marcel Holtmann [Tue, 15 Oct 2013 13:33:54 +0000 (06:33 -0700)]
Bluetooth: Make mgmt_discoverable() return void

The return value of mgmt_discoverable() 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: Introduce flag for limited discoverable mode
Marcel Holtmann [Tue, 15 Oct 2013 13:33:53 +0000 (06:33 -0700)]
Bluetooth: Introduce flag for limited discoverable mode

Add a new flag that can be set when in limited discoverable mode. This
flag will cause the limited discoverable bit in the class of device
value to bet set.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Update advertising data based on management commands
Marcel Holtmann [Tue, 15 Oct 2013 13:33:52 +0000 (06:33 -0700)]
Bluetooth: Update advertising data based on management commands

Magically updating the advertising data when some random command enables
advertising in the controller is not really a good idea. It also caused
a bit of complicated code with the exported hci_udpate_ad function that
is shared from many places.

This patch consolidates the advertising data update into the management
core. It also makes sure that when powering on with LE enabled or later
on enabling LE the controller has a good default for advertising data.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Use hci_request for discoverable timeout handling
Marcel Holtmann [Tue, 15 Oct 2013 13:33:51 +0000 (06:33 -0700)]
Bluetooth: Use hci_request for discoverable timeout handling

When the discoverable timeout triggers and it is time to turn inquiry
scan back off, use the HCI request framework to do it.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Fix minor coding style issue in set_connectable()
Marcel Holtmann [Mon, 14 Oct 2013 23:38:45 +0000 (16:38 -0700)]
Bluetooth: Fix minor coding style issue in set_connectable()

There is a minor coding style violation and so just fix it. No actual
logic has changed.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
11 years agoBluetooth: Read current IAC LAP on controller setup
Marcel Holtmann [Mon, 14 Oct 2013 21:06:36 +0000 (14:06 -0700)]
Bluetooth: Read current IAC LAP on controller setup

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
11 years agoBluetooth: Fix updating advertising data needlessly
Johan Hedberg [Mon, 14 Oct 2013 13:20:07 +0000 (16:20 +0300)]
Bluetooth: Fix updating advertising data needlessly

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The bpa10x_table[] device table can be declared as const

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

The bfusb_table[] device table can be declared as const

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

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

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

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

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

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

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