summaryrefslogtreecommitdiffstats
path: root/net/bluetooth/hci_conn.c
Commit message (Collapse)AuthorAgeFilesLines
* Bluetooth: Fix redundant encryption request for reauthenticationJohan Hedberg2014-04-251-3/+6
| | | | | | | | | | | | | | When we're performing reauthentication (in order to elevate the security level from an unauthenticated key to an authenticated one) we do not need to issue any encryption command once authentication completes. Since the trigger for the encryption HCI command is the ENCRYPT_PEND flag this flag should not be set in this scenario. Instead, the REAUTH_PEND flag takes care of all necessary steps for reauthentication. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Cc: stable@vger.kernel.org
* Bluetooth: Enforce strict Secure Connections Only mode securityMarcel Holtmann2014-03-191-0/+11
| | | | | | | | | | In Secure Connections Only mode, it is required that Secure Connections is used for pairing and that the link key is encrypted with AES-CCM using a P-256 authenticated combination key. If this is not the case, then new connection shall be refused or existing connections shall be dropped. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Convert uses of __constant_<foo> to <foo>Joe Perches2014-03-121-13/+13
| | | | | | | | | The use of __constant_<foo> has been unnecessary for quite awhile now. Make these uses consistent with the rest of the kernel. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Remove unnecessary stop_scan_complete functionJohan Hedberg2014-02-281-43/+8
| | | | | | | | | | | | | | | The stop_scan_complete function was used as an intermediate step before doing the actual connection creation. Since we're using hci_request there's no reason to have this extra function around, i.e. we can simply put both HCI commands into the same request. The single task that the intermediate function had, i.e. indicating discovery as stopped is now taken care of by a new HCI_LE_SCAN_INTERRUPTED flag which allows us to do the discovery state update when the stop scan command completes. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Fix trying to disable scanning twiceJohan Hedberg2014-02-281-1/+0
| | | | | | | | | | | | | | | | The discovery process has a timer for disabling scanning, however scanning might be disabled through other means too like the auto-connect process. We should therefore ensure that the timer is never active after sending a HCI command to disable scanning. There was some existing code in stop_scan_complete trying to avoid the timer when a connect request interrupts a discovery procedure, but the other way around was not covered. This patch covers both scenarios by canceling the timer as soon as we get a successful command complete for the disabling HCI command. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Add timeout for LE connection attemptsJohan Hedberg2014-02-281-0/+13
| | | | | | | | | | | | | | | LE connection attempts do not have a controller side timeout in the same way as BR/EDR has (in form of the page timeout). Since we always do scanning before initiating connections the attempts are always expected to succeed in some reasonable time. This patch adds a timer which forces a cancellation of the connection attempt within 20 seconds if it has not been successful by then. This way we e.g. ensure that mgmt_pair_device times out eventually and gives an error response. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Fix updating connection state to BT_CONNECT too earlyJohan Hedberg2014-02-281-1/+2
| | | | | | | | | | | We shouldn't update the hci_conn state to BT_CONNECT until the moment that we're ready to send the initiating HCI command for it. If the connection has the BT_CONNECT state too early the code responsible for updating the local random address may incorrectly think there's a pending connection in progress and refuse to update the address. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Use __le64 type for LE random numbersMarcel Holtmann2014-02-281-3/+3
| | | | | | | | | | | The random numbers in Bluetooth Low Energy are 64-bit numbers and should also be little endian since the HCI specification is little endian. Change the whole Low Energy pairing to use __le64 instead of a byte array. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Introduce LE auto connection infrastructureAndre Guedes2014-02-261-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch introduces the LE auto connection infrastructure which will be used to implement the LE auto connection options. In summary, the auto connection mechanism works as follows: Once the first pending LE connection is created, the background scanning is started. When the target device is found in range, the kernel autonomously starts the connection attempt. If connection is established successfully, that pending LE connection is deleted and the background is stopped. To achieve that, this patch introduces the hci_update_background_scan() which controls the background scanning state. This function starts or stops the background scanning based on the hdev->pend_le_conns list. If there is no pending LE connection, the background scanning is stopped. Otherwise, we start the background scanning. Then, every time a pending LE connection is added we call hci_update_ background_scan() so the background scanning is started (in case it is not already running). Likewise, every time a pending LE connection is deleted we call hci_update_background_scan() so the background scanning is stopped (in case this was the last pending LE connection) or it is started again (in case we have more pending LE connections). Finally, we also call hci_update_background_scan() in hci_le_conn_failed() so the background scan is restarted in case the connection establishment fails. This way the background scanning keeps running until all pending LE connection are established. At this point, resolvable addresses are not support by this infrastructure. The proper support is added in upcoming patches. Signed-off-by: Andre Guedes <andre.guedes@openbossa.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Move address type conversion to outside hci_connect_leAndre Guedes2014-02-261-6/+0
| | | | | | | | | | | | This patch moves address type conversion (L2CAP address type to HCI address type) to outside hci_connect_le. This way, we avoid back and forth address type conversion in a comming patch. So hci_connect_le() now expects 'dst_type' parameter in HCI address type convention. Signed-off-by: Andre Guedes <andre.guedes@openbossa.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Refactor HCI connection codeAndre Guedes2014-02-261-20/+4
| | | | | | | | | | | | | hci_connect() is a very simple and useless wrapper of hci_connect_acl and hci_connect_le functions. Addtionally, all places where hci_connect is called the link type value is passed explicitly. This way, we can safely delete hci_connect, declare hci_connect_acl and hci_connect_le in hci_core.h and call them directly. No functionality is changed by this patch. Signed-off-by: Andre Guedes <andre.guedes@openbossa.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Remove unused functionAndre Guedes2014-02-261-43/+0
| | | | | | | This patch removes hci_create_le_conn() since it is not used anymore. Signed-off-by: Andre Guedes <andre.guedes@openbossa.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Stop scanning on LE connectionAndre Guedes2014-02-261-2/+90
| | | | | | | | | | | | | | | | | | | | | | | | Some LE controllers don't support scanning and creating a connection at the same time. So we should always stop scanning in order to establish the connection. Since we may prematurely stop the discovery procedure in favor of the connection establishment, we should also cancel hdev->le_scan_ disable delayed work and set the discovery state to DISCOVERY_STOPPED. This change does a small improvement since it is not mandatory the user stops scanning before connecting anymore. Moreover, this change is required by upcoming LE auto connection mechanism in order to work properly with controllers that don't support background scanning and connection establishment at the same time. In future, we might want to do a small optimization by checking if controller is able to scan and connect at the same time. For now, we want the simplest approach so we always stop scanning (even if the controller is able to carry out both operations). Signed-off-by: Andre Guedes <andre.guedes@openbossa.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Declare le_conn_failed in hci_core.hAndre Guedes2014-02-261-2/+2
| | | | | | | | This patch adds the "hci_" prefix to le_conn_failed() helper and declares it in hci_core.h so it can be reused in hci_event.c. Signed-off-by: Andre Guedes <andre.guedes@openbossa.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Use unresolvable private address for active scanningMarcel Holtmann2014-02-241-1/+4
| | | | | | | | | | | | | | When running active scanning during LE discovery, do not reveal the own identity to the peer devices. In case LE privacy has been enabled, then a resolvable private address is used. If the LE privacy option is off, then use an unresolvable private address. The public address or static random address is never used in active scanning anymore. This ensures that scan request are send using a random address. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Fix setting correct src_type when connecting LEJohan Hedberg2014-02-231-1/+2
| | | | | | | | | | This patch ensures that conn->src_type contains the same address type as is used for initiating the connection while the connection attempt is in progress. Once connected this value will be overwritten with the identity address type. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Use hci_update_random_address() when connecting LEJohan Hedberg2014-02-231-1/+7
| | | | | | | | | | | When we initiate LE connections we need to update the local random address if necessary. This patch updates the LE connection creation mechanism to use the new hci_update_random_address() function to set the own_address_type parameter and to update the local random address if necessary. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Use same LE min/max connection event length during updateMarcel Holtmann2014-02-191-2/+2
| | | | | | | | | | | | | During LE connection establishment the value 0x0000 is used for min/max connection event length. So use the same value when the peripheral is requesting an update of the the connection paramters. For some reason the value 0x0001 got used in the connection update and 0x0000 in the connection creation. Using the same value for both just makes sense. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Fix wrong identity address during connection failuresMarcel Holtmann2014-02-191-0/+13
| | | | | | | | | | | | | | When the connection attempt fails, the address information are not provided in the HCI_LE_Connection_Complete event. So use the original information from the connection to reconstruct the identity address. This is important when a connection attempt has been made using the identity address, but the cached resolvable random address has changed in the meantime. The failure event needs to use the identity address and not the resolvable random address. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Look up RPA for connection requests with Identity AddressJohan Hedberg2014-02-181-5/+14
| | | | | | | | | | | | | We need to check whether there's a matching IRK and RPA when we're requested to connect to a remote LE device based on its Identity Address. This patch updates the hci_connect_le function to do an extra call to hci_find_irk_by_addr and uses the RPA if it's cached. This is particularly important once we start exposing the Identity Address to user space instead of the RPA in events such as Device Connected and Device Found. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Use connection parameters if anyAndre Guedes2014-02-131-2/+10
| | | | | | | | | This patch changes hci_connect_le() so it uses the connection parameters specified for the certain device. If no parameters were configured, we use the default values. Signed-off-by: Andre Guedes <andre.guedes@openbossa.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Include security level 4 in connections checkMarcel Holtmann2014-02-131-4/+8
| | | | | | | | | | This check is only used for RFCOMM connections and most likely no RFCOMM based profile will require security level 4 secure connection security policy. In case it ever does make sure that seucrity level 4 is treated as sufficient security level. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Introduce le_conn_failed() helperAndre Guedes2014-02-131-8/+16
| | | | | | | | This patch moves connection attempt failure code to its own function so it can be reused in the next patch. Signed-off-by: Andre Guedes <andre.guedes@openbossa.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Save connection interval parameters in hci_connAndre Guedes2014-02-131-2/+4
| | | | | | | | | | | | This patch creates two new fields in struct hci_conn to save the minimum and maximum connection interval values used to establish the connection this object represents. This change is required in order to know what parameters the connection is currently using. Signed-off-by: Andre Guedes <andre.guedes@openbossa.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Introduce requirements for security level 4Marcel Holtmann2014-02-131-5/+13
| | | | | | | | | | | | | | | | | | | | | | The security level 4 is a new strong security requirement that is based around 128-bit equivalent strength for link and encryption keys required using FIPS approved algorithms. Which means that E0, SAFER+ and P-192 are not allowed. Only connections created with P-256 resulting from using Secure Connections support are allowed. This security level needs to be enforced when Secure Connection Only mode is enabled for a controller or a service requires FIPS compliant strong security. Currently it is not possible to enable either of these two cases. This patch just puts in the foundation for being able to handle security level 4 in the future. It should be noted that devices or services with security level 4 requirement can only communicate using Bluetooth 4.1 controllers with support for Secure Connections. There is no backward compatibilty if used with older hardware. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Add support for handling P-256 derived link keysMarcel Holtmann2014-02-131-2/+4
| | | | | | | | | | Before being able to enable Secure Connections support, the core needs to know on how to handle P-256 derived link keys. The difference between authenticated and unauthenticated P-256 derived link keys is the same as its P-192 counter parts. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Add definitions for new link key typesMarcel Holtmann2014-02-131-2/+2
| | | | | | | | | | | | | | With the introduction of Secure Connections, the list of link key types got extended by P-256 versions of authenticated and unauthenticated link keys. To avoid any confusion the previous authenticated and unauthenticated link key types got ammended with a P912 postfix. And the two new keys have a P256 postfix now. Existing code using the previous definitions has been adjusted. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Expose debugfs settings for LE connection intervalMarcel Holtmann2013-10-191-2/+3
| | | | | | | | For testing purposes expose the default LE connection interval values via debugfs. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Select the own address type during initial setup phaseMarcel Holtmann2013-10-191-6/+1
| | | | | | | | | The own address type is based on the fact if the controller has a public address or not. This means that this detail can be just configured once during setup phase. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Convert idle timer to use delayed workJohan Hedberg2013-10-161-15/+7
| | | | | | | | There is no need to use a timer since the entire Bluetooth subsystem runs using workqueues these days. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Convert auto accept timer to use delayed workJohan Hedberg2013-10-161-8/+6
| | | | | | | | Since the entire Bluetooth subsystem runs in workqueues these days there is no need to use a timer for deferring work. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Store source address of HCI connectionsMarcel Holtmann2013-10-131-2/+5
| | | | | | | | | | | | | 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>
* Bluetooth: Store the source address type of LE connectionsMarcel Holtmann2013-10-131-4/+7
| | | | | | | | | | 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>
* Bluetooth: Remove pointless bdaddr_to_le() helper functionMarcel Holtmann2013-10-131-1/+4
| | | | | | | | | | | | | | | | 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>
* Bluetooth: Make LE scan interval and window a controller optionMarcel Holtmann2013-10-111-2/+2
| | | | | | | | | | | | | 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>
* Bluetooth: Move smp.h header file into net/bluetooth/Marcel Holtmann2013-10-111-1/+1
| | | | | | | | | 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>
* Bluetooth: Move a2mp.h header file into net/bluetooth/Marcel Holtmann2013-10-111-1/+2
| | | | | | | | | 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>
* Bluetooth: Refactor hci_connect_leAndre Guedes2013-10-101-18/+33
| | | | | | | | | | 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>
* Bluetooth: Use HCI request for LE connectionAndre Guedes2013-10-101-24/+67
| | | | | | | | | | | | | 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>
* Bluetooth: Use random address if public address is not availableMarcel Holtmann2013-10-061-0/+4
| | | | | | | | | | 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>
* Bluetooth: Rename HCI_LE_PERIPHERAL to HCI_ADVERTISINGJohan Hedberg2013-10-051-1/+1
| | | | | | | | 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>
* Bluetooth: Initialize hci_conn fields in hci_connect_leAndre Guedes2013-10-031-5/+5
| | | | | | | | | | 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>
* Bluetooth: Rename hci_conn variable in hci_connect_le()Andre Guedes2013-10-031-13/+13
| | | | | | | | 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>
* Bluetooth: Introduce a new HCI_BREDR_ENABLED flagJohan Hedberg2013-10-021-0/+3
| | | | | | | | | | | | | | | | | | | To allow treating dual-mode (BR/EDR/LE) controllers as single-mode ones (LE-only) we want to introduce a new HCI_BREDR_ENABLED flag to track whether BR/EDR is enabled or not (previously we simply looked at the feature bit with lmp_bredr_enabled). This patch add the new flag and updates the relevant places to test against it instead of using lmp_bredr_enabled. The flag is by default enabled when registering an adapter and only cleared if necessary once the local features have been read during the HCI init procedure. We cannot completely block BR/EDR usage in case user space uses raw HCI sockets but the patch tries to block this in places where possible, such as the various BR/EDR specific ioctls. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Disable upper layer connections when user channel is activeMarcel Holtmann2013-09-161-0/+1
| | | | | | | | | | | | | When the device has the user channel flag set, it means it is driven by an user application. In that case do not allow any connections from L2CAP or SCO sockets. This is the same situation as when the device has the raw flag set and it will then return EHOSTUNREACH. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Acked-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
* Bluetooth: Add SCO connection fallbackFrédéric Dalleau2013-08-211-8/+36
| | | | | | | | | | | | | | | | | | | | | When initiating a transparent eSCO connection, make use of T2 settings at first try. T2 is the recommended settings from HFP 1.6 WideBand Speech. Upon connection failure, try T1 settings. When CVSD is requested and eSCO is supported, try to establish eSCO connection using S3 settings. If it fails, fallback in sequence to S2, S1, D1, D0 settings. To know which setting should be used, conn->attempt is used. It indicates the currently ongoing SCO connection attempt and can be used as the index for the fallback settings table. These setting and the fallback order are described in Bluetooth HFP 1.6 specification p. 101. Signed-off-by: Frédéric Dalleau <frederic.dalleau@linux.intel.com> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
* Bluetooth: Parameters for outgoing SCO connectionsFrédéric Dalleau2013-08-211-5/+19
| | | | | | | | | | | | | In order to establish a transparent SCO connection, the correct settings must be specified in the Setup Synchronous Connection request. For that, a setting field is added to ACL connection data to set up the desired parameters. The patch also removes usage of hdev->voice_setting in CVSD connection and makes use of T2 parameters for transparent data. Signed-off-by: Frédéric Dalleau <frederic.dalleau@linux.intel.com> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
* Bluetooth: Use hci_connect_sco directlyFrédéric Dalleau2013-08-211-6/+2
| | | | | | | | | | | | hci_connect is a super function for connecting hci protocols. But the voice_setting parameter (introduced in subsequent patches) is only needed by SCO and security requirements are not needed for SCO channels. Thus, it makes sense to have a separate function for SCO. Signed-off-by: Frédéric Dalleau <frederic.dalleau@linux.intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
* Bluetooth: introduce hci_conn ref-countingDavid Herrmann2013-04-171-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We currently do not allow using hci_conn from outside of HCI-core. However, several other users could make great use of it. This includes HIDP, rfcomm and all other sub-protocols that rely on an active connection. Hence, we now introduce hci_conn ref-counting. We currently never call get_device(). put_device() is exclusively used in hci_conn_del_sysfs(). Hence, we currently never have a greater device-refcnt than 1. Therefore, it is safe to move the put_device() call from hci_conn_del_sysfs() to hci_conn_del() (it's the only caller). In fact, this even fixes a "use-after-free" bug as we access hci_conn after calling hci_conn_del_sysfs() in hci_conn_del(). From now on we can add references to hci_conn objects in other layers (like l2cap_sock, HIDP, rfcomm, ...) and grab a reference via hci_conn_get(). This does _not_ guarantee, that the connection is still alive. But, this isn't what we want. We can simply lock the hci_conn device and use "device_is_registered(hci_conn->dev)" to test that. However, this is hardly necessary as outside users should never rely on the HCI connection to be alive, anyway. Instead, they should solely rely on the device-object to be available. But if sub-devices want the hci_conn object as sysfs parent, they need to be notified when the connection drops. This will be introduced in later patches with l2cap_users. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
* Bluetooth: remove unneeded hci_conn_hold/put_device()David Herrmann2013-04-171-16/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | hci_conn_hold/put_device() is used to control when hci_conn->dev is no longer needed and can be deleted from the system. Lets first look how they are currently used throughout the code (excluding HIDP!). All code that uses hci_conn_hold_device() looks like this: ... hci_conn_hold_device(); hci_conn_add_sysfs(); ... On the other side, hci_conn_put_device() is exclusively used in hci_conn_del(). So, considering that hci_conn_del() must not be called twice (which would fail horribly), we know that hci_conn_put_device() is only called _once_ (which is in hci_conn_del()). On the other hand, hci_conn_add_sysfs() must not be called twice, either (it would call device_add twice, which breaks the device, see drivers/base/core.c). So we know that hci_conn_hold_device() is also called only once (it's only called directly before hci_conn_add_sysfs()). So hold and put are known to be called only once. That means we can safely remove them and directly call hci_conn_del_sysfs() in hci_conn_del(). But there is one issue left: HIDP also uses hci_conn_hold/put_device(). However, this case can be ignored and simply removed as it is totally broken. The issue is, the only thing HIDP delays with hci_conn_hold_device() is the removal of the hci_conn->dev from sysfs. But, the hci_conn device has no mechanism to get notified when its own parent (hci_dev) gets removed from sysfs. hci_dev_hold/put() does _not_ control when it is removed but only when the device object is created and destroyed. And hci_dev calls hci_conn_flush_*() when it removes itself from sysfs, which itself causes hci_conn_del() to be called, but it does _not_ cause hci_conn_del_sysfs() to be called, which is wrong. Hence, we fix it to call hci_conn_del_sysfs() in hci_conn_del(). This guarantees that a hci_conn object is removed from sysfs _before_ its parent hci_dev is removed. The changes to HIDP look scary, wrong and broken. However, if you look at the HIDP session management, you will notice they're already broken in the exact _same_ way (ever tried "unplugging" HIDP devices? Breaks _all_ the time). So this patch only makes HIDP look _scary_ and _obviously broken_. It does not break HIDP itself, it already is! See later patches in this series which fix HIDP to use proper session-management. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
generated by cgit v1.2.3 (git 2.25.1) at 2025-01-09 22:35:08 +0000