1. 24 12月, 2011 1 次提交
  2. 01 11月, 2011 1 次提交
    • S
      Bluetooth: Increase HCI reset timeout in hci_dev_do_close · e1b6eb3c
      Szymon Janc 提交于
      I've noticed that my CSR usb dongle was not working if it was plugged in when
      PC was booting. It looks like I get two HCI reset command complete events (see
      hcidump logs below).
      The root cause is reset called from off_timer. Timeout for this reset to
      complete is set to 250ms and my bt dongle requires more time for replying with
      command complete event. After that, chip seems to reply with reset command
      complete event for next non-reset command.
      
      Attached patch increase mentioned timeout to HCI_INIT_TIMEOUT, this value is
      already used for timeouting hci_reset_req in hci_dev_reset().
      
      This might also be related to BT not working after suspend that was reported
      here some time ago.
      
      Hcidump log:
      
      2011-09-12 23:13:27.379465 < HCI Command: Reset (0x03|0x0003) plen 0
      2011-09-12 23:13:27.380797 > HCI Event: Command Complete (0x0e) plen 4
          Reset (0x03|0x0003) ncmd 1
          status 0x00
      2011-09-12 23:13:27.380859 < HCI Command: Read Local Supported Features (0x04|0x000
      3) plen 0
      2011-09-12 23:13:27.760789 > HCI Event: Command Complete (0x0e) plen 4
          Reset (0x03|0x0003) ncmd 1
          status 0x00
      2011-09-12 23:13:27.760831 < HCI Command: Read Local Version Information (0x04|0x00
      01) plen 0
      2011-09-12 23:13:27.764780 > HCI Event: Command Complete (0x0e) plen 12
          Read Local Version Information (0x04|0x0001) ncmd 1
          status 0x00
          HCI Version: 1.1 (0x1) HCI Revision: 0x36f
          LMP Version: 1.1 (0x1) LMP Subversion: 0x36f
          Manufacturer: Cambridge Silicon Radio (10)
      Signed-off-by: NSzymon Janc <szymon@janc.net.pl>
      Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
      e1b6eb3c
  3. 21 9月, 2011 3 次提交
  4. 12 8月, 2011 2 次提交
  5. 09 7月, 2011 2 次提交
  6. 08 7月, 2011 1 次提交
    • A
      Bluetooth: Fix potential deadlock in hci_core · 8aded711
      Andre Guedes 提交于
      Since hdev->lock may be acquired by threads runnning in interrupt
      context, all threads running in process context should disable
      local bottom halve before locking hdev->lock. This can be done by
      using hci_dev_lock_bh macro.
      
      This way, we avoid potencial deadlocks like this one reported by
      CONFIG_PROVE_LOCKING=y.
      
      [  304.788780] =================================
      [  304.789686] [ INFO: inconsistent lock state ]
      [  304.789686] 2.6.39+ #1
      [  304.789686] ---------------------------------
      [  304.789686] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
      [  304.789686] ksoftirqd/0/3 [HC0[0]:SC1[1]:HE1:SE0] takes:
      [  304.789686]  (&(&hdev->lock)->rlock){+.?...}, at: [<ffffffffa000bbfe>] hci_conn_check_pending+0x38/0x76 [bluetooth]
      [  304.789686] {SOFTIRQ-ON-W} state was registered at:
      [  304.789686]   [<ffffffff8105188b>] __lock_acquire+0x347/0xd52
      [  304.789686]   [<ffffffff810526ac>] lock_acquire+0x8a/0xa7
      [  304.789686]   [<ffffffff812b3758>] _raw_spin_lock+0x2c/0x3b
      [  304.789686]   [<ffffffffa0009cf0>] hci_blacklist_del+0x1f/0x8a [bluetooth]
      [  304.789686]   [<ffffffffa00139fd>] hci_sock_ioctl+0x2d9/0x314 [bluetooth]
      [  304.789686]   [<ffffffff812197d8>] sock_ioctl+0x1f2/0x214
      [  304.789686]   [<ffffffff810b0fd6>] do_vfs_ioctl+0x46c/0x4ad
      [  304.789686]   [<ffffffff810b1059>] sys_ioctl+0x42/0x65
      [  304.789686]   [<ffffffff812b4892>] system_call_fastpath+0x16/0x1b
      [  304.789686] irq event stamp: 9768
      [  304.789686] hardirqs last  enabled at (9768): [<ffffffff812b40d4>] restore_args+0x0/0x30
      [  304.789686] hardirqs last disabled at (9767): [<ffffffff812b3f6a>] save_args+0x6a/0x70
      [  304.789686] softirqs last  enabled at (9726): [<ffffffff8102fa9b>] __do_softirq+0x129/0x13f
      [  304.789686] softirqs last disabled at (9739): [<ffffffff8102fb33>] run_ksoftirqd+0x82/0x133
      [  304.789686]
      [  304.789686] other info that might help us debug this:
      [  304.789686]  Possible unsafe locking scenario:
      [  304.789686]
      [  304.789686]        CPU0
      [  304.789686]        ----
      [  304.789686]   lock(&(&hdev->lock)->rlock);
      [  304.789686]   <Interrupt>
      [  304.789686]     lock(&(&hdev->lock)->rlock);
      [  304.789686]
      [  304.789686]  *** DEADLOCK ***
      [  304.789686]
      [  304.789686] 1 lock held by ksoftirqd/0/3:
      [  304.789686]  #0:  (hci_task_lock){++.-..}, at: [<ffffffffa0008353>] hci_rx_task+0x49/0x2f3 [bluetooth]
      [  304.789686]
      [  304.789686] stack backtrace:
      [  304.789686] Pid: 3, comm: ksoftirqd/0 Not tainted 2.6.39+ #1
      [  304.789686] Call Trace:
      [  304.789686]  [<ffffffff812ae901>] print_usage_bug+0x1e7/0x1f8
      [  304.789686]  [<ffffffff8100a796>] ? save_stack_trace+0x27/0x44
      [  304.789686]  [<ffffffff8104fc3f>] ? print_irq_inversion_bug.part.26+0x19a/0x19a
      [  304.789686]  [<ffffffff810504bb>] mark_lock+0x106/0x258
      [  304.789686]  [<ffffffff812b40d4>] ? retint_restore_args+0x13/0x13
      [  304.789686]  [<ffffffff81051817>] __lock_acquire+0x2d3/0xd52
      [  304.789686]  [<ffffffff8102be73>] ? vprintk+0x3ab/0x3d7
      [  304.789686]  [<ffffffff812ae126>] ? printk+0x3c/0x3e
      [  304.789686]  [<ffffffff810526ac>] lock_acquire+0x8a/0xa7
      [  304.789686]  [<ffffffffa000bbfe>] ? hci_conn_check_pending+0x38/0x76 [bluetooth]
      [  304.789686]  [<ffffffff811601c6>] ? __dynamic_pr_debug+0x10c/0x11a
      [  304.789686]  [<ffffffff812b3758>] _raw_spin_lock+0x2c/0x3b
      [  304.789686]  [<ffffffffa000bbfe>] ? hci_conn_check_pending+0x38/0x76 [bluetooth]
      [  304.789686]  [<ffffffffa000bbfe>] hci_conn_check_pending+0x38/0x76 [bluetooth]
      [  304.789686]  [<ffffffffa000c561>] hci_event_packet+0x38e/0x3e12 [bluetooth]
      [  304.789686]  [<ffffffff81052615>] ? lock_release+0x16c/0x179
      [  304.789686]  [<ffffffff812b3b41>] ? _raw_read_unlock+0x23/0x27
      [  304.789686]  [<ffffffffa0013e7f>] ? hci_send_to_sock+0x179/0x188 [bluetooth]
      [  304.789686]  [<ffffffffa00083d2>] hci_rx_task+0xc8/0x2f3 [bluetooth]
      [  304.789686]  [<ffffffff8102f5a9>] tasklet_action+0x87/0xe6
      [  304.789686]  [<ffffffff8102fa11>] __do_softirq+0x9f/0x13f
      [  304.789686]  [<ffffffff8102fb33>] run_ksoftirqd+0x82/0x133
      [  304.789686]  [<ffffffff8102fab1>] ? __do_softirq+0x13f/0x13f
      [  304.789686]  [<ffffffff81040f0a>] kthread+0x7f/0x87
      [  304.789686]  [<ffffffff812b55c4>] kernel_thread_helper+0x4/0x10
      [  304.789686]  [<ffffffff812b40d4>] ? retint_restore_args+0x13/0x13
      [  304.789686]  [<ffffffff81040e8b>] ? __init_kthread_worker+0x53/0x53
      [  304.789686]  [<ffffffff812b55c0>] ? gs_change+0x13/0x13
      Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
      Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
      8aded711
  7. 07 7月, 2011 2 次提交
  8. 01 7月, 2011 1 次提交
  9. 18 6月, 2011 1 次提交
  10. 17 6月, 2011 1 次提交
  11. 14 6月, 2011 1 次提交
  12. 09 6月, 2011 3 次提交
    • J
      Bluetooth: Add BT_POWER L2CAP socket option. · 14b12d0b
      Jaikumar Ganesh 提交于
      Add BT_POWER socket option used to control the power
      characteristics of the underlying ACL link. When the remote end
      has put the link in sniff mode and the host stack wants to send
      data we need need to explicitly exit sniff mode to work well with
      certain devices (For example, A2DP on Plantronics Voyager 855).
      However, this causes problems with HID devices.
      
      Hence, moving into active mode when sending data, irrespective
      of who set the sniff mode has been made as a socket option. By
      default, we will move into active mode. HID devices can set the
      L2CAP socket option to prevent this from happening.
      
      Currently, this has been implemented for L2CAP sockets. This has been
      tested with incoming and outgoing L2CAP sockets for HID and A2DP.
      
      Based on discussions on linux-bluetooth and patches submitted by
      Andrei Emeltchenko.
      Signed-off-by: NJaikumar Ganesh <jaikumar@google.com>
      Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
      14b12d0b
    • A
      Bluetooth: Advertising entries lifetime · 35815085
      Andre Guedes 提交于
      This patch adds a timer to clear 'adv_entries' after three minutes.
      
      After some amount of time, the advertising entries cached during
      the last LE scan should be considered expired and they should be
      removed from the advertising cache.
      
      It was chosen a three minutes timeout as an initial attempt. This
      value might change in future.
      Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
      Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
      35815085
    • A
      Bluetooth: LE advertising cache · 76c8686f
      Andre Guedes 提交于
      This patch implements the LE advertising cache. It stores sensitive
      information (bdaddr and bdaddr_type so far) gathered from LE
      advertising report events.
      
      Only advertising entries from connectables devices are added to the
      cache.
      Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
      Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
      76c8686f
  13. 06 6月, 2011 1 次提交
  14. 29 4月, 2011 6 次提交
  15. 19 4月, 2011 1 次提交
  16. 05 4月, 2011 1 次提交
  17. 01 4月, 2011 4 次提交
  18. 31 3月, 2011 1 次提交
  19. 25 3月, 2011 2 次提交
    • T
      Bluetooth: Fix warning with hci_cmd_timer · b77dcf84
      Thomas Gleixner 提交于
      After we made debugobjects working again, we got the following:
      
      WARNING: at lib/debugobjects.c:262 debug_print_object+0x8e/0xb0()
      Hardware name: System Product Name
      ODEBUG: free active (active state 0) object type: timer_list hint: hci_cmd_timer+0x0/0x60
      Pid: 2125, comm: dmsetup Tainted: G        W   2.6.38-06707-gc62b3898 #110375
      Call Trace:
       [<ffffffff8104700a>] warn_slowpath_common+0x7a/0xb0
       [<ffffffff810470b6>] warn_slowpath_fmt+0x46/0x50
       [<ffffffff812d3a5e>] debug_print_object+0x8e/0xb0
       [<ffffffff81bd8810>] ? hci_cmd_timer+0x0/0x60
       [<ffffffff812d4685>] debug_check_no_obj_freed+0x125/0x230
       [<ffffffff810f1063>] ? check_object+0xb3/0x2b0
       [<ffffffff810f3630>] kfree+0x150/0x190
       [<ffffffff81be4d06>] ? bt_host_release+0x16/0x20
       [<ffffffff81be4d06>] bt_host_release+0x16/0x20
       [<ffffffff813a1907>] device_release+0x27/0xa0
       [<ffffffff812c519c>] kobject_release+0x4c/0xa0
       [<ffffffff812c5150>] ? kobject_release+0x0/0xa0
       [<ffffffff812c61f6>] kref_put+0x36/0x70
       [<ffffffff812c4d37>] kobject_put+0x27/0x60
       [<ffffffff813a21f7>] put_device+0x17/0x20
       [<ffffffff81bda4f9>] hci_free_dev+0x29/0x30
       [<ffffffff81928be6>] vhci_release+0x36/0x70
       [<ffffffff810fb366>] fput+0xd6/0x1f0
       [<ffffffff810f8fe6>] filp_close+0x66/0x90
       [<ffffffff810f90a9>] sys_close+0x99/0xf0
       [<ffffffff81d4c96b>] system_call_fastpath+0x16/0x1b
      
      That timer was introduced with commit 6bd32326(Bluetooth: Use
      proper timer for hci command timout)
      
      Timer seems to be running when the thing is closed. Removing the timer
      unconditionally fixes the problem. And yes, it needs to be fixed
      before the HCI_UP check.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Tested-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
      b77dcf84
    • G
      Bluetooth: Fix HCI_RESET command synchronization · f630cf0d
      Gustavo F. Padovan 提交于
      We can't send new commands before a cmd_complete for the HCI_RESET command
      shows up.
      Reported-by: NMikko Vinni <mmvinni@yahoo.com>
      Reported-by: NJustin P. Mattock <justinmattock@gmail.com>
      Reported-by: NEd Tomlinson <edt@aei.ca>
      Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
      Tested-by: NJustin P. Mattock <justinmattock@gmail.com>
      Tested-by: NMikko Vinni <mmvinni@yahoo.com>
      Tested-by: NEd Tomlinson <edt@aei.ca>
      f630cf0d
  20. 18 2月, 2011 1 次提交
  21. 17 2月, 2011 4 次提交