Bluetooth: Trivial refactoring

This patch replaces the unlock-and-return statements by the goto
statement.

Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Bluetooth: Fix hci_le_conn_complete_evt

We need to check the 'Role' parameter from the LE Connection
Complete Event in order to properly set 'out' and 'link_mode'
fields from hci_conn structure.

Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Bluetooth: Remove unneeded code

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: Andre Guedes <andre.guedes@openbossa.org>
Bluetooth: Refactor hci_cs_le_create_conn

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 always want to
close connection if it fails.

Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Bluetooth: Find hci_conn by BT_CONNECT state

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: Andre Guedes <andre.guedes@openbossa.org>
Bluetooth: Lookup hci_conn in hci_le_conn_complete_evt

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: Andre Guedes <andre.guedes@openbossa.org>
Bluetooth: Refactor in hci_le_conn_complete_evt

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: Andre Guedes <andre.guedes@openbossa.org>
Bluetooth: Make __hci_request non-static

This patch removes the static modifier from __hci_request helper
so it can be used outside hci_core.

Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Bluetooth: LE Add to White List HCI command

This patch adds the LE Add to White List HCI command opcode,
command parameter struct and command complete function handler.

Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Bluetooth: LE connection work

Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Bluetooth: Schedule le_conn work in hci_le_connect

Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Bluetooth: LE Remove from White List HCI command

This patch adds the "LE Remove from White List" HCI command opcode
and command parameter struct.

Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Bluetooth: Remove entries from white list

Once the connection establishment terminates (successfully or
failure) the address should be removed from the white list.

Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Bluetooth: Reduce critical region in hci_dev_open

This patch reduces the critical region protected by hci_req_lock/
hci_req_unlock in hci_dev_open. This way, req_lock mutex is only
aquired if it is really needed. Also, this way, we avoid unneeded
locking nesting hci_req_lock-hci_dev_lock-hci_dev_unlock-hci_req_
unlock.

This patch fixes the following circular locking dependecy:

======================================================
[ INFO: possible circular locking dependency detected ]
3.5.0-rc1+ #7 Not tainted
-------------------------------------------------------
kworker/u:2/440 is trying to acquire lock:
 ((&conn->le_conn)){+.+...}, at: [<ffffffff810385f7>] wait_on_work+0x0/0xb7

but task is already holding lock:
 (&hdev->lock){+.+.+.}, at: [<ffffffffa0064ff8>] hci_event_packet+0x667/0x23f7 [bluetooth]

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #2 (&hdev->lock){+.+.+.}:
       [<ffffffff8105b455>] lock_acquire+0x93/0xb1
       [<ffffffff812bf8c9>] __mutex_lock_common+0x5d/0x3a1
       [<ffffffff812bfd08>] mutex_lock_nested+0x3b/0x40
       [<ffffffffa005dda1>] hci_dev_open+0x184/0x23f [bluetooth]
       [<ffffffffa005de97>] hci_power_on+0x3b/0x86 [bluetooth]
       [<ffffffff81038b52>] process_one_work+0x18b/0x2dd
       [<ffffffff81038f12>] worker_thread+0xcf/0x174
       [<ffffffff8103ccb8>] kthread+0x95/0x9d
       [<ffffffff812c3bd4>] kernel_thread_helper+0x4/0x10

-> #1 (&hdev->req_lock){+.+.+.}:
       [<ffffffff8105b455>] lock_acquire+0x93/0xb1
       [<ffffffff812bf8c9>] __mutex_lock_common+0x5d/0x3a1
       [<ffffffff812bfd08>] mutex_lock_nested+0x3b/0x40
       [<ffffffffa005fdf1>] le_connection_work+0x80/0x102 [bluetooth]
       [<ffffffff81038b52>] process_one_work+0x18b/0x2dd
       [<ffffffff81038f12>] worker_thread+0xcf/0x174
       [<ffffffff8103ccb8>] kthread+0x95/0x9d
       [<ffffffff812c3bd4>] kernel_thread_helper+0x4/0x10

-> #0 ((&conn->le_conn)){+.+...}:
       [<ffffffff8105ac72>] __lock_acquire+0xa2e/0xda2
       [<ffffffff8105b455>] lock_acquire+0x93/0xb1
       [<ffffffff81038645>] wait_on_work+0x4e/0xb7
       [<ffffffff81038968>] __cancel_work_timer+0xb3/0xf6
       [<ffffffff810389c5>] cancel_work_sync+0xb/0xd
       [<ffffffffa006144e>] hci_conn_del+0x96/0x188 [bluetooth]
       [<ffffffffa0066965>] hci_event_packet+0x1fd4/0x23f7 [bluetooth]
       [<ffffffffa005c142>] hci_rx_work+0xf3/0x33c [bluetooth]
       [<ffffffff81038b52>] process_one_work+0x18b/0x2dd
       [<ffffffff81038f12>] worker_thread+0xcf/0x174
       [<ffffffff8103ccb8>] kthread+0x95/0x9d
       [<ffffffff812c3bd4>] kernel_thread_helper+0x4/0x10

other info that might help us debug this:

Chain exists of:
  (&conn->le_conn) --> &hdev->req_lock --> &hdev->lock

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(&hdev->lock);
                               lock(&hdev->req_lock);
                               lock(&hdev->lock);
  lock((&conn->le_conn));

 *** DEADLOCK ***

3 locks held by kworker/u:2/440:
 #0:  (hdev->name){.+.+.+}, at: [<ffffffff81038af1>] process_one_work+0x12a/0x2dd
 #1:  ((&hdev->rx_work)){+.+.+.}, at: [<ffffffff81038af1>] process_one_work+0x12a/0x2dd
 #2:  (&hdev->lock){+.+.+.}, at: [<ffffffffa0064ff8>] hci_event_packet+0x667/0x23f7 [bluetooth]

stack backtrace:
Pid: 440, comm: kworker/u:2 Not tainted 3.5.0-rc1+ #7
Call Trace:
 [<ffffffff812bbcfd>] print_circular_bug+0x1f8/0x209
 [<ffffffff8105ac72>] __lock_acquire+0xa2e/0xda2
 [<ffffffff81036e71>] ? spin_unlock_irq+0x9/0xb
 [<ffffffff8105b455>] lock_acquire+0x93/0xb1
 [<ffffffff810385f7>] ? wait_on_cpu_work+0x70/0x70
 [<ffffffff81059d25>] ? lock_is_held+0x8a/0x9c
 [<ffffffff81038645>] wait_on_work+0x4e/0xb7
 [<ffffffff810385f7>] ? wait_on_cpu_work+0x70/0x70
 [<ffffffff8102f376>] ? del_timer+0x78/0x87
 [<ffffffff81038968>] __cancel_work_timer+0xb3/0xf6
 [<ffffffff810389c5>] cancel_work_sync+0xb/0xd
 [<ffffffffa006144e>] hci_conn_del+0x96/0x188 [bluetooth]
 [<ffffffffa0066965>] hci_event_packet+0x1fd4/0x23f7 [bluetooth]
 [<ffffffffa006d797>] ? hci_send_to_sock+0x17d/0x18c [bluetooth]
 [<ffffffffa005c142>] hci_rx_work+0xf3/0x33c [bluetooth]
 [<ffffffff81038af1>] ? process_one_work+0x12a/0x2dd
 [<ffffffff81058e31>] ? trace_hardirqs_on_caller+0x112/0x1ad
 [<ffffffff81038b52>] process_one_work+0x18b/0x2dd
 [<ffffffff81038af1>] ? process_one_work+0x12a/0x2dd
 [<ffffffffa005c04f>] ? hci_conn_hash_lookup_handle+0x8a/0x8a [bluetooth]
 [<ffffffff81036e66>] ? spin_lock_irq+0x9/0xb
 [<ffffffff81038f12>] worker_thread+0xcf/0x174
 [<ffffffff81038e43>] ? rescuer_thread+0x175/0x175
 [<ffffffff8103ccb8>] kthread+0x95/0x9d
 [<ffffffff812c3bd4>] kernel_thread_helper+0x4/0x10
 [<ffffffff812c2230>] ? retint_restore_args+0x13/0x13
 [<ffffffff8103cc23>] ? flush_kthread_worker+0xdb/0xdb
 [<ffffffff812c3bd0>] ? gs_change+0x13/0x13

Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Bluetooth: Reduce critical region in hci_dev_do_close

This patch reduces the critical region protected by hci_req_lock/
hci_req_unlock in hci_dev_do_close.

This patch fixes the following circular locking dependecy:

======================================================
[ INFO: possible circular locking dependency detected ]
3.5.0-rc1+ #7 Not tainted
-------------------------------------------------------
kworker/u:2/440 is trying to acquire lock:
 ((&conn->le_conn)){+.+...}, at: [<ffffffff810385f7>] wait_on_work+0x0/0xb7

but task is already holding lock:
 (&hdev->lock){+.+.+.}, at: [<ffffffffa00beffc>] hci_event_packet+0x667/0x23f7 [bluetooth]

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #3 (&hdev->lock){+.+.+.}:
       [<ffffffff8105b455>] lock_acquire+0x93/0xb1
       [<ffffffff812bf8c9>] __mutex_lock_common+0x5d/0x3a1
       [<ffffffff812bfd08>] mutex_lock_nested+0x3b/0x40
       [<ffffffffa00bcb85>] hci_cmd_complete_evt+0x942/0x1c96 [bluetooth]
       [<ffffffffa00bf525>] hci_event_packet+0xb90/0x23f7 [bluetooth]
       [<ffffffffa00b6142>] hci_rx_work+0xf3/0x33c [bluetooth]
       [<ffffffff81038b52>] process_one_work+0x18b/0x2dd
       [<ffffffff81038f12>] worker_thread+0xcf/0x174
       [<ffffffff8103ccb8>] kthread+0x95/0x9d
       [<ffffffff812c3bd4>] kernel_thread_helper+0x4/0x10

-> #2 ((&hdev->rx_work)){+.+.+.}:
       [<ffffffff8105b455>] lock_acquire+0x93/0xb1
       [<ffffffff81038539>] flush_work+0x34/0x82
       [<ffffffffa00b716b>] hci_dev_do_close+0x11f/0x2cb [bluetooth]
       [<ffffffffa00b7351>] hci_power_off+0x3a/0x3f [bluetooth]
       [<ffffffff81038b52>] process_one_work+0x18b/0x2dd
       [<ffffffff81038f12>] worker_thread+0xcf/0x174
       [<ffffffff8103ccb8>] kthread+0x95/0x9d
       [<ffffffff812c3bd4>] kernel_thread_helper+0x4/0x10

-> #1 (&hdev->req_lock){+.+...}:
       [<ffffffff8105b455>] lock_acquire+0x93/0xb1
       [<ffffffff812bf8c9>] __mutex_lock_common+0x5d/0x3a1
       [<ffffffff812bfd08>] mutex_lock_nested+0x3b/0x40
       [<ffffffffa00b9df5>] le_connection_work+0x80/0x102 [bluetooth]
       [<ffffffff81038b52>] process_one_work+0x18b/0x2dd
       [<ffffffff81038f12>] worker_thread+0xcf/0x174
       [<ffffffff8103ccb8>] kthread+0x95/0x9d
       [<ffffffff812c3bd4>] kernel_thread_helper+0x4/0x10

-> #0 ((&conn->le_conn)){+.+...}:
       [<ffffffff8105ac72>] __lock_acquire+0xa2e/0xda2
       [<ffffffff8105b455>] lock_acquire+0x93/0xb1
       [<ffffffff81038645>] wait_on_work+0x4e/0xb7
       [<ffffffff81038968>] __cancel_work_timer+0xb3/0xf6
       [<ffffffff810389c5>] cancel_work_sync+0xb/0xd
       [<ffffffffa00bb452>] hci_conn_del+0x96/0x188 [bluetooth]
       [<ffffffffa00c0969>] hci_event_packet+0x1fd4/0x23f7 [bluetooth]
       [<ffffffffa00b6142>] hci_rx_work+0xf3/0x33c [bluetooth]
       [<ffffffff81038b52>] process_one_work+0x18b/0x2dd
       [<ffffffff81038f12>] worker_thread+0xcf/0x174
       [<ffffffff8103ccb8>] kthread+0x95/0x9d
       [<ffffffff812c3bd4>] kernel_thread_helper+0x4/0x10

other info that might help us debug this:

Chain exists of:
  (&conn->le_conn) --> (&hdev->rx_work) --> &hdev->lock

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(&hdev->lock);
                               lock((&hdev->rx_work));
                               lock(&hdev->lock);
  lock((&conn->le_conn));

 *** DEADLOCK ***

3 locks held by kworker/u:2/440:
 #0:  (hdev->name){.+.+.+}, at: [<ffffffff81038af1>] process_one_work+0x12a/0x2dd
 #1:  ((&hdev->rx_work)){+.+.+.}, at: [<ffffffff81038af1>] process_one_work+0x12a/0x2dd
 #2:  (&hdev->lock){+.+.+.}, at: [<ffffffffa00beffc>] hci_event_packet+0x667/0x23f7 [bluetooth]

stack backtrace:
Pid: 440, comm: kworker/u:2 Not tainted 3.5.0-rc1+ #7
Call Trace:
 [<ffffffff812bbcfd>] print_circular_bug+0x1f8/0x209
 [<ffffffff8105ac72>] __lock_acquire+0xa2e/0xda2
 [<ffffffff81036e71>] ? spin_unlock_irq+0x9/0xb
 [<ffffffff8105b455>] lock_acquire+0x93/0xb1
 [<ffffffff810385f7>] ? wait_on_cpu_work+0x70/0x70
 [<ffffffff81059d25>] ? lock_is_held+0x8a/0x9c
 [<ffffffff81038645>] wait_on_work+0x4e/0xb7
 [<ffffffff810385f7>] ? wait_on_cpu_work+0x70/0x70
 [<ffffffff8102f376>] ? del_timer+0x78/0x87
 [<ffffffff81038968>] __cancel_work_timer+0xb3/0xf6
 [<ffffffff810389c5>] cancel_work_sync+0xb/0xd
 [<ffffffffa00bb452>] hci_conn_del+0x96/0x188 [bluetooth]
 [<ffffffffa00c0969>] hci_event_packet+0x1fd4/0x23f7 [bluetooth]
 [<ffffffffa00c779b>] ? hci_send_to_sock+0x17d/0x18c [bluetooth]
 [<ffffffffa00b6142>] hci_rx_work+0xf3/0x33c [bluetooth]
 [<ffffffff81038af1>] ? process_one_work+0x12a/0x2dd
 [<ffffffff81058e31>] ? trace_hardirqs_on_caller+0x112/0x1ad
 [<ffffffff81038b52>] process_one_work+0x18b/0x2dd
 [<ffffffff81038af1>] ? process_one_work+0x12a/0x2dd
 [<ffffffffa00b604f>] ? hci_conn_hash_lookup_handle+0x8a/0x8a [bluetooth]
 [<ffffffff81036e66>] ? spin_lock_irq+0x9/0xb
 [<ffffffff81038f12>] worker_thread+0xcf/0x174
 [<ffffffff81038e43>] ? rescuer_thread+0x175/0x175
 [<ffffffff8103ccb8>] kthread+0x95/0x9d
 [<ffffffff812c3bd4>] kernel_thread_helper+0x4/0x10
 [<ffffffff812c2230>] ? retint_restore_args+0x13/0x13
 [<ffffffff8103cc23>] ? flush_kthread_worker+0xdb/0xdb
 [<ffffffff812c3bd0>] ? gs_change+0x13/0x13

Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>