summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* bluetooth: 6lowpan: fix NOHZ: local_softirq_pendingAlexander Aring2015-10-271-1/+1
| | | | | | | | | | | | | | | | | | | Jukka reported about the following warning: "NOHZ: local_softirq_pending 08" I remember this warning and we had a similar issue when using workqueues and calling netif_rx. See commit 5ff3fec ("mac802154: fix NOHZ local_softirq_pending 08 warning"). This warning occurs when calling "netif_rx" inside the wrong context (non softirq context). The net core api offers "netif_rx_ni" to call netif_rx inside the correct softirq context. Reported-by: Jukka Rissanen <jukka.rissanen@linux.intel.com> Signed-off-by: Alexander Aring <alex.aring@gmail.com> Acked-by: Jukka Rissanen <jukka.rissanen@linux.intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Fix crash on fast disconnect of SCOKuba Pawlak2015-10-271-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix a crash that may happen when a connection is closed before it was fully established. Mapping conn->hcon was released by shutdown function, but it is still referenced in (not yet finished) connection established handling function. [ 4635.254073] BUG: unable to handle kernel NULL pointer dereference at 00000013 [ 4635.262058] IP: [<c11659f0>] memcmp+0xe/0x25 [ 4635.266835] *pdpt = 0000000024190001 *pde = 0000000000000000 [ 4635.273261] Oops: 0000 [#1] PREEMPT SMP [ 4635.277652] Modules linked in: evdev ecb vfat fat libcomposite usb2380 isofs zlib_inflate rfcomm(O) udc_core bnep(O) btusb(O) btbcm(O) btintel(O) bluetooth(O) cdc_acm arc4 uinput hid_mule [ 4635.321761] Pid: 363, comm: kworker/u:2H Tainted: G O 3.8.0-119.1-plk-adaptation-byt-ivi-brd #1 [ 4635.332642] EIP: 0060:[<c11659f0>] EFLAGS: 00010206 CPU: 0 [ 4635.338767] EIP is at memcmp+0xe/0x25 [ 4635.342852] EAX: e4720678 EBX: 00000000 ECX: 00000006 EDX: 00000013 [ 4635.349849] ESI: 00000000 EDI: fb85366c EBP: e40c7dc0 ESP: e40c7db4 [ 4635.356846] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 [ 4635.362873] CR0: 8005003b CR2: 00000013 CR3: 24191000 CR4: 001007f0 [ 4635.369869] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 [ 4635.376865] DR6: ffff0ff0 DR7: 00000400 [ 4635.381143] Process kworker/u:2H (pid: 363, ti=e40c6000 task=e40c5510 task.ti=e40c6000) [ 4635.390080] Stack: [ 4635.392319] e4720400 00000000 fb85366c e40c7df4 fb842285 e40c7de2 fb853200 00000013 [ 4635.401003] e3f101c4 e4720678 e3f101c0 e403be0a e40c7dfc e416a000 e403be0a fb85366c [ 4635.409692] e40c7e1c fb820186 020f6c00 e47c49ac e47c4008 00000000 e416a000 e47c402c [ 4635.418380] Call Trace: [ 4635.421153] [<fb842285>] sco_connect_cfm+0xff/0x236 [bluetooth] [ 4635.427893] [<fb820186>] hci_sync_conn_complete_evt.clone.101+0x227/0x268 [bluetooth] [ 4635.436758] [<fb82370f>] hci_event_packet+0x1caa/0x21d3 [bluetooth] [ 4635.443859] [<c106231f>] ? trace_hardirqs_on+0xb/0xd [ 4635.449502] [<c1375b8a>] ? _raw_spin_unlock_irqrestore+0x42/0x59 [ 4635.456340] [<fb814b67>] hci_rx_work+0xb9/0x350 [bluetooth] [ 4635.462663] [<c1039f1e>] ? process_one_work+0x17b/0x2e6 [ 4635.468596] [<c1039f77>] process_one_work+0x1d4/0x2e6 [ 4635.474333] [<c1039f1e>] ? process_one_work+0x17b/0x2e6 [ 4635.480294] [<fb814aae>] ? hci_cmd_work+0xda/0xda [bluetooth] [ 4635.486810] [<c103a3fa>] worker_thread+0x171/0x20f [ 4635.492257] [<c10456c5>] ? complete+0x34/0x3e [ 4635.497219] [<c103ea06>] kthread+0x90/0x95 [ 4635.501888] [<c103a289>] ? manage_workers+0x1df/0x1df [ 4635.507628] [<c1376537>] ret_from_kernel_thread+0x1b/0x28 [ 4635.513755] [<c103e976>] ? __init_kthread_worker+0x42/0x42 [ 4635.519975] Code: 74 0d 3c 79 74 04 3c 59 75 0c c6 02 01 eb 03 c6 02 00 31 c0 eb 05 b8 ea ff ff ff 5d c3 55 89 e5 57 56 53 31 db eb 0e 0f b6 34 18 <0f> b6 3c 1a 43 29 fe 75 07 49 85 c9 7f [ 4635.541264] EIP: [<c11659f0>] memcmp+0xe/0x25 SS:ESP 0068:e40c7db4 [ 4635.548166] CR2: 0000000000000013 [ 4635.552177] ---[ end trace e05ce9b8ce6182f6 ]--- Signed-off-by: Kuba Pawlak <kubax.t.pawlak@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Fix some obvious coding style issues in the SCO moduleMarcel Holtmann2015-10-261-11/+19
| | | | | | | | Lets fix this obvious coding style issues in the SCO module and bring it in line with the rest of the Bluetooth subsystem. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Replace hci_notify with hci_sock_dev_eventMarcel Holtmann2015-10-261-16/+9Star
| | | | | | | | There is no point in wrapping hci_sock_dev_event around hci_notify. It is an empty wrapper which adds no value. So remove it. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Rename bt_cb()->req into bt_cb()->hciMarcel Holtmann2015-10-265-24/+24
| | | | | | | | | | | | | | The SKB context buffer for HCI request is really not just for requests, information in their are preserved for the whole HCI layer. So it makes more sense to actually rename it into bt_cb()->hci and also call it then struct hci_ctrl. In addition that allows moving the decoded opcode for outgoing packets into that struct. So far it was just consuming valuable space from the main shared items. And opcode are not valid for L2CAP packets. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Remove unneeded parenthesis around MSG_OOBMarcel Holtmann2015-10-262-2/+2
| | | | | | | | There are two checks that are still using (MSG_OOB) instead of just MSG_OOB and so lets just fix them. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Fix locking issue during fast SCO reconnection.Kuba Pawlak2015-10-251-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When SCO connection is requested and disconnected fast, there is a change that sco_sock_shutdown is going to preempt thread started in sco_connect_cfm. When this happens struct sock sk may be removed but a pointer to it is still held in sco_conn_ready, where embedded spinlock is used. If it is used, but struct sock has been removed, it will crash. Block connection object, which will prevent struct sock from being removed and give connection process chance to finish. BUG: spinlock bad magic on CPU#0, kworker/u:2H/319 lock: 0xe3e99434, .magic: f3000000, .owner: (���/0, .owner_cpu: -203804160 Pid: 319, comm: kworker/u:2H Tainted: G O 3.8.0-115.1-plk-adaptation-byt-ivi-brd #1 Call Trace: [<c1155659>] ? do_raw_spin_lock+0x19/0xe9 [<fb75354f>] ? sco_connect_cfm+0x92/0x236 [bluetooth] [<fb731dbc>] ? hci_sync_conn_complete_evt.clone.101+0x18b/0x1cb [bluetooth] [<fb734ee7>] ? hci_event_packet+0x1acd/0x21a6 [bluetooth] [<c1041095>] ? finish_task_switch+0x50/0x89 [<c1349a2e>] ? __schedule+0x638/0x6b8 [<fb727918>] ? hci_rx_work+0xb9/0x2b8 [bluetooth] [<c103760a>] ? queue_delayed_work_on+0x21/0x2a [<c1035df9>] ? process_one_work+0x157/0x21b [<fb72785f>] ? hci_cmd_work+0xef/0xef [bluetooth] [<c1036217>] ? worker_thread+0x16e/0x20a [<c10360a9>] ? manage_workers+0x1cf/0x1cf [<c103a0ef>] ? kthread+0x8d/0x92 [<c134adf7>] ? ret_from_kernel_thread+0x1b/0x28 [<c103a062>] ? __init_kthread_worker+0x24/0x24 BUG: unable to handle kernel NULL pointer dereference at (null) IP: [< (null)>] (null) *pdpt = 00000000244e1001 *pde = 0000000000000000 Oops: 0010 [#1] PREEMPT SMP Modules linked in: evdev ecb rfcomm(O) libcomposite usb2380 udc_core bnep(O) btusb(O) btbcm(O) cdc_acm btintel(O) bluetooth(O) arc4 uinput hid_multitouch usbhid hid iwlmvm(O)e Pid: 319, comm: kworker/u:2H Tainted: G O 3.8.0-115.1-plk-adaptation-byt-ivi-brd #1 EIP: 0060:[<00000000>] EFLAGS: 00010246 CPU: 0 EIP is at 0x0 EAX: e3e99400 EBX: e3e99400 ECX: 00000100 EDX: 00000000 ESI: e3e99434 EDI: fb763ce0 EBP: e49b9e44 ESP: e49b9e14 DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 CR0: 8005003b CR2: 00000000 CR3: 24444000 CR4: 001007f0 DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 DR6: ffff0ff0 DR7: 00000400 Process kworker/u:2H (pid: 319, ti=e49b8000 task=e4ab9030 task.ti=e49b8000) Stack: fb75355b 00000246 fb763900 22222222 22222222 22222222 e3f94460 e3ca7c0a e49b9e4c e3f34c00 e3ca7c0a fb763ce0 e49b9e6c fb731dbc 02000246 e4cec85c e4cec008 00000000 e3f34c00 e4cec000 e3c2ce00 0000002c e49b9ed0 fb734ee7 Call Trace: [<fb75355b>] ? sco_connect_cfm+0x9e/0x236 [bluetooth] [<fb731dbc>] ? hci_sync_conn_complete_evt.clone.101+0x18b/0x1cb [bluetooth] [<fb734ee7>] ? hci_event_packet+0x1acd/0x21a6 [bluetooth] [<c1041095>] ? finish_task_switch+0x50/0x89 [<c1349a2e>] ? __schedule+0x638/0x6b8 [<fb727918>] ? hci_rx_work+0xb9/0x2b8 [bluetooth] [<c103760a>] ? queue_delayed_work_on+0x21/0x2a [<c1035df9>] ? process_one_work+0x157/0x21b [<fb72785f>] ? hci_cmd_work+0xef/0xef [bluetooth] [<c1036217>] ? worker_thread+0x16e/0x20a [<c10360a9>] ? manage_workers+0x1cf/0x1cf [<c103a0ef>] ? kthread+0x8d/0x92 [<c134adf7>] ? ret_from_kernel_thread+0x1b/0x28 [<c103a062>] ? __init_kthread_worker+0x24/0x24 Code: Bad EIP value. EIP: [<00000000>] 0x0 SS:ESP 0068:e49b9e14 CR2: 0000000000000000 ---[ end trace 942a6577c0abd725 ]--- Signed-off-by: Kuba Pawlak <kubax.t.pawlak@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Fix locking issue on SCO disconnectionKuba Pawlak2015-10-251-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Thread handling SCO disconnection may get preempted in '__sco_sock_close' after dropping a reference to hci_conn but before marking this as NULL in associated struct sco_conn. When execution returs to this thread, this connection will possibly be released, resulting in kernel crash Lock connection before this point. BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<fb770ab9>] __sco_sock_close+0x194/0x1ff [bluetooth] *pdpt = 0000000023da6001 *pde = 0000000000000000 Oops: 0002 [#1] PREEMPT SMP Modules linked in: evdev ecb rfcomm(O) libcomposite usb2380 udc_core bnep(O) btusb(O) btbcm(O) cdc_acm btintel(O) bluetooth(O) arc4 uinput hid_multitouch usbhid iwlmvm(O) hide Pid: 984, comm: bluetooth Tainted: G O 3.8.0-115.1-plk-adaptation-byt-ivi-brd #1 EIP: 0060:[<fb770ab9>] EFLAGS: 00010282 CPU: 2 EIP is at __sco_sock_close+0x194/0x1ff [bluetooth] EAX: 00000000 EBX: e49d7600 ECX: ef1ec3c2 EDX: 000000c3 ESI: e4c12000 EDI: 00000000 EBP: ef1edf5c ESP: ef1edf4c DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 CR0: 80050033 CR2: 00000000 CR3: 23da7000 CR4: 001007f0 DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 DR6: ffff0ff0 DR7: 00000400 Process bluetooth (pid: 984, ti=ef1ec000 task=e47f2550 task.ti=ef1ec000) Stack: e4c120d0 e49d7600 00000000 08421a40 ef1edf70 fb770b7a 00000002 e8a4cc80 08421a40 ef1ec000 c12966b1 00000001 00000000 0000000b 084954c8 c1296b6c 0000001b 00000002 0000001b 00000002 00000000 00000002 b2524880 00000046 Call Trace: [<fb770b7a>] ? sco_sock_shutdown+0x56/0x95 [bluetooth] [<c12966b1>] ? sys_shutdown+0x37/0x53 [<c1296b6c>] ? sys_socketcall+0x12e/0x1be [<c134ae7e>] ? sysenter_do_call+0x12/0x26 [<c1340000>] ? ip_vs_control_net_cleanup+0x46/0xb1 Code: e8 90 6b 8c c5 f6 05 72 5d 78 fb 04 74 17 8b 46 08 50 56 68 0a fd 77 fb 68 60 5d 78 fb e8 68 95 9e c5 83 c4 10 8b 83 fc 01 00 00 <c7> 00 00 00 00 00 eb 32 ba 68 00 00 0b EIP: [<fb770ab9>] __sco_sock_close+0x194/0x1ff [bluetooth] SS:ESP 0068:ef1edf4c CR2: 0000000000000000 ---[ end trace 47fa2f55a9544e69 ]--- Signed-off-by: Kuba Pawlak <kubax.t.pawlak@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Fix crash on SCO disconnectKuba Pawlak2015-10-251-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When disconnecting audio from the phone's side, it may happen, that a thread handling HCI message 'disconnection complete' will get preempted in 'sco_conn_del' before calling 'sco_sock_kill', still holding a pointer to struct sock sk. Interrupting thread started in 'sco_sock_shutdown' will carry on releasing resources and will eventually release struct sock. When execution goes back to first thread it will call sco_sock_kill using now invalid pointer to already destroyed socket. Fix is to grab a reference to the socket a release it after calling 'sco_sock_kill'. [ 166.358213] BUG: unable to handle kernel paging request at 7541203a [ 166.365228] IP: [<fb6e8bfb>] bt_sock_unlink+0x1a/0x38 [bluetooth] [ 166.372068] *pdpt = 0000000024b19001 *pde = 0000000000000000 [ 166.378483] Oops: 0002 [#1] PREEMPT SMP [ 166.382871] Modules linked in: evdev ecb rfcomm(O) libcomposite usb2380 udc_core bnep(O) btusb(O) btbcm(O) btintel(O) cdc_acm bluetooth(O) arc4 uinput hid_multitouch iwlmvm(O) usbhid hide [ 166.424233] Pid: 338, comm: kworker/u:2H Tainted: G O 3.8.0-115.1-plk-adaptation-byt-ivi-brd #1 [ 166.435112] EIP: 0060:[<fb6e8bfb>] EFLAGS: 00010206 CPU: 0 [ 166.441259] EIP is at bt_sock_unlink+0x1a/0x38 [bluetooth] [ 166.447382] EAX: 632e6563 EBX: e4bfc600 ECX: e466d4d3 EDX: 7541203a [ 166.454369] ESI: fb7278ac EDI: e4d52000 EBP: e4669e20 ESP: e4669e0c [ 166.461366] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 [ 166.467391] CR0: 8005003b CR2: 7541203a CR3: 24aba000 CR4: 001007f0 [ 166.474387] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 [ 166.481375] DR6: ffff0ff0 DR7: 00000400 [ 166.485654] Process kworker/u:2H (pid: 338, ti=e4668000 task=e466e030 task.ti=e4668000) [ 166.494591] Stack: [ 166.496830] e4bfc600 e4bfc600 fb715c28 e4717ee0 e4d52000 e4669e3c fb715cf3 e4bfc634 [ 166.505518] 00000068 e4d52000 e4c32000 fb7277c0 e4669e6c fb6f2019 0000004a 00000216 [ 166.514205] e4660101 e4c32008 02000001 00000013 e4d52000 e4c32000 e3dc9240 00000005 [ 166.522891] Call Trace: [ 166.525654] [<fb715c28>] ? sco_sock_kill+0x73/0x9a [bluetooth] [ 166.532295] [<fb715cf3>] ? sco_conn_del+0xa4/0xbf [bluetooth] [ 166.538836] [<fb6f2019>] ? hci_disconn_complete_evt.clone.55+0x1bd/0x205 [bluetooth] [ 166.547609] [<fb6f73d3>] ? hci_event_packet+0x297/0x223c [bluetooth] [ 166.554805] [<c10416da>] ? dequeue_task+0xaf/0xb7 [ 166.560154] [<c1041095>] ? finish_task_switch+0x50/0x89 [ 166.566086] [<c1349a2e>] ? __schedule+0x638/0x6b8 [ 166.571460] [<fb6eb906>] ? hci_rx_work+0xb9/0x2b8 [bluetooth] [ 166.577975] [<c1035df9>] ? process_one_work+0x157/0x21b [ 166.583933] [<fb6eb84d>] ? hci_cmd_work+0xef/0xef [bluetooth] [ 166.590448] [<c1036217>] ? worker_thread+0x16e/0x20a [ 166.596088] [<c10360a9>] ? manage_workers+0x1cf/0x1cf [ 166.601826] [<c103a0ef>] ? kthread+0x8d/0x92 [ 166.606691] [<c134adf7>] ? ret_from_kernel_thread+0x1b/0x28 [ 166.613010] [<c103a062>] ? __init_kthread_worker+0x24/0x24 [ 166.619230] Code: 85 63 ff ff ff 31 db 8d 65 f4 89 d8 5b 5e 5f 5d c3 56 8d 70 04 53 89 f0 89 d3 e8 7e 17 c6 c5 8b 53 28 85 d2 74 1a 8b 43 24 85 c0 <89> 02 74 03 89 50 04 c7 43 28 00 00 00 [ 166.640501] EIP: [<fb6e8bfb>] bt_sock_unlink+0x1a/0x38 [bluetooth] SS:ESP 0068:e4669e0c [ 166.649474] CR2: 000000007541203a [ 166.653420] ---[ end trace 0181ff2c9e42d51e ]--- [ 166.658609] note: kworker/u:2H[338] exited with preempt_count 1 Signed-off-by: Kuba Pawlak <kubax.t.pawlak@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: btmrvl: add missing of_node_putJulia Lawall2015-10-251-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | for_each_compatible_node performs an of_node_get on each iteration, so a break out of the loop requires an of_node_put. A simplified version of the semantic patch that fixes this problem is as follows (http://coccinelle.lip6.fr): // <smpl> @@ expression e; local idexpression n; @@ for_each_compatible_node(n, ...) { ... when != of_node_put(n) when != e = n ( return n; | + of_node_put(n); ? return ...; ) ... } // </smpl> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Increase minor version of core moduleMarcel Holtmann2015-10-221-1/+1
| | | | | | | | | | | With the addition of support for diagnostic feature, it makes sense to increase the minor version of the Bluetooth core module. The module version is not used anywhere, but it gives a nice extra hint for debugging purposes. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* ieee802154: 6lowpan: fix memory leakAlexander Aring2015-10-221-4/+9
| | | | | | | | | | | | | | | | | | | | | | | | Looking at current situation of memory management in 6lowpan receive function I detected some invalid handling. After calling lowpan_invoke_rx_handlers we will do a kfree_skb and then NET_RX_DROP on error handling. We don't do this before, also on skb_share_check/skb_unshare which might manipulate the reference counters. After running some 'grep -r "dev_add_pack" net/' to look how others packet-layer receive callbacks works I detected that every subsystem do a kfree_skb, then NET_RX_DROP without calling skb functions which might manipulate the skb reference counters. This is the reason why we should do the same here like all others subsystems. I didn't find any documentation how the packet-layer receive callbacks handle NET_RX_DROP return values either. This patch will add a kfree_skb, then NET_RX_DROP handling for the "trivial checks", in case of skb_share_check/skb_unshare the kfree_skb call will be done inside these functions. Signed-off-by: Alexander Aring <alex.aring@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Make hci_disconnect() behave correctly for all statesJohan Hedberg2015-10-221-8/+3Star
| | | | | | | | | | There are a few places that don't explicitly check the connection state before calling hci_disconnect(). To make this API do the right thing take advantage of the new hci_abort_conn() API and also make sure to only read the clock offset if we're really connected. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Take advantage of connection abort helpersJohan Hedberg2015-10-222-104/+11Star
| | | | | | | | | Convert the various places mapping connection state to disconnect/cancel HCI command to use the new hci_abort_conn helper API. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Introduce hci_req helper to abort a connectionJohan Hedberg2015-10-222-0/+97
| | | | | | | | | | There are several different places needing to make sure that a connection gets disconnected or canceled. The exact action needed depends on the connection state, so centralizing this logic can save quite a lot of code duplication. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: hci_bcm: checking for ERR_PTR instead of NULLDan Carpenter2015-10-221-2/+2
| | | | | | | bt_skb_alloc() returns NULL on error, it never returns an ERR_PTR. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Fix crash in SMP when unpairingJohan Hedberg2015-10-223-0/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When unpairing the keys stored in hci_dev are removed. If SMP is ongoing the SMP context will also have references to these keys, so removing them from the hci_dev lists will make the pointers invalid. This can result in the following type of crashes: BUG: unable to handle kernel paging request at 6b6b6b6b IP: [<c11f26be>] __list_del_entry+0x44/0x71 *pde = 00000000 Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC Modules linked in: hci_uart btqca btusb btintel btbcm btrtl hci_vhci rfcomm bluetooth_6lowpan bluetooth CPU: 0 PID: 723 Comm: kworker/u5:0 Not tainted 4.3.0-rc3+ #1379 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.8.1-20150318_183358- 04/01/2014 Workqueue: hci0 hci_rx_work [bluetooth] task: f19da940 ti: f1a94000 task.ti: f1a94000 EIP: 0060:[<c11f26be>] EFLAGS: 00010202 CPU: 0 EIP is at __list_del_entry+0x44/0x71 EAX: c0088d20 EBX: f30fcac0 ECX: 6b6b6b6b EDX: 6b6b6b6b ESI: f4b60000 EDI: c0088d20 EBP: f1a95d90 ESP: f1a95d8c DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 CR0: 8005003b CR2: 6b6b6b6b CR3: 319e5000 CR4: 00000690 Stack: f30fcac0 f1a95db0 f82dc3e1 f1bfc000 00000000 c106524f f1bfc000 f30fd020 f1a95dc0 f1a95dd0 f82dcbdb f1a95de0 f82dcbdb 00000067 f1bfc000 f30fd020 f1a95de0 f1a95df0 f82d1126 00000067 f82d1126 00000006 f30fd020 f1bfc000 Call Trace: [<f82dc3e1>] smp_chan_destroy+0x192/0x240 [bluetooth] [<c106524f>] ? trace_hardirqs_on_caller+0x14e/0x169 [<f82dcbdb>] smp_teardown_cb+0x47/0x64 [bluetooth] [<f82dcbdb>] ? smp_teardown_cb+0x47/0x64 [bluetooth] [<f82d1126>] l2cap_chan_del+0x5d/0x14d [bluetooth] [<f82d1126>] ? l2cap_chan_del+0x5d/0x14d [bluetooth] [<f82d40ef>] l2cap_conn_del+0x109/0x17b [bluetooth] [<f82d40ef>] ? l2cap_conn_del+0x109/0x17b [bluetooth] [<f82c0205>] ? hci_event_packet+0x5b1/0x2092 [bluetooth] [<f82d41aa>] l2cap_disconn_cfm+0x49/0x50 [bluetooth] [<f82d41aa>] ? l2cap_disconn_cfm+0x49/0x50 [bluetooth] [<f82c0228>] hci_event_packet+0x5d4/0x2092 [bluetooth] [<c1332c16>] ? skb_release_data+0x6a/0x95 [<f82ce5d4>] ? hci_send_to_monitor+0xe7/0xf4 [bluetooth] [<c1409708>] ? _raw_spin_unlock_irqrestore+0x44/0x57 [<f82b3bb0>] hci_rx_work+0xf1/0x28b [bluetooth] [<f82b3bb0>] ? hci_rx_work+0xf1/0x28b [bluetooth] [<c10635a0>] ? __lock_is_held+0x2e/0x44 [<c104772e>] process_one_work+0x232/0x432 [<c1071ddc>] ? rcu_read_lock_sched_held+0x50/0x5a [<c104772e>] ? process_one_work+0x232/0x432 [<c1047d48>] worker_thread+0x1b8/0x255 [<c1047b90>] ? rescuer_thread+0x23c/0x23c [<c104bb71>] kthread+0x91/0x96 [<c14096a7>] ? _raw_spin_unlock_irq+0x27/0x44 [<c1409d61>] ret_from_kernel_thread+0x21/0x30 [<c104bae0>] ? kthread_parkme+0x1e/0x1e To solve the issue, introduce a new smp_cancel_pairing() API that can be used to clean up the SMP state before touching the hci_dev lists. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Disable auto-connection parameters when unpairingJohan Hedberg2015-10-221-0/+10
| | | | | | | | | | For connection parameters that are left around until a disconnection we should at least clear any auto-connection properties. This way a new Add Device call is required to re-set them after calling Unpair Device. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Remove unnecessary hci_explicit_connect_lookup functionJohan Hedberg2015-10-213-22/+3Star
| | | | | | | | There's only one user of this helper which can be replaces with a call to hci_pend_le_action_lookup() and a check for params->explicit_connect. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Remove redundant (and possibly wrong) flag clearingJohan Hedberg2015-10-211-1/+0Star
| | | | | | | | | There's no need to clear the HCI_CONN_ENCRYPT_PEND flag in smp_failure. In fact, this may cause the encryption tracking to get out of sync as this has nothing to do with HCI activity. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Add hdev helper variable to hci_le_create_connection_cancelJohan Hedberg2015-10-211-6/+7
| | | | | | | | | The hci_le_create_connection_cancel() function needs to use the hdev pointer in many places so add a variable for it to avoid the need to dereference the hci_conn every time. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Remove unnecessary indentation in unpair_device()Johan Hedberg2015-10-211-23/+32
| | | | | | | | | Instead of doing all of the LE-specific handling in an else-branch in unpair_device() create a 'done' label for the BR/EDR branch to jump to and then remove the else-branch completely. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: 6lowpan: Use hci_conn_hash_lookup_le() when possibleJohan Hedberg2015-10-211-1/+1
| | | | | | | | | Use the new hci_conn_hash_lookup_le() API to look up LE connections. This way we're guaranteed exact matches that also take into account the address type. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Use hci_conn_hash_lookup_le() when possibleJohan Hedberg2015-10-213-11/+11
| | | | | | | | | Use the new hci_conn_hash_lookup_le() API to look up LE connections. This way we're guaranteed exact matches that also take into account the address type. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Add hci_conn_hash_lookup_le() helper functionJohan Hedberg2015-10-211-0/+24
| | | | | | | | | | | | | | Many of the existing LE connection lookups are forced to use hci_conn_hash_lookup_ba() which doesn't take into account the address type. What's worse, most of the users don't bother checking that the returned address type matches what was wanted. This patch adds a new helper API to look up LE connections based on their address and address type, paving the way to have the hci_conn_hash_lookup_ba() users converted to do more precise lookups. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Add le_addr_type() helper functionJohan Hedberg2015-10-211-38/+18Star
| | | | | | | | | The mgmt code needs to convert from mgmt/L2CAP address types to HCI in many places. Having a dedicated helper function for this simplifies code by shortening it and removing unnecessary 'addr_type' variables. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Fix missing hdev locking for LE scan cleanupJohan Hedberg2015-10-212-9/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The hci_conn objects don't have a dedicated lock themselves but rely on the caller to hold the hci_dev lock for most types of access. The hci_conn_timeout() function has so far sent certain HCI commands based on the hci_conn state which has been possible without holding the hci_dev lock. The recent changes to do LE scanning before connect attempts added even more operations to hci_conn and hci_dev from hci_conn_timeout, thereby exposing potential race conditions with the hci_dev and hci_conn states. As an example of such a race, here there's a timeout but an l2cap_sock_connect() call manages to race with the cleanup routine: [Oct21 08:14] l2cap_chan_timeout: chan ee4b12c0 state BT_CONNECT [ +0.000004] l2cap_chan_close: chan ee4b12c0 state BT_CONNECT [ +0.000002] l2cap_chan_del: chan ee4b12c0, conn f3141580, err 111, state BT_CONNECT [ +0.000002] l2cap_sock_teardown_cb: chan ee4b12c0 state BT_CONNECT [ +0.000005] l2cap_chan_put: chan ee4b12c0 orig refcnt 4 [ +0.000010] hci_conn_drop: hcon f53d56e0 orig refcnt 1 [ +0.000013] l2cap_chan_put: chan ee4b12c0 orig refcnt 3 [ +0.000063] hci_conn_timeout: hcon f53d56e0 state BT_CONNECT [ +0.000049] hci_conn_params_del: addr ee:0d:30:09:53:1f (type 1) [ +0.000002] hci_chan_list_flush: hcon f53d56e0 [ +0.000001] hci_chan_del: hci0 hcon f53d56e0 chan f4e7ccc0 [ +0.004528] l2cap_sock_create: sock e708fc00 [ +0.000023] l2cap_chan_create: chan ee4b1770 [ +0.000001] l2cap_chan_hold: chan ee4b1770 orig refcnt 1 [ +0.000002] l2cap_sock_init: sk ee4b3390 [ +0.000029] l2cap_sock_bind: sk ee4b3390 [ +0.000010] l2cap_sock_setsockopt: sk ee4b3390 [ +0.000037] l2cap_sock_connect: sk ee4b3390 [ +0.000002] l2cap_chan_connect: 00:02:72:d9:e5:8b -> ee:0d:30:09:53:1f (type 2) psm 0x00 [ +0.000002] hci_get_route: 00:02:72:d9:e5:8b -> ee:0d:30:09:53:1f [ +0.000001] hci_dev_hold: hci0 orig refcnt 8 [ +0.000003] hci_conn_hold: hcon f53d56e0 orig refcnt 0 Above the l2cap_chan_connect() shouldn't have been able to reach the hci_conn f53d56e0 anymore but since hci_conn_timeout didn't do proper locking that's not the case. The end result is a reference to hci_conn that's not in the conn_hash list, resulting in list corruption when trying to remove it later: [Oct21 08:15] l2cap_chan_timeout: chan ee4b1770 state BT_CONNECT [ +0.000004] l2cap_chan_close: chan ee4b1770 state BT_CONNECT [ +0.000003] l2cap_chan_del: chan ee4b1770, conn f3141580, err 111, state BT_CONNECT [ +0.000001] l2cap_sock_teardown_cb: chan ee4b1770 state BT_CONNECT [ +0.000005] l2cap_chan_put: chan ee4b1770 orig refcnt 4 [ +0.000002] hci_conn_drop: hcon f53d56e0 orig refcnt 1 [ +0.000015] l2cap_chan_put: chan ee4b1770 orig refcnt 3 [ +0.000038] hci_conn_timeout: hcon f53d56e0 state BT_CONNECT [ +0.000003] hci_chan_list_flush: hcon f53d56e0 [ +0.000002] hci_conn_hash_del: hci0 hcon f53d56e0 [ +0.000001] ------------[ cut here ]------------ [ +0.000461] WARNING: CPU: 0 PID: 1782 at lib/list_debug.c:56 __list_del_entry+0x3f/0x71() [ +0.000839] list_del corruption, f53d56e0->prev is LIST_POISON2 (00000200) The necessary fix is unfortunately more complicated than just adding hci_dev_lock/unlock calls to the hci_conn_timeout() call path. Particularly, the hci_conn_del() API, which expects the hci_dev lock to be held, performs a cancel_delayed_work_sync(&hcon->disc_work) which would lead to a deadlock if the hci_conn_timeout() call path tries to acquire the same lock. This patch solves the problem by deferring the cleanup work to a separate work callback. To protect against the hci_dev or hci_conn going away meanwhile temporary references are taken with the help of hci_dev_hold() and hci_conn_get(). Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Cc: stable@vger.kernel.org # 4.3
* Bluetooth: btintel: Enable extra Intel vendor eventsMarcel Holtmann2015-10-213-9/+92
| | | | | | | | | | The Intel Bluetooth controllers can emit extra vendor specific events in error conditions or for debugging purposes. To make the life easier for engineers, enable them by default. When the vendor_diag options has been enabled, then additional debug events are also enabled. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: btusb: Set manufacturer for Intel bootloader devicesMarcel Holtmann2015-10-211-1/+3
| | | | | | | | For Intel bootloader devices, set the manufacturer information so that it becomes possible to decode the boot process. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Introduce driver specific post init callbackMarcel Holtmann2015-10-212-1/+5
| | | | | | | | | | Some drivers might have to restore certain settings after the init procedure has been completed. This driver callback allows them to hook into that stage. This callback is run just before the controller is declared as powered up. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: hci_uart: Provide initial manufacturer informationMarcel Holtmann2015-10-216-0/+12
| | | | | | | | Provide an early indication about the manufacturer information so that it can be forwarded into monitor channel. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: l2cap_disconnection_req priority over shutdownDean Jenkins2015-10-211-1/+10
| | | | | | | | | | | | | | | | | There is a L2CAP protocol race between the local peer and the remote peer demanding disconnection of the L2CAP link. When L2CAP ERTM is used, l2cap_sock_shutdown() can be called from userland to disconnect L2CAP. However, there can be a delay introduced by waiting for ACKs. During this waiting period, the remote peer may have sent a Disconnection Request. Therefore, recheck the shutdown status of the socket after waiting for ACKs because there is no need to do further processing if the connection has gone. Signed-off-by: Dean Jenkins <Dean_Jenkins@mentor.com> Signed-off-by: Harish Jenny K N <harish_kandiga@mentor.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Reorganize mutex lock in l2cap_sock_shutdown()Dean Jenkins2015-10-211-17/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit reorganizes the mutex lock and is now only protecting l2cap_chan_close(). This is now consistent with other places where l2cap_chan_close() is called. If a conn connection exists, call mutex_lock(&conn->chan_lock) before calling l2cap_chan_close() to ensure other L2CAP protocol operations do not interfere. Note that the conn structure has to be protected from being freed as it is possible for the connection to be disconnected whilst the locks are not held. This solution allows the mutex lock to be used even when the connection has just been disconnected. This commit also reduces the scope of chan locking. The only place where chan locking is needed is the call to l2cap_chan_close(chan, 0) which if necessary closes the channel. Therefore, move the l2cap_chan_lock(chan) and l2cap_chan_lock(chan) locking calls to around l2cap_chan_close(chan, 0). This allows __l2cap_wait_ack(sk, chan) to be called with no chan locks being held so L2CAP messaging over the ACL link can be done unimpaired. Signed-off-by: Dean Jenkins <Dean_Jenkins@mentor.com> Signed-off-by: Harish Jenny K N <harish_kandiga@mentor.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Unwind l2cap_sock_shutdown()Dean Jenkins2015-10-211-14/+18
| | | | | | | | | | | | | l2cap_sock_shutdown() is designed to only action shutdown of the channel when shutdown is not already in progress. Therefore, reorganise the code flow by adding a goto to jump to the end of function handling when shutdown is already being actioned. This removes one level of code indentation and make the code more readable. Signed-off-by: Dean Jenkins <Dean_Jenkins@mentor.com> Signed-off-by: Harish Jenny K N <harish_kandiga@mentor.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* 6lowpan: put mcast compression in an own functionAlexander Aring2015-10-211-27/+32
| | | | | | | | This patch moves the mcast compression algorithmn to an own function like all other compression/decompression methods in iphc. Signed-off-by: Alexander Aring <alex.aring@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* 6lowpan: rework tc and flow label handlingAlexander Aring2015-10-211-85/+205
| | | | | | | | | | | | | | | | | | | | | | This patch reworks the handling of compression/decompression of traffic class and flow label handling. The current method is hard to understand, also doesn't checks if we can read the buffer from skb length. I tried to put the shifting operations into static inline functions and comment each steps which I did there to make it hopefully somewhat more readable. The big mess to deal with that is the that the ipv6 header bring the order "DSCP + ECN" but iphc uses "ECN + DSCP". Additional the DCSP + ECN bits are splitted in ipv6_hdr inside the priority and flow_lbl[0] fields. I tested these compressions by using fakelb 802.15.4 driver and manipulate the tc and flow label fields manually in function "__ip6_local_out" before the skb will be send to lower layers. Then I looked up the tc and flow label fields in wireshark on a wpan and lowpan interface. Signed-off-by: Alexander Aring <alex.aring@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* 6lowpan: iphc: change define valuesAlexander Aring2015-10-211-93/+106
| | | | | | | | | | | | | | This patch has the main goal to delete shift operations. Instead we doing masks and equals afterwards. E.g. for the SAM evaluation we masking only the SAM value which fits in iphc1 byte, then comparing with all possible SAM values over a switch case statement. We will not shifting the SAM value to somewhat readable anymore. Additional this patch slighty change the naming style like RFC 6282, e.g. TTL to HLIM and we will drop an errno now if CID flag is set, because we don't support it. Signed-off-by: Alexander Aring <alex.aring@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* 6lowpan: remove lowpan_is_addr_broadcastAlexander Aring2015-10-212-11/+1Star
| | | | | | | | This macro is used at 802.15.4 6LoWPAN only and can be replaced by memcmp with the interface broadcast address. Signed-off-by: Alexander Aring <alex.aring@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* 6lowpan: move IPHC functionality definesAlexander Aring2015-10-214-124/+112Star
| | | | | | | | | | | This patch removes the IPHC related defines for doing bit manipulation from global 6lowpan header to the iphc file which should the only one implementation which use these defines. Also move next header compression defines to their nhc implementation. Signed-off-by: Alexander Aring <alex.aring@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* 6lowpan: nhc: move iphc manipulation out of nhcAlexander Aring2015-10-213-17/+14Star
| | | | | | | | | This patch moves the iphc setting of next header commpression bit inside iphc functionality. Setting of IPHC bits should be happen at iphc.c file only. Signed-off-by: Alexander Aring <alex.aring@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* 6lowpan: remove lowpan_fetch_skb_u8Alexander Aring2015-10-212-15/+16
| | | | | | | | | | This patch removes the lowpan_fetch_skb_u8 function for getting the iphc bytes. Instead we using the generic which has a len parameter to tell the amount of bytes to fetch. Signed-off-by: Alexander Aring <alex.aring@gmail.com> Acked-by: Jukka Rissanen <jukka.rissanen@linux.intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* 6lowpan: cleanup lowpan_header_decompressAlexander Aring2015-10-217-96/+103
| | | | | | | | | | | | | | | | | | | | | | | | This patch changes the lowpan_header_decompress function by removing inklayer related information from parameters. This is currently for supporting short and extended address for iphc handling in 802154. We don't support short address handling anyway right now, but there exists already code for handling short addresses in lowpan_header_decompress. The address parameters are also changed to a void pointer, so 6LoWPAN linklayer specific code can put complex structures as these parameters and cast it again inside the generic code by evaluating linklayer type before. The order is also changed by destination address at first and then source address, which is the same like all others functions where destination is always the first, memcpy, dev_hard_header, lowpan_header_compress, etc. This patch also moves the fetching of iphc values from 6LoWPAN linklayer specific code into the generic branch. Signed-off-by: Alexander Aring <alex.aring@gmail.com> Acked-by: Jukka Rissanen <jukka.rissanen@linux.intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* 6lowpan: cleanup lowpan_header_compressAlexander Aring2015-10-214-20/+32
| | | | | | | | | | | | | This patch changes the lowpan_header_compress function by removing unused parameters like "len" and drop static value parameters of protocol type. Instead we really check the protocol type inside inside the skb structure. Also we drop the use of IEEE802154_ADDR_LEN which is link-layer specific. Instead we using EUI64_ADDR_LEN which should always the default case for now. Signed-off-by: Alexander Aring <alex.aring@gmail.com> Acked-by: Jukka Rissanen <jukka.rissanen@linux.intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* 6lowpan: introduce LOWPAN_IPHC_MAX_HC_BUF_LENAlexander Aring2015-10-212-1/+9
| | | | | | | | | | This patch introduces the LOWPAN_IPHC_MAX_HC_BUF_LEN define which represent the worst-case supported IPHC buffer length. It's used to allocate the stack buffer space for creating the IPHC header. Signed-off-by: Alexander Aring <alex.aring@gmail.com> Acked-by: Jukka Rissanen <jukka.rissanen@linux.intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* bluetooth: 6lowpan: use lowpan dispatch helpersAlexander Aring2015-10-211-30/+27Star
| | | | | | | | | | | | | | This patch adds a check if the dataroom of skb contains a dispatch value by checking if skb->len != 0. This patch also change the dispatch evaluation by the recently introduced helpers for checking the common 6LoWPAN dispatch values for IPv6 and IPHC header. There was also a forgotten else branch which should drop the packet if no matching dispatch is available. Signed-off-by: Alexander Aring <alex.aring@gmail.com> Acked-by: Jukka Rissanen <jukka.rissanen@linux.intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* mac802154: llsec: use kzfreeAlexander Aring2015-10-211-10/+10
| | | | | | | | This patch will use kzfree instead kfree for security related information which can be offered by acccident. Signed-off-by: Alexander Aring <alex.aring@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Fix removing connection parameters when unpairingJohan Hedberg2015-10-211-5/+7
| | | | | | | | | | | | | | | | | | | | | The commit 89cbb0638e9b7 introduced support for deferred connection parameter removal when unpairing by removing them only once an existing connection gets disconnected. However, it failed to address the scenario when we're *not* connected and do an unpair operation. What makes things worse is that most user space BlueZ versions will first issue a disconnect request and only then unpair, meaning the buggy code will be triggered every time. This effectively causes the kernel to resume scanning and reconnect to a device for which we've removed all keys and GATT database information. This patch fixes the issue by adding the missing call to the hci_conn_params_del() function to a branch which handles the case of no existing connection. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Cc: stable@vger.kernel.org # 3.19+
* Bluetooth: btusb: Add support for latest Apple controllersMarcel Holtmann2015-10-211-7/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The latest Apple Bluetooth controllers with Broadcom chip in it have a small design change. Instead of including a USB hub with mouse and keyboard devices, they are now HID interfaces on the same device. T: Bus=04 Lev=02 Prnt=02 Port=04 Cnt=01 Dev#= 39 Spd=12 MxCh= 0 D: Ver= 2.01 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=05ac ProdID=8290 Rev= 0.79 S: Manufacturer=Broadcom Corp. S: Product=Bluetooth USB Host Controller C:* #Ifs= 6 Cfg#= 1 Atr=e0 MxPwr= 0mA A: FirstIf#= 2 IfCount= 4 Cls=ff(vend.) Sub=01 Prot=01 I:* If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=01 Driver=usbhid E: Ad=85(I) Atr=03(Int.) MxPS= 8 Ivl=10ms I:* If#= 1 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=02 Driver=usbhid E: Ad=86(I) Atr=03(Int.) MxPS= 8 Ivl=10ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 3 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 3 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 3 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 3 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 3 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms I:* If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=btusb E: Ad=84(I) Atr=02(Bulk) MxPS= 32 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 32 Ivl=0ms I:* If#= 5 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none) The general layout of Bluetooth devices is that interface 0 is the main interface and interface 1 is for audio data. This design obviously moves it to main interface 2 and audio data on interface 3. Starting with the MacBookPro12,1 (early 2015 models) the new Broadcom BCM943602CS cards are used which show this interface layout. usb 4-1.5: New USB device found, idVendor=05ac, idProduct=8290 usb 4-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 4-1.5: Product: Bluetooth USB Host Controller usb 4-1.5: Manufacturer: Broadcom Corp. Bluetooth: hci0: BCM: chip id 102 build 0243 Bluetooth: hci0: BCM: product 05ac:8290 Bluetooth: hci0: BCM20703A1 Generic USB UHE Apple 20Mhz fcbga_X87 Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: btusb: Set early vendor info for Intel and BroadcomMarcel Holtmann2015-10-211-0/+4
| | | | | | | | | | | | For the controllers from Intel and Broadcom (including Apple), it is helpful to have the information about the manufacturer send out early. This patch sets the hdev->manufacturer information which will be send out before actually calling the vendor specific hdev->setup driver callback. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Add support setup stage internal notification eventMarcel Holtmann2015-10-213-8/+19
| | | | | | | | | | | | Before the vendor specific setup stage is triggered call back into the core to trigger an internal notification event. That event is used to send an index update to the monitor interface. With that specific event it is possible to update userspace with manufacturer information before any HCI command has been executed. This is useful for early stage debugging of vendor specific initialization sequences. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2024-11-20 02:32:20 +0100