aboutsummaryrefslogtreecommitdiffstats
path: root/net/bluetooth
Commit message (Collapse)AuthorAge
* Bluetooth: Fix potential NULL dereferenceJohan Hedberg2015-02-03
| | | | | | | | | | | The bnep_get_device function may be triggered by an ioctl just after a connection has gone down. In such a case the respective L2CAP chan->conn pointer will get set to NULL (by l2cap_chan_del). This patch adds a missing NULL check for this case in the bnep_get_device() function. Reported-by: Patrik Flykt <patrik.flykt@linux.intel.com> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Remove mgmt_rp_read_local_oob_ext_data structJohan Hedberg2015-02-02
| | | | | | | | | | This extended return parameters struct conflicts with the new Read Local OOB Extended Data command definition. To avoid the conflict simply rename the old "extended" version to the normal one and update the code appropriately to take into account the two possible response PDU sizes. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Add restarting to service discoveryJakub Pawlowski2015-02-02
| | | | | | | | | | | | | When using LE_SCAN_FILTER_DUP_ENABLE, some controllers would send advertising report from each LE device only once. That means that we don't get any updates on RSSI value, and makes Service Discovery very slow. This patch adds restarting scan when in Service Discovery, and device with filtered uuid is found, but it's not in RSSI range to send event yet. This way if device moves into range, we will quickly get RSSI update. Signed-off-by: Jakub Pawlowski <jpawlowski@google.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Add le_scan_restart work for LE scan restartingJakub Pawlowski2015-02-02
| | | | | | | | | | | | | Currently there is no way to restart le scan, and it's needed in service scan method. The way it work: it disable, and then enable le scan on controller. During the restart, we must remember when the scan was started, and it's duration, to later re-schedule the le_scan_disable work, that was stopped during the stop scan phase. Signed-off-by: Jakub Pawlowski <jpawlowski@google.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Fix OOB data present for BR/EDR Secure Connections Only modeMarcel Holtmann2015-02-01
| | | | | | | | | | | | When using Secure Connections Only mode, then only P-256 OOB data is valid and should be provided. In case userspace provides P-192 and P-256 OOB data, then the P-192 values will be set to zero. However the present value of the IO capability exchange still mentioned that both values would be available. Fix this by telling the controller clearly that only the P-256 OOB data is present. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Expose remote OOB information as debugfs entryMarcel Holtmann2015-02-01
| | | | | | | | For debugging purposes it is good to know which OOB data is actually currently loaded for each controller. So expose that list via debugfs. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Expose hardware error code as debugfs entryMarcel Holtmann2015-02-01
| | | | | | | | | When the Hardware Error event is send by the controller, the Bluetooth core stores the error code. Expose it via debugfs so it can be retrieved later on. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Expose debug keys usage setting via debugfsMarcel Holtmann2015-02-01
| | | | | | | | To allow easier debugging when debug keys are generated, provide debugfs entry for checking the setting of debug keys usage. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Track changes from HCI Write Simple Pairing Debug Mode commandMarcel Holtmann2015-02-01
| | | | | | | | | | When the HCI Write Simple Pairing Debug Mode command has been issued, the result needs to be tracked and stored. The hdev->ssp_debug_mode variable is already present, but was never updated when the mode in the controller was actually changed. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Expose Secure Simple Pairing debug mode setting in debugfsMarcel Holtmann2015-02-01
| | | | | | | | The value of the ssp_debug_mode should be accessible via debugfs to be able to determine if a BR/EDR controller generates debugs keys or not. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Allow remote OOB data to only provide P-192 or P-256 valuesMarcel Holtmann2015-01-31
| | | | | | | | | | In case the remote only provided P-192 or P-256 data for OOB pairing, then make sure that the data value pointers are correctly set. That way the core can provide correct information when remote OOB data present information have to be communicated. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Fix OOB data present value for SMP pairingMarcel Holtmann2015-01-31
| | | | | | | | | | Before setting the OOB data present flag with SMP pairing, check the newly introduced present tracking that actual OOB data values have been provided. The existence of remote OOB data structure does not actually mean that the correct data values are available. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Fix OOB data present value for BR/EDR Secure ConnectionsMarcel Holtmann2015-01-31
| | | | | | | | | | | | | | When BR/EDR Secure Connections has been enabled, the OOB data present value can take 2 additional values. The host has to clearly provide details about if P-192 OOB data, P-256 OOB data or a combination of P-192 and P-256 OOB data is present. In case BR/EDR Secure Connections is not enabled or not supported, then check that P-192 OOB data is actually present and return the correct value based on that. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Store OOB data present value for each set of remote OOB dataMarcel Holtmann2015-01-31
| | | | | | | | | Instead of doing complex calculation every time the OOB data is used, just calculate the OOB data present value and store it with the OOB data raw values. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Fix sending Read Remote Extended Features commandSzymon Janc2015-01-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This command should only be used if remote device reports that it supports extended features. Otherwise command will fail and connection will be dropped. Some devices support SSP but don't support extended features so current check for SSP support is not enought. Instead of checking for SSP support just check if both ends support Extended Feature. < HCI Command: Create Connection (0x01|0x0005) plen 13 Address: D0:9C:30:00:19:6F (Foster Electric Company, Limited) Packet type: 0xcc18 DM1 may be used DH1 may be used DM3 may be used DH3 may be used DM5 may be used DH5 may be used Page scan repetition mode: R1 (0x01) Page scan mode: Mandatory (0x00) Clock offset: 0x94c8 Role switch: Allow slave (0x01) > HCI Event: Command Status (0x0f) plen 4 Create Connection (0x01|0x0005) ncmd 1 Status: Success (0x00) > HCI Event: Connect Complete (0x03) plen 11 Status: Success (0x00) Handle: 5 Address: D0:9C:30:00:19:6F (Foster Electric Company, Limited) Link type: ACL (0x01) Encryption: Disabled (0x00) < HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2 Handle: 5 > HCI Event: Command Status (0x0f) plen 4 Read Remote Supported Features (0x01|0x001b) ncmd 1 Status: Success (0x00) > HCI Event: Page Scan Repetition Mode Change (0x20) plen 7 Address: D0:9C:30:00:19:6F (Foster Electric Company, Limited) Page scan repetition mode: R1 (0x01) > HCI Event: Read Remote Supported Features (0x0b) plen 11 Status: Success (0x00) Handle: 5 Features: 0xff 0xff 0x8f 0xfe 0xdb 0xff 0x5b 0x07 3 slot packets 5 slot packets Encryption Slot offset Timing accuracy Role switch Hold mode Sniff mode Park state Power control requests Channel quality driven data rate (CQDDR) SCO link HV2 packets HV3 packets u-law log synchronous data A-law log synchronous data CVSD synchronous data Paging parameter negotiation Power control Transparent synchronous data Broadcast Encryption Enhanced Data Rate ACL 2 Mbps mode Enhanced Data Rate ACL 3 Mbps mode Enhanced inquiry scan Interlaced inquiry scan Interlaced page scan RSSI with inquiry results Extended SCO link (EV3 packets) EV4 packets EV5 packets AFH capable slave AFH classification slave LE Supported (Controller) 3-slot Enhanced Data Rate ACL packets 5-slot Enhanced Data Rate ACL packets Sniff subrating Pause encryption AFH capable master AFH classification master Enhanced Data Rate eSCO 2 Mbps mode Enhanced Data Rate eSCO 3 Mbps mode 3-slot Enhanced Data Rate eSCO packets Extended Inquiry Response Simultaneous LE and BR/EDR (Controller) Secure Simple Pairing Encapsulated PDU Non-flushable Packet Boundary Flag Link Supervision Timeout Changed Event Inquiry TX Power Level Enhanced Power Control < HCI Command: Read Remote Extended Features (0x01|0x001c) plen 3 Handle: 5 Page: 1 > HCI Event: Command Status (0x0f) plen 4 Read Remote Extended Features (0x01|0x001c) ncmd 1 Status: Command Disallowed (0x0c) < HCI Command: Read Clock Offset (0x01|0x001f) plen 2 Handle: 5 > HCI Event: Command Status (0x0f) plen 4 Read Clock Offset (0x01|0x001f) ncmd 1 Status: Success (0x00) < HCI Command: Disconnect (0x01|0x0006) plen 3 Handle: 5 Reason: Remote User Terminated Connection (0x13) Signed-off-by: Szymon Janc <szymon.janc@tieto.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Move smp_unregister() into hci_dev_do_close() functionMarcel Holtmann2015-01-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The smp_unregister() function needs to be called every time the controller is powered down. There are multiple entry points when this can happen. One is "hciconfig hci0 reset" which will throw a WARN_ON when LE support has been enabled. [ 78.564620] WARNING: CPU: 0 PID: 148 at net/bluetooth/smp.c:3075 smp_register+0xf1/0x170() [ 78.564622] Modules linked in: [ 78.564628] CPU: 0 PID: 148 Comm: kworker/u3:1 Not tainted 3.19.0-rc4-devel+ #404 [ 78.564629] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS [ 78.564635] Workqueue: hci0 hci_rx_work [ 78.564638] ffffffff81b4a7a2 ffff88001cb2fb38 ffffffff8161d881 0000000080000000 [ 78.564642] 0000000000000000 ffff88001cb2fb78 ffffffff8103b870 696e55206e6f6f6d [ 78.564645] ffff88001d965000 0000000000000000 0000000000000000 ffff88001d965000 [ 78.564648] Call Trace: [ 78.564655] [<ffffffff8161d881>] dump_stack+0x4f/0x7b [ 78.564662] [<ffffffff8103b870>] warn_slowpath_common+0x80/0xc0 [ 78.564667] [<ffffffff81544b00>] ? add_uuid+0x1f0/0x1f0 [ 78.564671] [<ffffffff8103b955>] warn_slowpath_null+0x15/0x20 [ 78.564674] [<ffffffff81562d81>] smp_register+0xf1/0x170 [ 78.564680] [<ffffffff81081236>] ? lock_timer_base.isra.30+0x26/0x50 [ 78.564683] [<ffffffff81544bf0>] powered_complete+0xf0/0x120 [ 78.564688] [<ffffffff8152e622>] hci_req_cmd_complete+0x82/0x260 [ 78.564692] [<ffffffff8153554f>] hci_cmd_complete_evt+0x6cf/0x2e20 [ 78.564697] [<ffffffff81623e43>] ? _raw_spin_unlock_irqrestore+0x13/0x30 [ 78.564701] [<ffffffff8106b0af>] ? __wake_up_sync_key+0x4f/0x60 [ 78.564705] [<ffffffff8153a2ab>] hci_event_packet+0xbcb/0x2e70 [ 78.564709] [<ffffffff814094d3>] ? skb_release_all+0x23/0x30 [ 78.564711] [<ffffffff81409529>] ? kfree_skb+0x29/0x40 [ 78.564715] [<ffffffff815296c8>] hci_rx_work+0x1c8/0x3f0 [ 78.564719] [<ffffffff8105bd91>] ? get_parent_ip+0x11/0x50 [ 78.564722] [<ffffffff8105be25>] ? preempt_count_add+0x55/0xb0 [ 78.564727] [<ffffffff8104f65f>] process_one_work+0x12f/0x360 [ 78.564731] [<ffffffff8104ff9b>] worker_thread+0x6b/0x4b0 [ 78.564735] [<ffffffff8104ff30>] ? cancel_delayed_work_sync+0x10/0x10 [ 78.564738] [<ffffffff810542fa>] kthread+0xea/0x100 [ 78.564742] [<ffffffff81620000>] ? __schedule+0x3e0/0x980 [ 78.564745] [<ffffffff81054210>] ? kthread_create_on_node+0x180/0x180 [ 78.564749] [<ffffffff816246ec>] ret_from_fork+0x7c/0xb0 [ 78.564752] [<ffffffff81054210>] ? kthread_create_on_node+0x180/0x180 [ 78.564755] ---[ end trace 8b0d943af76d3736 ]--- This warning is not critical and has only been placed in the code to actually catch this exact situation. To avoid triggering it move the smp_unregister() into hci_dev_do_close() which will now also take care of remove the SMP channel. It is safe to call this function since it only remove the channel if it has been previously registered. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Perform a power cycle when receiving hardware error eventMarcel Holtmann2015-01-28
| | | | | | | | | | | | | | | | When receiving a HCI Hardware Error event, the controller should be assumed to be non-functional until issuing a HCI Reset command. The Bluetooth hardware errors are vendor specific and so add a new hdev->hw_error callback that drivers can provide to run extra code to handle the hardware error. After completing the vendor specific error handling perform a full reset of the Bluetooth stack by closing and re-opening the transport. Based-on-patch-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Introduce hci_dev_do_reset helper functionMarcel Holtmann2015-01-28
| | | | | | | | | Split the hci_dev_reset ioctl handling into using hci_dev_do_reset helper function. Similar to what has been done with hci_dev_do_open and hci_dev_do_close. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Fix notifying discovery state when powering offJohan Hedberg2015-01-28
| | | | | | | | | | The discovery state should be set to stopped when the HCI device is powered off. This patch adds the appropriate call to the hci_discovery_set_state() function from hci_dev_do_close() which is responsible for the power-off procedure. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Fix notifying discovery state upon resetJohan Hedberg2015-01-28
| | | | | | | | | | | | When HCI_Reset is issued the discovery state is assumed to be stopped. The hci_cc_reset() handler was trying to set the state but it was doing it without using the hci_discovery_set_state() function. Because of this e.g. the mgmt Discovering event could go without being sent. This patch fixes the code to use the hci_discovery_set_state() function instead of just blindly setting the state value. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Fix check for SSP when enabling SCJohan Hedberg2015-01-28
| | | | | | | | | | | | | There's a check in set_secure_conn() that's supposed to ensure that SSP is enabled before we try to request the controller to enable SC (since SSP is a pre-requisite for it). However, this check only makes sense for controllers actually supporting BR/EDR SC. If we have a 4.0 controller we're only interested in the LE part of SC and should therefore not be requiring SSP to be enabled. This patch adds an additional condition to check for lmp_sc_capable(hdev) before requiring SSP to be enabled. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Check for P-256 OOB values in Secure Connections Only modeMarcel Holtmann2015-01-28
| | | | | | | | | If Secure Connections Only mode has been enabled, the it is important to check that OOB data for P-256 values is provided. In case it is not, then tell the remote side that no OOB data is present. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Use helper function to determine BR/EDR OOB data presentMarcel Holtmann2015-01-28
| | | | | | | | | | When replying to the IO capability request for Secure Simple Pairing and Secure Connections, the OOB data present fields needs to set. Instead of making the calculation inline, split this into a separate helper function. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Clear P-192 values for OOB when in Secure Connections Only modeMarcel Holtmann2015-01-28
| | | | | | | | | When Secure Connections Only mode has been enabled and remote OOB data is requested, then only provide P-256 hash and randomizer vaulues. The fields for P-192 hash and randomizer should be set to zero. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Enforce zero-valued hash/rand192 for LE OOBJohan Hedberg2015-01-28
| | | | | | | | | | | Until legacy SMP OOB pairing is implemented user space should be given a clear error when trying to use it. This patch adds a corresponding check to the Add Remote OOB Data handler function which returns "invalid parameters" if non-zero Rand192 or Hash192 parameters were given for an LE address. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Fix nested sleepsPeter Hurley2015-01-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | l2cap/rfcomm/sco_sock_accept() are wait loops which may acquire sleeping locks. Since both wait loops and sleeping locks use task_struct.state to sleep and wake, the nested sleeping locks destroy the wait loop state. Use the newly-minted wait_woken() and DEFINE_WAIT_FUNC() for the wait loop. DEFINE_WAIT_FUNC() allows an alternate wake function to be specified; in this case, the predefined scheduler function, woken_wake_function(). This wait construct ensures wakeups will not be missed without requiring the wait loop to set the task state before condition evaluation. How this works: CPU 0 | CPU 1 | | is <condition> set? | no set <condition> | | wake_up_interruptible | woken_wake_function | set WQ_FLAG_WOKEN | try_to_wake_up | | wait_woken | set TASK_INTERRUPTIBLE | WQ_FLAG_WOKEN? yes | set TASK_RUNNING | | - loop - | | is <condition> set? | yes - exit wait loop Fixes "do not call blocking ops when !TASK_RUNNING" warnings in l2cap_sock_accept(), rfcomm_sock_accept() and sco_sock_accept(). Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Convert Set SC to use HCI RequestJohan Hedberg2015-01-23
| | | | | | | | | | | | | This patch converts the Set Secure Connection HCI handling to use a HCI request instead of using a hard-coded callback in hci_event.c. This e.g. ensures that we don't clear the flags incorrectly if something goes wrong with the power up process (not related to a mgmt Set SC command). The code can also be simplified a bit since only one pending Set SC command is allowed, i.e. mgmt_pending_foreach usage is not needed. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Remove incorrect check for BDADDR_BREDR address typeJohan Hedberg2015-01-23
| | | | | | | | | The Add Remote OOB Data mgmt command should allow data to be passed for LE as well. This patch removes a left-over check for BDADDR_BREDR that should not be there anymore. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Check for valid bdaddr in add_remote_oob_dataJohan Hedberg2015-01-23
| | | | | | | | | Before doing any other verifications, the add_remote_oob_data function should first check that the given address is valid. This patch adds such a missing check to the beginning of the function. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Require SSP enabling before BR/EDR Secure ConnectionsMarcel Holtmann2015-01-22
| | | | | | | | | When BR/EDR is supported by a controller, then it is required to enable Secure Simple Pairing first before enabling the Secure Connections feature. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Limit BR/EDR switching for LE only with secure connectionsMarcel Holtmann2015-01-22
| | | | | | | | | | | | | | When a powered on dual-mode controller has been configured to operate as LE only with secure connections, then the BR/EDR side of things can not be switched back on. Do reconfigure the controller it first needs to be powered down. The secure connections feature is implemented in the BR/EDR controller while for LE it is implemented in the host. So explicitly forbid such a transaction to avoid inconsistent states. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Fix dependency for BR/EDR Secure Connections mode on SSPMarcel Holtmann2015-01-22
| | | | | | | | | | | | | | | The BR/EDR Secure Connections feature should only be enabled when the Secure Simple Pairing mode has been enabled first. However since secure connections is feature that is valid for BR/EDR and LE, this needs special handling. When enabling secure connections on a LE only configured controller, thent the BR/EDR side should not be enabled in the controller. This patches makes the BR/EDR Secure Connections feature depending on enabling Secure Simple Pairing mode first. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Fix reporting invalid RSSI for LE devicesSzymon Janc2015-01-22
| | | | | | | | | Start Discovery was reporting 0 RSSI for invalid RSSI only for BR/EDR devices. LE devices were reported with RSSI 127. Signed-off-by: Szymon Janc <szymon.janc@tieto.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Cc: stable@vger.kernel.org # 3.19+
* Bluetooth: Remove unused functionRickard Strandqvist2015-01-16
| | | | | | | | | | Remove the function hci_conn_change_link_key() that is not used anywhere. This was partially found by using a static code analysis program called cppcheck. Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Add paranoid check for existing LE and BR/EDR SMP channelsMarcel Holtmann2015-01-15
| | | | | | | | | When the SMP channels have been already registered, then print out a clear WARN_ON message that something went wrong. Also unregister the existing channels in this case before trying to register new ones. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Fix lookup of fixed channels by local bdaddrJohan Hedberg2015-01-15
| | | | | | | | | | The comparing of chan->src should always be done against the local identity address, represented by hcon->src and hcon->src_type. This patch modifies l2cap_global_fixed_chan() to take the full hci_conn so that we can easily compare against hcon->src and hcon->src_type. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Add helpers for src/dst bdaddr type conversionJohan Hedberg2015-01-15
| | | | | | | | | | | The current bdaddr_type() usage in l2cap_core.c is a bit funny in that it's always passed a hci_conn + a hci_conn member. Because of this only the hci_conn is really needed. Since the second parameter is always either hcon->src_type or hcon->dst type this patch adds two helper functions for each purpose: bdaddr_src_type() and bdaddr_dst_type(). Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Bind the SMP channel registration to management power stateMarcel Holtmann2015-01-15
| | | | | | | | | | | | | | | | | | | When the controller gets powered on via the management interface, then register the supported SMP channels. There is no point in registering these channels earlier since it is not know what identity address the controller is going to operate with. When powering down a controller unregister all SMP channels. This is required since a powered down controller is allowed to change its identity address. In addition the SMP channels are only available when the controller is powered via the management interface. When using legacy ioctl, then Bluetooth Low Energy is not supported and registering kernel side SMP integration may actually cause confusion. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Don't register any SMP channel if LE is not supportedMarcel Holtmann2015-01-15
| | | | | | | | When LE features are not supported, then do not bother registering any kind of SMP channel. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Fix LE SMP channel source address and source address typeMarcel Holtmann2015-01-15
| | | | | | | | | | | | | The source address and source address type of the LE SMP channel can either be the public address of the controller or the static random address configured by the host. Right now the public address is used for the LE SMP channel and obviously that is not correct if the controller operates with the configured static random address. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Fix issue with switching BR/EDR back on when disabledMarcel Holtmann2015-01-15
| | | | | | | | | | For dual-mode controllers it is possible to disable BR/EDR and operate as LE single mode controllers with a static random address. If that is the case, then refuse switching BR/EDR back on after the controller has been powered. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Show device address type for L2CAP debugfs entriesMarcel Holtmann2015-01-15
| | | | | | | | | The devices address types are BR/EDR Public, LE Public and LE Random and any of these three is valid for L2CAP connections. So show the correct type in the debugfs list. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: 6lowpan: Remove PSM setting codeJukka Rissanen2015-01-14
| | | | | | | | | | | Removing PSM setting debugfs interface as the IPSP has a well defined PSM value that should be used. The patch introduces enable flag that can be used to toggle 6lowpan on/off. Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Fix valid Identity Address checkJohan Hedberg2015-01-14
| | | | | | | | | | | | | | According to the Bluetooth core specification valid identity addresses are either Public Device Addresses or Static Random Addresses. IRKs received with any other type of address should be discarded since we cannot assume to know the permanent identity of the peer device. This patch fixes a missing check for the Identity Address when receiving the Identity Address Information SMP PDU. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Cc: stable@vger.kernel.org # 3.17+
* Bluetooth: Remove dead codeGowtham Anandha Babu2015-01-14
| | | | | | | | Variable 'controller' is assigned a value that is never used. Identified by cppcheck tool. Signed-off-by: Gowtham Anandha Babu <gowtham.ab@samsung.com> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Use %llu for printing duration details of selftestsMarcel Holtmann2015-01-14
| | | | | | | | The duration variable for the selftests is unsigned long long and with that use %llu instead of %lld when printing the results. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Move Delete Stored Link Key to 4th phase of initializationMarcel Holtmann2015-01-14
| | | | | | | | | This moves the execution of Delete Stored Link Key command to the hci_init4_req phase. No actual code has been changed. The command is just executed at a later stage of the initialization. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Process result of HCI Delete Stored Link Key commandMarcel Holtmann2015-01-12
| | | | | | | | When the HCI Delete Stored Link Key command completes, then update the value of current stored keys in hci_dev structure. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Read stored link key information when powering on controllerMarcel Holtmann2015-01-12
| | | | | | | | | | The information about max stored link keys and current stored link keys should be read at controller initialization. So issue HCI Read Stored Link Key command with BDADDR_ANY and read_all flag set to 0x01 to retrieve this information. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Handle command complete event for HCI Read Stored Link KeysMarcel Holtmann2015-01-12
| | | | | | | | | | When the HCI Read Stored Link Keys command completes it gives useful information of the current stored keys and maximum keys a controller can actually store. So process this event and store these information in hci_dev structure. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
generated by cgit v1.2.2 (git 2.25.0) at 2024-11-26 20:34:38 -0500