1. 15 2月, 2015 1 次提交
  2. 02 2月, 2015 2 次提交
  3. 31 1月, 2015 1 次提交
  4. 29 1月, 2015 1 次提交
  5. 24 1月, 2015 1 次提交
  6. 16 1月, 2015 1 次提交
  7. 13 1月, 2015 1 次提交
  8. 03 1月, 2015 1 次提交
  9. 21 12月, 2014 1 次提交
  10. 20 12月, 2014 3 次提交
  11. 19 12月, 2014 2 次提交
  12. 05 12月, 2014 3 次提交
  13. 03 12月, 2014 7 次提交
  14. 19 11月, 2014 1 次提交
  15. 18 11月, 2014 1 次提交
  16. 15 11月, 2014 2 次提交
  17. 03 11月, 2014 1 次提交
  18. 02 11月, 2014 1 次提交
  19. 25 10月, 2014 3 次提交
  20. 17 9月, 2014 1 次提交
  21. 09 9月, 2014 5 次提交
    • J
      Bluetooth: Fix mgmt pairing failure when authentication fails · e1e930f5
      Johan Hedberg 提交于
      Whether through HCI with BR/EDR or SMP with LE when authentication fails
      we should also notify any pending Pair Device mgmt command. This patch
      updates the mgmt_auth_failed function to take the actual hci_conn object
      and makes sure that any pending pairing command is notified and cleaned
      up appropriately.
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      e1e930f5
    • J
      Bluetooth: Fix locking of the SMP context · fc75cc86
      Johan Hedberg 提交于
      Before the move the l2cap_chan the SMP context (smp_chan) didn't have
      any kind of proper locking. The best there existed was the
      HCI_CONN_LE_SMP_PEND flag which was used to enable mutual exclusion for
      potential multiple creators of the SMP context.
      
      Now that SMP has been converted to use the l2cap_chan infrastructure and
      since the SMP context is directly mapped to a corresponding l2cap_chan
      we get the SMP context locking essentially for free through the
      l2cap_chan lock. For all callbacks that l2cap_core.c makes for each
      channel implementation (smp.c in the case of SMP) the l2cap_chan lock is
      held through l2cap_chan_lock(chan).
      
      Since the calls from l2cap_core.c to smp.c are covered the only missing
      piece to have the locking implemented properly is to ensure that the
      lock is held for any other call path that may access the SMP context.
      This means user responses through mgmt.c, requests to elevate the
      security of a connection through hci_conn.c, as well as any deferred
      work through workqueues.
      
      This patch adds the necessary locking to all these other code paths that
      try to access the SMP context. Since mutual exclusion for the l2cap_chan
      access is now covered from all directions the patch also removes
      unnecessary HCI_CONN_LE_SMP_PEND flag (once we've acquired the chan lock
      we can simply check whether chan->smp is set to know if there's an SMP
      context).
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      fc75cc86
    • J
      Bluetooth: Update hci_disconnect() to return an error value · e3b679d5
      Johan Hedberg 提交于
      We'll soon use hci_disconnect() from places that are interested to know
      whether the hci_send_cmd() really succeeded or not. This patch updates
      hci_disconnect() to pass on any error returned from hci_send_cmd().
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      e3b679d5
    • J
      Bluetooth: Ignore incoming data after initiating disconnection · f94b665d
      Johan Hedberg 提交于
      When hci_chan_del is called the disconnection routines get scheduled
      through a workqueue. If there's any incoming ACL data before the
      routines get executed there's a chance that a new hci_chan is created
      and the disconnection never happens. This patch adds a new hci_conn flag
      to indicate that we're in the process of driving the connection down. We
      set the flag in hci_chan_del and check for it in hci_chan_create so that
      no new channels are created for the same connection.
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      f94b665d
    • J
      Bluetooth: Use zero timeout for immediate scheduling · eb78d7e5
      Johan Hedberg 提交于
      There's no point in passing a "small" timeout to queue_delayed_work() to
      try to get the callback faster scheduled. Passing 0 is perfectly valid
      and will cause a shortcut to a direct queue_work().
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      eb78d7e5