1. 17 4月, 2013 2 次提交
    • D
      Bluetooth: l2cap: add l2cap_user sub-modules · 2c8e1411
      David Herrmann 提交于
      Several sub-modules like HIDP, rfcomm, ... need to track l2cap
      connections. The l2cap_conn->hcon->dev object is used as parent for sysfs
      devices so the sub-modules need to be notified when the hci_conn object is
      removed from sysfs.
      
      As submodules normally use the l2cap layer, the l2cap_user objects are
      registered there instead of on the underlying hci_conn object. This avoids
      any direct dependency on the HCI layer and lets the l2cap core handle any
      specifics.
      
      This patch introduces l2cap_user objects which contain a "probe" and
      "remove" callback. You can register them on any l2cap_conn object and if
      it is active, the "probe" callback will get called. Otherwise, an error is
      returned.
      
      The l2cap_conn object will call your "remove" callback directly before it
      is removed from user-space. This allows you to remove your submodules
      _before_ the parent l2cap_conn and hci_conn object is removed.
      
      At any time you can asynchronously unregister your l2cap_user object if
      your submodule vanishes before the l2cap_conn object does.
      
      There is no way around l2cap_user. If we want wire-protocols in the
      kernel, we always want the hci_conn object as parent in the sysfs tree. We
      cannot use a channel here since we might need multiple channels for a
      single protocol.
      But the problem is, we _must_ get notified when an l2cap_conn object is
      removed. We cannot use reference-counting for object-removal! This is not
      how it works. If a hardware is removed, we should immediately remove the
      object from sysfs. Any other behavior would be inconsistent with the rest
      of the system. Also note that device_del() might sleep, but it doesn't
      wait for user-space or block very long. It only _unlinks_ the object from
      sysfs and the whole device-tree. Everything else is handled by ref-counts!
      This is exactly what the other sub-modules must do: unlink their devices
      when the "remove" l2cap_user callback is called. They should not do any
      cleanup or synchronous shutdowns.
      Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
      Acked-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      2c8e1411
    • D
      Bluetooth: l2cap: introduce l2cap_conn ref-counting · 9c903e37
      David Herrmann 提交于
      If we want to use l2cap_conn outside of l2cap_core.c, we need refcounting
      for these objects. Otherwise, we cannot synchronize l2cap locks with
      outside locks and end up with deadlocks.
      
      Hence, introduce ref-counting for l2cap_conn objects. This doesn't affect
      l2cap internals at all, as they use a direct synchronization.
      We also keep a reference to the parent hci_conn for locking purposes as
      l2cap_conn depends on this. This doesn't affect the connection itself but
      only the lifetime of the (dead) object.
      Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
      Acked-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      9c903e37
  2. 12 4月, 2013 2 次提交
  3. 10 1月, 2013 2 次提交
    • J
      Bluetooth: Fix authentication if acl data comes before remote feature evt · 7b064eda
      Jaganath Kanakkassery 提交于
      If remote device sends l2cap info request before read_remote_ext_feature
      completes then mgmt_connected will be sent in hci_acldata_packet() and
      remote name request wont be sent and eventually authentication wont happen
      
      Hcidump log of the issue
      
      < HCI Command: Create Connection (0x01|0x0005) plen 13
          bdaddr BC:85:1F:74:7F:29 ptype 0xcc18 rswitch 0x01 clkoffset 0x4bf7 (valid)
          Packet type: DM1 DM3 DM5 DH1 DH3 DH5
      > HCI Event: Command Status (0x0f) plen 4
          Create Connection (0x01|0x0005) status 0x00 ncmd 1
      > HCI Event: Connect Complete (0x03) plen 11
          status 0x00 handle 12 bdaddr BC:85:1F:74:7F:29 type ACL encrypt 0x00
      < HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2
          handle 12
      > HCI Event: Command Status (0x0f) plen 4
          Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 1
      > HCI Event: Read Remote Supported Features (0x0b) plen 11
          status 0x00 handle 12
          Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87
      > HCI Event: Max Slots Change (0x1b) plen 3
          handle 12 slots 5
      < HCI Command: Read Remote Extended Features (0x01|0x001c) plen 3
          handle 12 page 1
      > HCI Event: Command Status (0x0f) plen 4
          Read Remote Extended Features (0x01|0x001c) status 0x00 ncmd 1
      > ACL data: handle 12 flags 0x02 dlen 10
          L2CAP(s): Info req: type 2
      < ACL data: handle 12 flags 0x00 dlen 16
          L2CAP(s): Info rsp: type 2 result 0
            Extended feature mask 0x00b8
              Enhanced Retransmission mode
              Streaming mode
              FCS Option
              Fixed Channels
      > HCI Event: Read Remote Extended Features (0x23) plen 13
          status 0x00 handle 12 page 1 max 1
          Features: 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
      > ACL data: handle 12 flags 0x02 dlen 10
          L2CAP(s): Info req: type 3
      < ACL data: handle 12 flags 0x00 dlen 20
          L2CAP(s): Info rsp: type 3 result 0
            Fixed channel list 0x00000002
              L2CAP Signalling Channel
      > HCI Event: Number of Completed Packets (0x13) plen 5
          handle 12 packets 2
      
      This patch moves sending mgmt_connected from hci_acldata_packet() to
      l2cap_connect_req() since this code is to handle the scenario remote
      device sends l2cap connect req too fast
      Signed-off-by: NJaganath Kanakkassery <jaganath.k@samsung.com>
      Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      7b064eda
    • A
      Bluetooth: AMP: Remove dead code · cbf54ad1
      Andrei Emeltchenko 提交于
      Remove code which cannot execute. l2cap_conn_add for AMP_LINK
      might only be invoked when receiving data in l2cap_recv_acldata.
      But this case is checked in the first statement there.
      Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com>
      Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      cbf54ad1
  4. 04 12月, 2012 5 次提交
  5. 21 11月, 2012 3 次提交
  6. 20 11月, 2012 5 次提交
  7. 02 11月, 2012 12 次提交
  8. 24 10月, 2012 9 次提交