Let's hide the internals of sock->packet_sizes[] by adding a function
which returns the size of the next waiting packet.
Signed-off-by: Michael Scott <mike@foundries.io>
Let's hide the internals of the modem_socket's sem_data_ready and
poll handling with 2 new functions:
- modem_socket_wait_data: take a semaphore and wait for data
- modem_socket_data_ready: give back the data ready semaphore and
unblock poll() users
Signed-off-by: Michael Scott <mike@foundries.io>
Add lock behavior for functions in modem_socket, to prevent race
conditions when performing socket data maintenance.
Signed-off-by: Michael Scott <mike@foundries.io>
Many modems implement socket-based APIs to manage data connections.
This layer provides much of the groundwork for keeping track of
these "sockets" throughout their lifecycle (from the initial offload
API calls through the command handler call back layers):
- structure for holding socket data like IP protocol, destination,
source and incoming packet sizes
- configuration to note modem starting socket id and number of
sockets
- methods to get/put socket structs from/to the pool
- function to update the # and size of packets in the modem receive
queue
- prebuilt modem_socket_poll() method for socket offload poll() API
Example modem driver setup code looks like this:
/* socket data */
static struct modem_socket_config socket_config;
static struct modem_socket sockets[MDM_MAX_SOCKETS];
static int modem_init(struct device *dev)
{
...
/* setup socket config */
socket_config.sockets = &sockets[0];
socket_config.sockets_len = ARRAY_SIZE(sockets);
socket_config.base_socket_num = 0;
ret = modem_socket_init(&socket_config);
...
}
Signed-off-by: Michael Scott <mike@foundries.io>
Michael Scott