1. 02 12月, 2011 1 次提交
    • A
      Bluetooth: Add dev_flags to struct hci_dev · d23264a8
      Andre Guedes 提交于
      This patch adds the dev_flags field to struct hci_dev. This new
      flags variable should be used to define flags related to BR/EDR
      and/or LE controller itself. It should be used to define flags
      which represents states from the controller. The dev_flags is
      cleared in case the controller sends a Reset Command Complete
      Event to the host.
      
      Also, this patch adds the HCI_LE_SCAN flag which was created to
      track if the controller is performing LE scan or not. The flag
      is set/cleared when the controller starts/stops scanning.
      
      This is an initial effort to stop using hdev->flags to define
      internal flags since it is exported to userspace by an ioctl.
      Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
      Acked-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
      d23264a8
  2. 22 11月, 2011 2 次提交
  3. 17 11月, 2011 2 次提交
  4. 09 11月, 2011 4 次提交
  5. 08 11月, 2011 12 次提交
  6. 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
  7. 15 10月, 2011 3 次提交
  8. 21 9月, 2011 3 次提交
  9. 12 8月, 2011 2 次提交
  10. 09 7月, 2011 2 次提交
  11. 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
  12. 07 7月, 2011 2 次提交
  13. 01 7月, 2011 1 次提交
  14. 18 6月, 2011 1 次提交
  15. 17 6月, 2011 1 次提交
  16. 14 6月, 2011 1 次提交
  17. 09 6月, 2011 1 次提交
    • 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