Zephyr API Documentation 4.0.0
A Scalable Open Source RTOS
Loading...
Searching...
No Matches
bt_l2cap_chan_ops Struct Reference

L2CAP Channel operations structure. More...

#include <l2cap.h>

Data Fields

void(* connected )(struct bt_l2cap_chan *chan)
 Channel connected callback.
 
void(* disconnected )(struct bt_l2cap_chan *chan)
 Channel disconnected callback.
 
void(* encrypt_change )(struct bt_l2cap_chan *chan, uint8_t hci_status)
 Channel encrypt_change callback.
 
struct net_buf *(* alloc_seg )(struct bt_l2cap_chan *chan)
 Channel alloc_seg callback.
 
struct net_buf *(* alloc_buf )(struct bt_l2cap_chan *chan)
 Channel alloc_buf callback.
 
int(* recv )(struct bt_l2cap_chan *chan, struct net_buf *buf)
 Channel recv callback.
 
void(* sent )(struct bt_l2cap_chan *chan)
 Channel sent callback.
 
void(* status )(struct bt_l2cap_chan *chan, atomic_t *status)
 Channel status callback.
 
void(* released )(struct bt_l2cap_chan *chan)
 
void(* reconfigured )(struct bt_l2cap_chan *chan)
 Channel reconfigured callback.
 
void(* seg_recv )(struct bt_l2cap_chan *chan, size_t sdu_len, off_t seg_offset, struct net_buf_simple *seg)
 Handle L2CAP segments directly.
 

Detailed Description

L2CAP Channel operations structure.

The object has to stay valid and constant for the lifetime of the channel.

Field Documentation

◆ alloc_buf

struct net_buf *(* bt_l2cap_chan_ops::alloc_buf) (struct bt_l2cap_chan *chan)

Channel alloc_buf callback.

If this callback is provided the channel will use it to allocate buffers to store incoming data. Channels that requires segmentation must set this callback. If the application has not set a callback the L2CAP SDU MTU will be truncated to BT_L2CAP_SDU_RX_MTU.

Parameters
chanThe channel requesting a buffer.
Returns
Allocated buffer.

◆ alloc_seg

struct net_buf *(* bt_l2cap_chan_ops::alloc_seg) (struct bt_l2cap_chan *chan)

Channel alloc_seg callback.

If this callback is provided the channel will use it to allocate buffers to store segments. This avoids wasting big SDU buffers with potentially much smaller PDUs. If this callback is supplied, it must return a valid buffer.

Parameters
chanThe channel requesting a buffer.
Returns
Allocated buffer.

◆ connected

void(* bt_l2cap_chan_ops::connected) (struct bt_l2cap_chan *chan)

Channel connected callback.

If this callback is provided it will be called whenever the connection completes.

Parameters
chanThe channel that has been connected

◆ disconnected

void(* bt_l2cap_chan_ops::disconnected) (struct bt_l2cap_chan *chan)

Channel disconnected callback.

If this callback is provided it will be called whenever the channel is disconnected, including when a connection gets rejected.

Parameters
chanThe channel that has been Disconnected

◆ encrypt_change

void(* bt_l2cap_chan_ops::encrypt_change) (struct bt_l2cap_chan *chan, uint8_t hci_status)

Channel encrypt_change callback.

If this callback is provided it will be called whenever the security level changed (indirectly link encryption done) or authentication procedure fails. In both cases security initiator and responder got the final status (HCI status) passed by related to encryption and authentication events from local host's controller.

Parameters
chanThe channel which has made encryption status changed.
statusHCI status of performed security procedure caused by channel security requirements. The value is populated by HCI layer and set to 0 when success and to non-zero (reference to HCI Error Codes) when security/authentication failed.

◆ reconfigured

void(* bt_l2cap_chan_ops::reconfigured) (struct bt_l2cap_chan *chan)

Channel reconfigured callback.

If this callback is provided it will be called whenever peer or local device requested reconfiguration. Application may check updated MTU and MPS values by inspecting chan->le endpoints.

Parameters
chanThe channel which was reconfigured

◆ recv

int(* bt_l2cap_chan_ops::recv) (struct bt_l2cap_chan *chan, struct net_buf *buf)

Channel recv callback.

Parameters
chanThe channel receiving data.
bufBuffer containing incoming data.
Note
This callback is mandatory, unless
CONFIG_BT_L2CAP_SEG_RECV 
is enabled and seg_recv is supplied.

If the application returns -EINPROGRESS, the application takes ownership of the reference in buf. (I.e. This pointer value can simply be given to bt_l2cap_chan_recv_complete without any calls net_buf_ref or net_buf_unref.)

Returns
0 in case of success or negative value in case of error.
-EINPROGRESS in case where user has to confirm once the data has been processed by calling bt_l2cap_chan_recv_complete passing back the buffer received with its original user_data which contains the number of segments/credits used by the packet.

◆ released

void(* bt_l2cap_chan_ops::released) (struct bt_l2cap_chan *chan)

◆ seg_recv

void(* bt_l2cap_chan_ops::seg_recv) (struct bt_l2cap_chan *chan, size_t sdu_len, off_t seg_offset, struct net_buf_simple *seg)

Handle L2CAP segments directly.

This is an alternative to bt_l2cap_chan_ops::recv. They cannot be used together.

This is called immediately for each received segment.

Unlike with bt_l2cap_chan_ops::recv, flow control is explicit. Each time this handler is invoked, the remote has permanently used up one credit. Use bt_l2cap_chan_give_credits to give credits.

The start of an SDU is marked by seg_offset == 0. The end of an SDU is marked by seg_offset + seg->len == sdu_len.

The stack guarantees that:

  • The sender had the credit.
  • The SDU length does not exceed MTU.
  • The segment length does not exceed MPS.

Additionally, the L2CAP protocol is such that:

  • Segments come in order.
  • SDUs cannot be interleaved or aborted halfway.
Note
With this alternative API, the application is responsible for setting the RX MTU and MPS. The MPS must not exceed BT_L2CAP_RX_MTU.
Parameters
chanThe receiving channel.
sdu_lenByte length of the SDU this segment is part of.
seg_offsetThe byte offset of this segment in the SDU.
segThe segment payload.

◆ sent

void(* bt_l2cap_chan_ops::sent) (struct bt_l2cap_chan *chan)

Channel sent callback.

This callback will be called once the controller marks the SDU as completed. When the controller does so is implementation dependent. It could be after the SDU is enqueued for transmission, or after it is sent on air.

Parameters
chanThe channel which has sent data.

◆ status

void(* bt_l2cap_chan_ops::status) (struct bt_l2cap_chan *chan, atomic_t *status)

Channel status callback.

If this callback is provided it will be called whenever the channel status changes.

Parameters
chanThe channel which status changed
statusThe channel status

The documentation for this struct was generated from the following file: