1. 08 3月, 2013 5 次提交
    • J
      Bluetooth: Add initial skeleton for asynchronous HCI requests · 3119ae95
      Johan Hedberg 提交于
      This patch adds the initial definitions and functions for asynchronous
      HCI requests. Asynchronous requests are essentially a group of HCI
      commands together with an optional completion callback. The request is
      tracked through the already existing command queue by having the
      necessary context information as part of the control buffer of each skb.
      
      The only information needed in the skb control buffer is a flag for
      indicating that the skb is the start of a request as well as the
      optional complete callback that should be used when the request is
      complete (this will be found in the last skb of the request).
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Acked-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      3119ae95
    • D
      Bluetooth: Remove RFCOMM session refcnt · 08c30aca
      Dean Jenkins 提交于
      Previous commits have improved the handling of the RFCOMM session
      timer and the RFCOMM session pointers such that freed RFCOMM
      session structures should no longer be erroneously accessed. The
      RFCOMM session refcnt now has no purpose and will be deleted by
      this commit.
      
      Note that the RFCOMM session is now deleted as soon as the
      RFCOMM control channel link is no longer required. This makes the
      lifetime of the RFCOMM session deterministic and absolute.
      Previously with the refcnt, there was uncertainty about when
      the session structure would be deleted because the relative
      refcnt prevented the session structure from being deleted at will.
      
      It was noted that the refcnt could malfunction under very heavy
      real-time processor loading in embedded SMP environments. This
      could cause premature RFCOMM session deletion or double session
      deletion that could result in kernel crashes. Removal of the
      refcnt prevents this issue.
      
      There are 4 connection / disconnection RFCOMM session scenarios:
      host initiated control link ---> host disconnected control link
      host initiated ctrl link ---> remote device disconnected ctrl link
      remote device initiated ctrl link ---> host disconnected ctrl link
      remote device initiated ctrl link ---> remote device disc'ed ctrl link
      
      The control channel connection procedures are independent of the
      disconnection procedures. Strangely, the RFCOMM session refcnt was
      applying special treatment so erroneously combining connection and
      disconnection events. This commit fixes this issue by removing
      some session code that used the "initiator" member of the session
      structure that was intended for use with the data channels.
      Signed-off-by: NDean Jenkins <Dean_Jenkins@mentor.com>
      Acked-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      08c30aca
    • D
      Bluetooth: Return RFCOMM session ptrs to avoid freed session · 8ff52f7d
      Dean Jenkins 提交于
      Unfortunately, the design retains local copies of the s RFCOMM
      session pointer in various code blocks and this invites the erroneous
      access to a freed RFCOMM session structure.
      
      Therefore, return the RFCOMM session pointer back up the call stack
      to avoid accessing a freed RFCOMM session structure. When the RFCOMM
      session is deleted, NULL is passed up the call stack.
      
      If active DLCs exist when the rfcomm session is terminating,
      avoid a memory leak of rfcomm_dlc structures by ensuring that
      rfcomm_session_close() is used instead of rfcomm_session_del().
      Signed-off-by: NDean Jenkins <Dean_Jenkins@mentor.com>
      Acked-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      8ff52f7d
    • D
      Bluetooth: change bt_sock_unregister() to return void · be9f97f0
      David Herrmann 提交于
      There is no reason a caller ever wants to check the return type of this
      call. _Iff_ a user successfully called bt_sock_register(), they're allowed
      to call bt_sock_unregister().
      All other calls in the kernel (device_del, device_unregister, kfree(), ..)
      that are logically equivalent return void. Lets not make callers think
      they have to check the return type of this call and instead simply return
      void.
      
      We guarantee that after bt_sock_unregister() is called, the socket type
      _is_ unregistered. If that is not what the caller wants, they're using the
      wrong function, anyway.
      Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
      Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      be9f97f0
    • A
      Bluetooth: Rename hci_acl_disconn · bed71748
      Andre Guedes 提交于
      As hci_acl_disconn function basically sends the HCI Disconnect Command
      and it is used to disconnect ACL, SCO and LE links, renaming it to
      hci_disconnect is more suitable.
      Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
      Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      bed71748
  2. 02 2月, 2013 1 次提交
  3. 23 1月, 2013 4 次提交
  4. 18 1月, 2013 1 次提交
  5. 10 1月, 2013 3 次提交
  6. 04 12月, 2012 4 次提交
  7. 20 11月, 2012 2 次提交
  8. 19 11月, 2012 3 次提交
  9. 02 11月, 2012 11 次提交
  10. 24 10月, 2012 5 次提交
  11. 18 10月, 2012 1 次提交