Since discovery also deals with LE scanning it makes sense to move it
behind the same req_workqueue as other LE scanning changes. This also
simplifies the logic since we do many of the actions in a synchronous
manner.

Part of this refactoring is moving hci_req_stop_discovery() to
hci_request.c. At the same time the function receives support for
properly handling the STOPPING state since that's the state we'll be
in when stopping through the req_workqueue.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

Since discovery also deals with LE scanning it makes sense to move it
behind the same req_workqueue as other LE scanning changes. This also
simplifies the logic since we do many of the actions in a synchronous
manner.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

In some circumstances it may be useful to abort the request through
checks done in the request callback. To make the feature possible this
patch changes the return value of the request callback from void to
int and aborts the request if a non-zero value is returned.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

As preparation for moving the discovery HCI commands behind
req_workqueue, add a helper and do the validity checks of the given
discovery type before proceeding further. This way we don't need to do
them again in hci_request.c.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

To avoid any risks of races, place also these LE scan modification
work callbacks behind the same work queue as the other LE scan
changes.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

There are no more external users so this API can be made private.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

We can easily use the new req_workqueue based background scan update
for the power on case. This also removes the last external user of
__hci_update_background_scan().
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

Since explicit connect requests are also a sub-category of passive
scan updates, run them through the same workqueue as the other passive
scan changes.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

In some cases it may be important to get the exact HCI status rather
than the converted HCI-to-errno value. Add an optional return
parameter to the hci_req_sync() API to allow for this. Since there are
no good HCI translation candidates for cancelation and timeout, use
the "unknown" status code for those cases.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

There's no point in waiting for HCI activity in Add/Remove Device
since the effects of these calls are long-lasting and we can anyway
not report up to the application all HCI failures.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

Instead of firing off a simple async request queue all background scan
updates through req_workqueue and use hci_req_sync() there to ensure
that no two updates overlap with each other.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

Prepare hci_request.c to have code for doing synchronous HCI requests,
such as LE scanning or advertising changes. The necessary work
callbacks will be set up in hci_request_setup() and cleaned up in
hci_request_cancel_all(). The former is used when an HCI device get
registered, and the latter each time it is powered off (or
unregistered).
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

To make it clear which HCI request APIs target specifically
synchronous requests, add 'sync' to the API names.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

hci_request.c is a more natural place for the synchronous request
handling. Furthermore, we will soon need access to some of the
previously private-to-hci_core.c functions from hci_request.c.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

The hci_conn_params_clear_all() function is only called from
hci_unregister_dev() at which point it's completely futile to try to
do any LE scanning updates. Simply remove this unnecessary function
call. At the same time we can make the function static since it's only
accessed from within the same c-file.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

To enable controller specific logging, the userspace daemon has to have
the ability to log per controller. To facilitate this support, provide
a dedicated logging channel. Messages in this channel will be included
in the monitor queue and with that also forwarded to monitoring tools
along with the actual hardware traces.

All messages from the logging channel are timestamped and with that
allow an easy correlation between userspace messages and hardware
events. This will increase the ability to debug problems faster.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>

The monitor channel can be used to send generic system notes as text
strings for debugging purposes. This adds the system note monitor code
and uses it for including kernel and subsystem version into traces.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>

The HCI sockets code has still some old casting coding style. Fix this
to match with the rest of the code.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>

It's not obvious why schedule_work is used instead of queue_work. Add
a comment explaining why.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

When HCI commands are injected via the raw socket, the core was not
including the decoded opcode value. So ensure that it is actually set.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>

We can reduce the size of the hci_ctrl struct by converting
'bool req_start' to 'u8 req_flags' and making the two function
pointers a union (since only one is ever set at a time).
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

The new hci_skb_pkt_* wrappers only help if they are used consistently
in the Bluetooth subsystem. So first convert the core packet handling.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>

For the LE only controllers, there are events that should not be enabled
if the corresponding command is not supported.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>

When setting the event mask, the HCI_QUIRK_FIXUP_INQUIRY_MODE quirk is
required to be checked so that the Inquiry Result with RSSI event gets
actually enabled.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>

The LE event mask should be created based on the commands that are
actually supported by the controller.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>

There are some BR/EDR default events for Bluetooth 1.2 or later
controllers that are not conditional on their features being present.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>

When receiving a connect response we should make sure that the DCID is
within the valid range and that we don't already have another channel
allocated for the same DCID.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

The 'dyn_end' value is also a valid CID so it should be included in
the range of values checked.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

The core spec defines specific response codes for situations when the
received CID is incorrect. Add the defines for these and return them
as appropriate from the LE Connect Request handler function.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

The white list commands might not be implemented if the controller does
not actually support the white list. So check the supported commands
first before issuing these commands. Not supporting the white list is
the same as supporting a white list with zero size.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>

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 5ff3fec6 ("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: NJukka Rissanen <jukka.rissanen@linux.intel.com>
Signed-off-by: NAlexander Aring <alex.aring@gmail.com>
Acked-by: NJukka Rissanen <jukka.rissanen@linux.intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

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: NKuba Pawlak <kubax.t.pawlak@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

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

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

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

There are two checks that are still using (MSG_OOB) instead of just
MSG_OOB and so lets just fix them.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>

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: NKuba Pawlak <kubax.t.pawlak@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

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: NKuba Pawlak <kubax.t.pawlak@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

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: NKuba Pawlak <kubax.t.pawlak@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

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