24 Apr, 2013

1 commit


17 Apr, 2013

2 commits

  • 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: David Herrmann
    Acked-by: Marcel Holtmann
    Signed-off-by: Gustavo Padovan

    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: David Herrmann
    Acked-by: Marcel Holtmann
    Signed-off-by: Gustavo Padovan

    David Herrmann
     

12 Apr, 2013

2 commits

  • This patch removes the status parameter of the l2cap_conn_add function.
    The parameter 'status' is always 0.

    Signed-off-by: Claudio Takahasi
    Signed-off-by: Gustavo Padovan

    Claudio Takahasi
     
  • We use _get() and _put() for device ref-counting in the kernel. However,
    hci_conn_put() is _not_ used for ref-counting, hence, rename it to
    hci_conn_drop() so we can later fix ref-counting and introduce
    hci_conn_put().

    hci_conn_hold() and hci_conn_put() are currently used to manage how long a
    connection should be held alive. When the last user drops the connection,
    we spawn a delayed work that performs the disconnect. Obviously, this has
    nothing to do with ref-counting for the _object_ but rather for the
    keep-alive of the connection.

    But we really _need_ proper ref-counting for the _object_ to allow
    connection-users like rfcomm-tty, HIDP or others.

    Signed-off-by: David Herrmann
    Acked-by: Marcel Holtmann
    Signed-off-by: Gustavo Padovan

    David Herrmann
     

31 Jan, 2013

1 commit


10 Jan, 2013

2 commits

  • 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: Jaganath Kanakkassery
    Signed-off-by: Gustavo Padovan

    Jaganath Kanakkassery
     
  • 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: Andrei Emeltchenko
    Signed-off-by: Gustavo Padovan

    Andrei Emeltchenko
     

04 Dec, 2012

5 commits

  • Make code more readable by changing CONF_NO_FCS_RECV which is read
    as "No L2CAP FCS option received" to CONF_RECV_NO_FCS which means
    "Received L2CAP option NO_FCS". This flag really means that we have
    received L2CAP FRAME CHECK SEQUENCE (FCS) OPTION with value "No FCS".

    Signed-off-by: Andrei Emeltchenko
    Signed-off-by: Gustavo Padovan

    Andrei Emeltchenko
     
  • Process L2CAP Config rsp Pending with FCS Option 0x00 (No FCS)
    which is sent by Motorola Windows 7 Bluetooth stack. The trace
    is shown below (all other options are skipped).

    ...
    < ACL data: handle 1 flags 0x00 dlen 48
    L2CAP(s): Config req: dcid 0x0043 flags 0x00 clen 36
    ...
    FCS Option 0x00 (No FCS)
    > ACL data: handle 1 flags 0x02 dlen 48
    L2CAP(s): Config req: dcid 0x0041 flags 0x00 clen 36
    ...
    FCS Option 0x01 (CRC16 Check)
    < ACL data: handle 1 flags 0x00 dlen 47
    L2CAP(s): Config rsp: scid 0x0043 flags 0x00 result 4 clen 33
    Pending
    ...
    > ACL data: handle 1 flags 0x02 dlen 50
    L2CAP(s): Config rsp: scid 0x0041 flags 0x00 result 4 clen 36
    Pending
    ...
    FCS Option 0x00 (No FCS)
    < ACL data: handle 1 flags 0x00 dlen 14
    L2CAP(s): Config rsp: scid 0x0043 flags 0x00 result 0 clen 0
    Success
    > ACL data: handle 1 flags 0x02 dlen 14
    L2CAP(s): Config rsp: scid 0x0041 flags 0x00 result 0 clen 0
    Success
    ...

    Signed-off-by: Andrei Emeltchenko
    Signed-off-by: Gustavo Padovan

    Andrei Emeltchenko
     
  • If L2CAP_FEAT_FCS is not supported we sould miss EWS option
    configuration because of break. Make code more readable by
    combining FCS configuration in the single block.

    Signed-off-by: Andrei Emeltchenko
    Signed-off-by: Gustavo Padovan

    Andrei Emeltchenko
     
  • Before starting quering remote AMP controllers make sure
    that there is local active AMP controller.

    Signed-off-by: Andrei Emeltchenko
    Signed-off-by: Gustavo Padovan

    Andrei Emeltchenko
     
  • l2cap_send_disconn_req takes 3 parameters of which conn might be
    derived from chan. Make this conversion inside l2cap_send_disconn_req.

    Signed-off-by: Andrei Emeltchenko
    Signed-off-by: Gustavo Padovan

    Andrei Emeltchenko
     

21 Nov, 2012

3 commits

  • When receiving L2CAP Create Channel Request set the channel as
    L2CAP_FCS_NONE. Then in "L2CAP Config req" following field will
    be set: "FCS Option 0x00 (No FCS)". So by default High Speed
    channels have no FCS.

    Signed-off-by: Andrei Emeltchenko
    Signed-off-by: Gustavo Padovan

    Andrei Emeltchenko
     
  • Instead of printing:
    "[ 7763.082007] Bluetooth: 2"
    print something like:
    "[ 7763.082007] Bluetooth: Trailing bytes: 2 in sframe"

    Signed-off-by: Andrei Emeltchenko
    Signed-off-by: Gustavo Padovan

    Andrei Emeltchenko
     
  • When receiving Physical Link Completed event we need to create L2CAP
    channel with L2CAP Create Chan Request. Current code was sending
    this command only if connection was pending (which is probably
    needed in channel move case). If channel is not moved but created
    Create Chan should be sent for outgoing channel which is checked
    with BT_CONNECT flag.

    Signed-off-by: Andrei Emeltchenko
    Acked-by: Marcel Holtmann
    Signed-off-by: Gustavo Padovan

    Andrei Emeltchenko
     

20 Nov, 2012

5 commits


02 Nov, 2012

12 commits


24 Oct, 2012

7 commits

  • Channel moves are triggered by changes to the BT_CHANNEL_POLICY
    sockopt when an ERTM or streaming-mode channel is connected.

    Moves are only started if enable_hs is true.

    Signed-off-by: Mat Martineau
    Acked-by: Marcel Holtmann
    Signed-off-by: Gustavo Padovan

    Mat Martineau
     
  • Do not retransmit previously-sent data when a "receiver ready" s-frame
    with the "final" flag is received during a move.

    The ERTM state machines will resynchronize at the end of a channel
    move, and the state machine needs to avoid state changes during a
    move.

    Signed-off-by: Mat Martineau
    Acked-by: Marcel Holtmann
    Acked-by: Andrei Emeltchenko
    Signed-off-by: Gustavo Padovan

    Mat Martineau
     
  • When operating over BR/EDR, ERTM accounts for the maximum over-the-air
    packet size when setting the PDU size. AMP controllers do not use the
    same over-the-air packets, so the PDU size should only be based on the
    HCI MTU of the AMP controller.

    Signed-off-by: Mat Martineau
    Signed-off-by: Andrei Emeltchenko
    Acked-by: Marcel Holtmann
    Signed-off-by: Gustavo Padovan

    Mat Martineau
     
  • The L2CAP spec recommends specific retransmit and monitor timeouts for
    ERTM channels that are on AMP controllers. These timeouts are
    calculated from the AMP controller's best effort flush timeout.

    BR/EDR controllers use the default retransmit and monitor timeouts.

    Signed-off-by: Mat Martineau
    Acked-by: Marcel Holtmann
    Signed-off-by: Gustavo Padovan

    Mat Martineau
     
  • Outgoing ERTM data is queued during a channel move. The ERTM state
    machine is partially reset at the start of a move, and must be
    resynchronized with the remote state machine at the end of the move.
    Data is not sent so that there are no state transitions between the
    partial reset and the resync.

    Streaming mode frames are dropped during a move.

    Signed-off-by: Mat Martineau
    Acked-by: Marcel Holtmann
    Acked-by: Andrei Emeltchenko
    Signed-off-by: Gustavo Padovan

    Mat Martineau
     
  • AMP controllers expect to transmit only "complete" ACL frames. These
    frames have both the "start" and "cont" bits set. AMP does not allow
    fragmented ACLs.

    Signed-off-by: Mat Martineau
    Acked-by: Marcel Holtmann
    Acked-by: Andrei Emeltchenko
    Signed-off-by: Gustavo Padovan

    Mat Martineau
     
  • Several different actions may be taken when an AMP physical link
    becomes available. A channel being created on an AMP controller must
    continue the connection process. A channel being moved needs to
    either send a move request or a move response. A failed physical link
    will revert to using a BR/EDR controller if possible.

    Signed-off-by: Mat Martineau
    Acked-by: Marcel Holtmann
    Acked-by: Andrei Emeltchenko
    Signed-off-by: Gustavo Padovan

    Mat Martineau