- 28 9月, 2012 5 次提交
-
-
由 Andrei Emeltchenko 提交于
Define physical link structures. Physical links are represented by hci_conn structure. For BR/EDR we use type ACL_LINK and for AMP we use AMP_LINK. Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Andrei Emeltchenko 提交于
When receiving A2MP Discover Response send A2MP Get Info Request for each AMP controller in the discovery list. Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Andrei Emeltchenko 提交于
When receiving A2MP Get AMP Assoc Request execute Read Local AMP Assoc HCI command to AMP controller. If the AMP Assoc data is larger than it can fit to HCI event only fragment is read. When all fragments are read send A2MP Get AMP Assoc Response. Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Andrei Emeltchenko 提交于
When receiving A2MP Get Info Request execute Read Local AMP Info HCI command to AMP controller with function to be executed upon receiving command complete event. Function will handle A2MP Get Info Response. Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Andrei Emeltchenko 提交于
Create amp_mgr_list global list which will be used by different hci devices to find amp_mgr. Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
- 19 9月, 2012 2 次提交
-
-
由 Johan Hedberg 提交于
For each kernel release where commands or events are added to the management interface, the revision field should be increment by one. The increment should only happen once per kernel release and not for every command/event that gets added. The revision value is for informational purposes only, but this simple policy would make any future debugging a lot simple. Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com> Cc: stable@vger.kernel.org Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Johan Hedberg 提交于
This patch adds support for Secure Simple Pairing with devices that have KeyboardOnly as their IO capability. Such devices will cause a passkey notification on our side and optionally also keypress notifications. Without this patch some keyboards cannot be paired using the mgmt interface. Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com> Cc: stable@vger.kernel.org Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
- 09 9月, 2012 4 次提交
-
-
由 Andrei Emeltchenko 提交于
Add Read Data Block Size HCI cmd to AMP initialization, then it makes possible to send data. Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Andrei Emeltchenko 提交于
Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Andrei Emeltchenko 提交于
Return code is not needed in hci_chan_del Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Andrei Emeltchenko 提交于
hdev is allocated with kzalloc so zero initialization is not needed. Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
- 27 8月, 2012 2 次提交
-
-
由 Vinicius Costa Gomes 提交于
In the case that the link is already in the connected state and a Pairing request arrives from the mgmt interface, hci_conn_security() would be called but it was not considering LE links. Reported-by: NJoão Paulo Rechi Vita <jprvita@openbossa.org> Signed-off-by: NVinicius Costa Gomes <vinicius.gomes@openbossa.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Vinicius Costa Gomes 提交于
To make it clear that it may be called from contexts that may not have any knowledge of L2CAP, we change the connection parameter, to receive a hci_conn. This also makes it clear that it is checking the security of the link. Signed-off-by: NVinicius Costa Gomes <vinicius.gomes@openbossa.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
- 22 8月, 2012 6 次提交
-
-
由 Vinicius Costa Gomes 提交于
Commit 4cd2d983 "Bluetooth: Simplify the connection type handling" broke the creation of ESCO links. This patch adds a type parameter to hci_connect_sco() so it creates the connection of the right kind. Signed-off-by: NVinicius Costa Gomes <vinicius.gomes@openbossa.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Syam Sidhardhan 提交于
This patch changes the struct l2cap_chan and associated code to use kref api for object refcounting and freeing. Suggested-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: NJaganath Kanakkassery <jaganath.k@samsung.com> Signed-off-by: NSyam Sidhardhan <s.syam@samsung.com> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Syam Sidhardhan 提交于
Earlier we were printing chan->psm before assigning any value. Signed-off-by: NSyam Sidhardhan <s.syam@samsung.com> Acked-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Mikel Astiz 提交于
MGMT_EV_DEVICE_DISCONNECTED will now expose the disconnection reason to userland, distinguishing four possible values: 0x00 Reason not known or unspecified 0x01 Connection timeout 0x02 Connection terminated by local host 0x03 Connection terminated by remote host Note that the local/remote distinction just determines which side terminated the low-level connection, regardless of the disconnection of the higher-level profiles. This can sometimes be misleading and thus must be used with care. For example, some hardware combinations would report a locally initiated disconnection even if the user turned Bluetooth off in the remote side. Signed-off-by: NMikel Astiz <mikel.astiz@bmw-carit.de> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Mikel Astiz 提交于
Replace the status checks with the short form of the boolean expression. Signed-off-by: NMikel Astiz <mikel.astiz@bmw-carit.de> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Andrei Emeltchenko 提交于
Use standard bluetooth way to check NULL pointer !var instead of var == NULL. Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
- 15 8月, 2012 9 次提交
-
-
由 Andrei Emeltchenko 提交于
Make code more clear by moving sk and bt vars to the place where they are actually used. Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Andre Guedes 提交于
If SMP fails, we should always cancel security_timer delayed work. Otherwise, security_timer function may run after l2cap_conn object has been freed. This patch fixes the following warning reported by ODEBUG: WARNING: at lib/debugobjects.c:261 debug_print_object+0x7c/0x8d() Hardware name: Bochs ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x27 Modules linked in: btusb bluetooth Pid: 440, comm: kworker/u:2 Not tainted 3.5.0-rc1+ #4 Call Trace: [<ffffffff81174600>] ? free_obj_work+0x4a/0x7f [<ffffffff81023eb8>] warn_slowpath_common+0x7e/0x97 [<ffffffff81023f65>] warn_slowpath_fmt+0x41/0x43 [<ffffffff811746b1>] debug_print_object+0x7c/0x8d [<ffffffff810394f0>] ? __queue_work+0x241/0x241 [<ffffffff81174fdd>] debug_check_no_obj_freed+0x92/0x159 [<ffffffff810ac08e>] slab_free_hook+0x6f/0x77 [<ffffffffa0019145>] ? l2cap_conn_del+0x148/0x157 [bluetooth] [<ffffffff810ae408>] kfree+0x59/0xac [<ffffffffa0019145>] l2cap_conn_del+0x148/0x157 [bluetooth] [<ffffffffa001b9a2>] l2cap_recv_frame+0xa77/0xfa4 [bluetooth] [<ffffffff810592f9>] ? trace_hardirqs_on_caller+0x112/0x1ad [<ffffffffa001c86c>] l2cap_recv_acldata+0xe2/0x264 [bluetooth] [<ffffffffa0002b2f>] hci_rx_work+0x235/0x33c [bluetooth] [<ffffffff81038dc3>] ? process_one_work+0x126/0x2fe [<ffffffff81038e22>] process_one_work+0x185/0x2fe [<ffffffff81038dc3>] ? process_one_work+0x126/0x2fe [<ffffffff81059f2e>] ? lock_acquired+0x1b5/0x1cf [<ffffffffa00028fa>] ? le_scan_work+0x11d/0x11d [bluetooth] [<ffffffff81036fb6>] ? spin_lock_irq+0x9/0xb [<ffffffff81039209>] worker_thread+0xcf/0x175 [<ffffffff8103913a>] ? rescuer_thread+0x175/0x175 [<ffffffff8103cfe0>] kthread+0x95/0x9d [<ffffffff812c5054>] kernel_threadi_helper+0x4/0x10 [<ffffffff812c36b0>] ? retint_restore_args+0x13/0x13 [<ffffffff8103cf4b>] ? flush_kthread_worker+0xdb/0xdb [<ffffffff812c5050>] ? gs_change+0x13/0x13 This bug can be reproduced using hctool lecc or l2test tools and bluetoothd not running. Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Vinicius Costa Gomes 提交于
Now that we have a "connect" function for each link type, we should be able to indentify which function is going to be called. Signed-off-by: NVinicius Costa Gomes <vinicius.gomes@openbossa.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Vinicius Costa Gomes 提交于
Now that we have separate ways of doing connections for each link type, we can do better than an "if" statement to handle each link type. Signed-off-by: NVinicius Costa Gomes <vinicius.gomes@openbossa.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Vinicius Costa Gomes 提交于
We can do the same that we did for the other link types, for SCO connections. The only thing that's worth noting is that as SCO links need an ACL link, this functions uses the function that adds an ACL link. Signed-off-by: NVinicius Costa Gomes <vinicius.gomes@openbossa.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Vinicius Costa Gomes 提交于
The hci_connect() function was starting to get too complicated to be quickly understood. We can separate the creation of a new ACL connection into its own function. Signed-off-by: NVinicius Costa Gomes <vinicius.gomes@openbossa.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Vinicius Costa Gomes 提交于
The code that handles LE connection is already quite separated from the rest of the connection procedure, so we can easily put it into its own. Signed-off-by: NVinicius Costa Gomes <vinicius.gomes@openbossa.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Vinicius Costa Gomes 提交于
These names were causing much confusion, so we rename these functions that send HCI commands to be more similar in naming to the actual HCI commands that will be sent. Signed-off-by: NVinicius Costa Gomes <vinicius.gomes@openbossa.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Vinicius Costa Gomes 提交于
Some connection related functions are only used inside hci_conn.c so no need to have them exported. Signed-off-by: NVinicius Costa Gomes <vinicius.gomes@openbossa.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
- 07 8月, 2012 12 次提交
-
-
由 Jaganath Kanakkassery 提交于
If l2cap_chan_create() fails then it will return from l2cap_sock_kill since zapped flag of sk is reset. Signed-off-by: NJaganath Kanakkassery <jaganath.k@samsung.com> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Andrei Emeltchenko 提交于
smp_chan_create might return NULL so we need to check before dereferencing smp. Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Ram Malovany 提交于
When the name of the given entry is empty , the state needs to be updated accordingly. Cc: stable@vger.kernel.org Signed-off-by: NRam Malovany <ramm@ti.com> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Ram Malovany 提交于
If the device was not found in a list of found devices names of which are pending.This may happen in a case when HCI Remote Name Request was sent as a part of incoming connection establishment procedure. Hence there is no need to continue resolving a next name as it will be done upon receiving another Remote Name Request Complete Event. This will fix a kernel crash when trying to use this entry to resolve the next name. Cc: stable@vger.kernel.org Signed-off-by: NRam Malovany <ramm@ti.com> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Ram Malovany 提交于
If entry wasn't found in the hci_inquiry_cache_lookup_resolve do not resolve the name.This will fix a kernel crash when trying to use NULL pointer. Cc: stable@vger.kernel.org Signed-off-by: NRam Malovany <ramm@ti.com> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Szymon Janc 提交于
Some devices e.g. some Android based phones don't do SDP search before pairing and cancel legacy pairing when ACL is disconnected. PIN Code Request event which changes ACL timeout to HCI_PAIRING_TIMEOUT is only received after remote user entered PIN. In that case no L2CAP is connected so default HCI_DISCONN_TIMEOUT (2 seconds) is being used to timeout ACL connection. This results in problems with legacy pairing as remote user has only few seconds to enter PIN before ACL is disconnected. Increase disconnect timeout for incomming connection to HCI_PAIRING_TIMEOUT if SSP is disabled and no linkey exists. To avoid keeping ACL alive for too long after SDP search set ACL timeout back to HCI_DISCONN_TIMEOUT when L2CAP is connected. 2012-07-19 13:24:43.413521 < HCI Command: Create Connection (0x01|0x0005) plen 13 bdaddr 00:02:72:D6:6A:3F ptype 0xcc18 rswitch 0x01 clkoffset 0x0000 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 2012-07-19 13:24:43.425224 > HCI Event: Command Status (0x0f) plen 4 Create Connection (0x01|0x0005) status 0x00 ncmd 1 2012-07-19 13:24:43.885222 > HCI Event: Role Change (0x12) plen 8 status 0x00 bdaddr 00:02:72:D6:6A:3F role 0x01 Role: Slave 2012-07-19 13:24:44.054221 > HCI Event: Connect Complete (0x03) plen 11 status 0x00 handle 42 bdaddr 00:02:72:D6:6A:3F type ACL encrypt 0x00 2012-07-19 13:24:44.054313 < HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2 handle 42 2012-07-19 13:24:44.055176 > HCI Event: Page Scan Repetition Mode Change (0x20) plen 7 bdaddr 00:02:72:D6:6A:3F mode 0 2012-07-19 13:24:44.056217 > HCI Event: Max Slots Change (0x1b) plen 3 handle 42 slots 5 2012-07-19 13:24:44.059218 > HCI Event: Command Status (0x0f) plen 4 Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 0 2012-07-19 13:24:44.062192 > HCI Event: Command Status (0x0f) plen 4 Unknown (0x00|0x0000) status 0x00 ncmd 1 2012-07-19 13:24:44.067219 > HCI Event: Read Remote Supported Features (0x0b) plen 11 status 0x00 handle 42 Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87 2012-07-19 13:24:44.067248 < HCI Command: Read Remote Extended Features (0x01|0x001c) plen 3 handle 42 page 1 2012-07-19 13:24:44.071217 > HCI Event: Command Status (0x0f) plen 4 Read Remote Extended Features (0x01|0x001c) status 0x00 ncmd 1 2012-07-19 13:24:44.076218 > HCI Event: Read Remote Extended Features (0x23) plen 13 status 0x00 handle 42 page 1 max 1 Features: 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 2012-07-19 13:24:44.076249 < HCI Command: Remote Name Request (0x01|0x0019) plen 10 bdaddr 00:02:72:D6:6A:3F mode 2 clkoffset 0x0000 2012-07-19 13:24:44.081218 > HCI Event: Command Status (0x0f) plen 4 Remote Name Request (0x01|0x0019) status 0x00 ncmd 1 2012-07-19 13:24:44.105214 > HCI Event: Remote Name Req Complete (0x07) plen 255 status 0x00 bdaddr 00:02:72:D6:6A:3F name 'uw000951-0' 2012-07-19 13:24:44.105284 < HCI Command: Authentication Requested (0x01|0x0011) plen 2 handle 42 2012-07-19 13:24:44.111207 > HCI Event: Command Status (0x0f) plen 4 Authentication Requested (0x01|0x0011) status 0x00 ncmd 1 2012-07-19 13:24:44.112220 > HCI Event: Link Key Request (0x17) plen 6 bdaddr 00:02:72:D6:6A:3F 2012-07-19 13:24:44.112249 < HCI Command: Link Key Request Negative Reply (0x01|0x000c) plen 6 bdaddr 00:02:72:D6:6A:3F 2012-07-19 13:24:44.115215 > HCI Event: Command Complete (0x0e) plen 10 Link Key Request Negative Reply (0x01|0x000c) ncmd 1 status 0x00 bdaddr 00:02:72:D6:6A:3F 2012-07-19 13:24:44.116215 > HCI Event: PIN Code Request (0x16) plen 6 bdaddr 00:02:72:D6:6A:3F 2012-07-19 13:24:48.099184 > HCI Event: Auth Complete (0x06) plen 3 status 0x13 handle 42 Error: Remote User Terminated Connection 2012-07-19 13:24:48.179182 > HCI Event: Disconn Complete (0x05) plen 4 status 0x00 handle 42 reason 0x13 Reason: Remote User Terminated Connection Cc: stable@vger.kernel.org Signed-off-by: NSzymon Janc <szymon.janc@tieto.com> Acked-by: NJohan Hedberg <johan.hedberg@intel.com> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Gustavo Padovan 提交于
sco_chan_del() only has conn != NULL when called from sco_conn_del() so just move the code from it that deal with conn to sco_conn_del(). [ 120.765529] [ 120.765529] ====================================================== [ 120.766529] [ INFO: possible circular locking dependency detected ] [ 120.766529] 3.5.0-rc1-10292-g3701f944-dirty #70 Tainted: G W [ 120.766529] ------------------------------------------------------- [ 120.766529] kworker/u:3/1497 is trying to acquire lock: [ 120.766529] (&(&conn->lock)->rlock#2){+.+...}, at: [<ffffffffa00b7ecc>] sco_chan_del+0x4c/0x170 [bluetooth] [ 120.766529] [ 120.766529] but task is already holding lock: [ 120.766529] (slock-AF_BLUETOOTH-BTPROTO_SCO){+.+...}, at: [<ffffffffa00b8401>] sco_conn_del+0x61/0xe0 [bluetooth] [ 120.766529] [ 120.766529] which lock already depends on the new lock. [ 120.766529] [ 120.766529] [ 120.766529] the existing dependency chain (in reverse order) is: [ 120.766529] [ 120.766529] -> #1 (slock-AF_BLUETOOTH-BTPROTO_SCO){+.+...}: [ 120.766529] [<ffffffff8107980e>] lock_acquire+0x8e/0xb0 [ 120.766529] [<ffffffff813c19e0>] _raw_spin_lock+0x40/0x80 [ 120.766529] [<ffffffffa00b85e9>] sco_connect_cfm+0x79/0x300 [bluetooth] [ 120.766529] [<ffffffffa0094b13>] hci_sync_conn_complete_evt.isra.90+0x343/0x400 [bluetooth] [ 120.766529] [<ffffffffa009d447>] hci_event_packet+0x317/0xfb0 [bluetooth] [ 120.766529] [<ffffffffa008aa68>] hci_rx_work+0x2c8/0x890 [bluetooth] [ 120.766529] [<ffffffff81047db7>] process_one_work+0x197/0x460 [ 120.766529] [<ffffffff810489d6>] worker_thread+0x126/0x2d0 [ 120.766529] [<ffffffff8104ee4d>] kthread+0x9d/0xb0 [ 120.766529] [<ffffffff813c4294>] kernel_thread_helper+0x4/0x10 [ 120.766529] [ 120.766529] -> #0 (&(&conn->lock)->rlock#2){+.+...}: [ 120.766529] [<ffffffff81078a8a>] __lock_acquire+0x154a/0x1d30 [ 120.766529] [<ffffffff8107980e>] lock_acquire+0x8e/0xb0 [ 120.766529] [<ffffffff813c19e0>] _raw_spin_lock+0x40/0x80 [ 120.766529] [<ffffffffa00b7ecc>] sco_chan_del+0x4c/0x170 [bluetooth] [ 120.766529] [<ffffffffa00b8414>] sco_conn_del+0x74/0xe0 [bluetooth] [ 120.766529] [<ffffffffa00b88a2>] sco_disconn_cfm+0x32/0x60 [bluetooth] [ 120.766529] [<ffffffffa0093a82>] hci_disconn_complete_evt.isra.53+0x242/0x390 [bluetooth] [ 120.766529] [<ffffffffa009d747>] hci_event_packet+0x617/0xfb0 [bluetooth] [ 120.766529] [<ffffffffa008aa68>] hci_rx_work+0x2c8/0x890 [bluetooth] [ 120.766529] [<ffffffff81047db7>] process_one_work+0x197/0x460 [ 120.766529] [<ffffffff810489d6>] worker_thread+0x126/0x2d0 [ 120.766529] [<ffffffff8104ee4d>] kthread+0x9d/0xb0 [ 120.766529] [<ffffffff813c4294>] kernel_thread_helper+0x4/0x10 [ 120.766529] [ 120.766529] other info that might help us debug this: [ 120.766529] [ 120.766529] Possible unsafe locking scenario: [ 120.766529] [ 120.766529] CPU0 CPU1 [ 120.766529] ---- ---- [ 120.766529] lock(slock-AF_BLUETOOTH-BTPROTO_SCO); [ 120.766529] lock(&(&conn->lock)->rlock#2); [ 120.766529] lock(slock-AF_BLUETOOTH-BTPROTO_SCO); [ 120.766529] lock(&(&conn->lock)->rlock#2); [ 120.766529] [ 120.766529] *** DEADLOCK *** Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Andre Guedes 提交于
This patch moves the hci_conn check to begining of hci_le_conn_ complete_evt in order to improve code's readability and better error handling. Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Andre Guedes 提交于
This patch does a trivial code refactoring in hci_conn lookup in hci_le_conn_complete_evt. It performs the hci_conn lookup at the begining of the function since it is used by both flows (error and success). Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Andre Guedes 提交于
This patch changes hci_cs_le_create_conn to perform hci_conn lookup by state instead of bdaddr. Since we can have only one LE connection in BT_CONNECT state, we can perform LE hci_conn lookup by state. This way, we don't rely on hci_sent_cmd_data helper to find the hci_conn object. Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Andre Guedes 提交于
This patch does some code refactoring in hci_cs_le_create_conn function. The hci_conn object is only needed in case of failure, therefore hdev locking and hci_conn lookup were moved to if-statement scope. Also, the conn->state check was removed since we should always close the connection if it fails. Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Andre Guedes 提交于
This patch removes some unneeded code from hci_cs_le_create_conn. If the hci_conn is not found, it means this LE connection attempt was triggered by a thrid-party tool (e.g. hcitool). We should not create this new hci_conn in LE Create Connection command status event since it is already properly handled in LE Connection Complete event. Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-