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>
WIP: Bluetooth: Fix circular locking

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

but task is already holding lock:
 (&hdev->lock){+.+.+.}, at: [<ffffffffa0086ff8>] 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
       [<ffffffffa007f1aa>] hci_dev_do_close+0x15e/0x2cb [bluetooth]
       [<ffffffffa007ff24>] hci_dev_close+0x42/0x5e [bluetooth]
       [<ffffffffa008e81f>] hci_sock_ioctl+0x11d/0x320 [bluetooth]
       [<ffffffff81233f76>] sock_ioctl+0x1f3/0x215
       [<ffffffff810bffcd>] vfs_ioctl+0x21/0x34
       [<ffffffff810c08c4>] do_vfs_ioctl+0x419/0x45c
       [<ffffffff810c0949>] sys_ioctl+0x42/0x65
       [<ffffffff812c29f9>] system_call_fastpath+0x16/0x1b

-> #1 (&hdev->req_lock){+.+.+.}:
       [<ffffffff8105b455>] lock_acquire+0x93/0xb1
       [<ffffffff812bf8c9>] __mutex_lock_common+0x5d/0x3a1
       [<ffffffff812bfd08>] mutex_lock_nested+0x3b/0x40
       [<ffffffffa0081df1>] 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
       [<ffffffffa008344e>] hci_conn_del+0x96/0x188 [bluetooth]
       [<ffffffffa0088965>] hci_event_packet+0x1fd4/0x23f7 [bluetooth]
       [<ffffffffa007e142>] 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:1/16:
 #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: [<ffffffffa0086ff8>] hci_event_packet+0x667/0x23f7 [bluetooth]

stack backtrace:
Pid: 16, comm: kworker/u:1 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
 [<ffffffffa008344e>] hci_conn_del+0x96/0x188 [bluetooth]
 [<ffffffffa0088965>] hci_event_packet+0x1fd4/0x23f7 [bluetooth]
 [<ffffffffa008f797>] ? hci_send_to_sock+0x17d/0x18c [bluetooth]
 [<ffffffffa007e142>] 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
 [<ffffffffa007e04f>] ? 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_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>