patrick/zephyr
1
0
Fork 0
Code Issues Pull requests Actions 7 Packages Projects Releases Wiki Activity
zephyr/drivers/modem/modem_socket.h

92 lines
2.7 KiB
C
Raw Normal View History

drivers: modem: introduce socket helper layer 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>
2019-08-07 17:04:00 +02:00
/** @file
* @brief Modem socket header file.
*
* Generic modem socket and packet size implementation for modem context
*/
/*
drivers: modem: socket: introduce locking 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>
2020-01-27 21:59:33 +01:00
* Copyright (c) 2019-2020 Foundries.io
drivers: modem: introduce socket helper layer 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>
2019-08-07 17:04:00 +02:00
*
* SPDX-License-Identifier: Apache-2.0
*/
#ifndef ZEPHYR_INCLUDE_DRIVERS_MODEM_MODEM_SOCKET_H_
#define ZEPHYR_INCLUDE_DRIVERS_MODEM_MODEM_SOCKET_H_
drivers: migrate includes to <zephyr/...> In order to bring consistency in-tree, migrate all drivers to the new prefix <zephyr/...>. Note that the conversion has been scripted, refer to #45388 for more details. Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
2022-05-06 10:25:46 +02:00
#include <zephyr/kernel.h>
#include <zephyr/net/net_ip.h>
#include <zephyr/net/socket.h>
drivers: modem: ublox-sara-r4: Rework offloading mechanism Switch to `NET_SOCKET_REGISTER` mechanism over the offloaded API registration. Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
2019-12-04 10:04:07 +01:00
#include "sockets_internal.h"
drivers: modem: introduce socket helper layer 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>
2019-08-07 17:04:00 +02:00
#ifdef __cplusplus
extern "C" {
#endif
net: tag net socket objects Used for permission validation when accessing the associated file descriptors from user mode. There often get defined in implementation code, expand the search to look in drivers/ and subsys/net/. Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2020-05-29 22:33:12 +02:00
__net_socket struct modem_socket {
drivers: modem: introduce socket helper layer 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>
2019-08-07 17:04:00 +02:00
sa_family_t family;
enum net_sock_type type;
drivers: modem: ublox-sara-r4: add TLS offload support Currently it's able to connect to google iot. All other use cases are untested. Signed-off-by: Johann Tael <jntael@gmail.com>
2021-03-31 09:33:34 +02:00
int ip_proto;
drivers: modem: introduce socket helper layer 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>
2019-08-07 17:04:00 +02:00
struct sockaddr src;
struct sockaddr dst;
drivers/modem: Patch fix for sock id and fd There is is an error in the way that the sock id is determined. A unique fd is reserved and assigned appropriatly, but the id, which should correspond to a socket number within the modem, is set to an invalid, and identical for all sockets, value, and then not used appropriatly in the drivers, instead, the sock_fd is used, which can be any value really, it is not related to the socket number in any way. This results in the drivers only working if the reserved fd happens to be between base_socket_num and (socket_len - 1) This patch assignes the id to the index of the socket + the base_socket_num, the socket at index 0 will get the id 1 if the base_socket_num is 1, and the modem_socket_from_id should then be used to get a pointer to the socket, since the id is not neccesarily equal to the index. The FIXME has been solved by adding a note both at the start of the modem_socket_get function and inside the Kconfig file for the MODEM_SOCKET option description. It is not an error, but the user must be aware that it uses the POSIX file descriptors, for which only 4 are allocated by default. This patch fixes the bug, without breaking the brittle modem drivers which currently are built around this bug. The modem drivers should be updated to use the id as the socket num instead of the sock_fd after this fix has been merged. The "socket # needs assigning" has been removed, as that is what this patch is doing I also added comments to the id and sock_fd in the modem_socket structure to help developers use the id and fd appropriately. Signed-off-by: Bjarki Arge Andreasen <bjarkix123@gmail.com>
2022-07-08 21:28:07 +02:00
/** The number identifying the socket handle inside the modem */
drivers: modem: introduce socket helper layer 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>
2019-08-07 17:04:00 +02:00
int id;
drivers/modem: Patch fix for sock id and fd There is is an error in the way that the sock id is determined. A unique fd is reserved and assigned appropriatly, but the id, which should correspond to a socket number within the modem, is set to an invalid, and identical for all sockets, value, and then not used appropriatly in the drivers, instead, the sock_fd is used, which can be any value really, it is not related to the socket number in any way. This results in the drivers only working if the reserved fd happens to be between base_socket_num and (socket_len - 1) This patch assignes the id to the index of the socket + the base_socket_num, the socket at index 0 will get the id 1 if the base_socket_num is 1, and the modem_socket_from_id should then be used to get a pointer to the socket, since the id is not neccesarily equal to the index. The FIXME has been solved by adding a note both at the start of the modem_socket_get function and inside the Kconfig file for the MODEM_SOCKET option description. It is not an error, but the user must be aware that it uses the POSIX file descriptors, for which only 4 are allocated by default. This patch fixes the bug, without breaking the brittle modem drivers which currently are built around this bug. The modem drivers should be updated to use the id as the socket num instead of the sock_fd after this fix has been merged. The "socket # needs assigning" has been removed, as that is what this patch is doing I also added comments to the id and sock_fd in the modem_socket structure to help developers use the id and fd appropriately. Signed-off-by: Bjarki Arge Andreasen <bjarkix123@gmail.com>
2022-07-08 21:28:07 +02:00
/** The file descriptor identifying the socket in the fdtable */
drivers: modem: introduce socket helper layer 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>
2019-08-07 17:04:00 +02:00
int sock_fd;
/** packet data */
zephyr: replace zephyr integer types with C99 types git grep -l 'u\(8\|16\|32\|64\)_t' | \ xargs sed -i "s/u\(8\|16\|32\|64\)_t/uint\1_t/g" git grep -l 's\(8\|16\|32\|64\)_t' | \ xargs sed -i "s/s\(8\|16\|32\|64\)_t/int\1_t/g" Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
2020-05-27 18:26:57 +02:00
uint16_t packet_sizes[CONFIG_MODEM_SOCKET_PACKET_COUNT];
uint16_t packet_count;
drivers: modem: introduce socket helper layer 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>
2019-08-07 17:04:00 +02:00
/** data ready semaphore */
struct k_sem sem_data_ready;
modem: Rework the modem_sockets poll behavior The current modem sockets poll implementation has 2 limitations as of today: - not following posix spec wrt timeout of -1 (should be forever, but as today it's was returning immediately) - not able to poll from multiple threads on different sockets on the same modem. This pull request should implement these limitations. Signed-off-by: Wouter Cappelle <wouter.cappelle@crodeon.com>
2021-10-15 09:28:44 +02:00
/** data ready poll signal */
modem: Update modem sockets poll to allow eventfd The modem sockets poll implementation does not allow a combination of poll on modem sockets and on other sockets like eventfd. This blocks trivial application signalling. Current users are using a poll timeout, which needs to check if other work needs to be done in the thread (eg: lwm2m engine). To allow proper signalling with eventfd, the non offload poll methods needs to work for the modem sockets. This commit is implementing this for POLLIN. Signed-off-by: Wouter Cappelle <wouter.cappelle@crodeon.com>
2021-10-21 11:18:17 +02:00
struct k_poll_signal sig_data_ready;
drivers: modem: introduce socket helper layer 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>
2019-08-07 17:04:00 +02:00
/** socket state */
drivers: modem: socket: add is_connected field to modem_socket Let's add a field which the drivers can use to keep track of whether they are connected or not. This will normally be enabled / disabled in the socket connect and URC for socket close notify. Signed-off-by: Michael Scott <mike@foundries.io>
2020-01-27 22:14:49 +01:00
bool is_connected;
drivers: modem: socket: add wait_data and data_ready functions 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>
2020-01-27 21:52:56 +01:00
bool is_waiting;
drivers: modem: introduce socket helper layer 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>
2019-08-07 17:04:00 +02:00
/** temporary socket data */
void *data;
};
struct modem_socket_config {
struct modem_socket *sockets;
size_t sockets_len;
/* beginning socket id (modems can set this to 0 or 1 as needed) */
int base_socket_num;
drivers: modem: socket: introduce locking 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>
2020-01-27 21:59:33 +01:00
struct k_sem sem_lock;
drivers: modem: ublox-sara-r4: Rework offloading mechanism Switch to `NET_SOCKET_REGISTER` mechanism over the offloaded API registration. Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
2019-12-04 10:04:07 +01:00
const struct socket_op_vtable *vtable;
drivers: modem: introduce socket helper layer 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>
2019-08-07 17:04:00 +02:00
};
drivers: modem: socket: add modem_socket_next_packet_size 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>
2020-01-27 22:13:01 +01:00
/* return size of the first packet */
modem: clang-format the modem_socket files Running clang-format on the modem socket files Signed-off-by: Wouter Cappelle <wouter.cappelle@crodeon.com>
2021-10-19 09:24:12 +02:00
uint16_t modem_socket_next_packet_size(struct modem_socket_config *cfg, struct modem_socket *sock);
int modem_socket_packet_size_update(struct modem_socket_config *cfg, struct modem_socket *sock,
int new_total);
int modem_socket_get(struct modem_socket_config *cfg, int family, int type, int proto);
struct modem_socket *modem_socket_from_fd(struct modem_socket_config *cfg, int sock_fd);
struct modem_socket *modem_socket_from_id(struct modem_socket_config *cfg, int id);
drivers: modem: introduce socket helper layer 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>
2019-08-07 17:04:00 +02:00
struct modem_socket *modem_socket_from_newid(struct modem_socket_config *cfg);
void modem_socket_put(struct modem_socket_config *cfg, int sock_fd);
modem: clang-format the modem_socket files Running clang-format on the modem socket files Signed-off-by: Wouter Cappelle <wouter.cappelle@crodeon.com>
2021-10-19 09:24:12 +02:00
int modem_socket_poll(struct modem_socket_config *cfg, struct zsock_pollfd *fds, int nfds,
int msecs);
modem: Update modem sockets poll to allow eventfd The modem sockets poll implementation does not allow a combination of poll on modem sockets and on other sockets like eventfd. This blocks trivial application signalling. Current users are using a poll timeout, which needs to check if other work needs to be done in the thread (eg: lwm2m engine). To allow proper signalling with eventfd, the non offload poll methods needs to work for the modem sockets. This commit is implementing this for POLLIN. Signed-off-by: Wouter Cappelle <wouter.cappelle@crodeon.com>
2021-10-21 11:18:17 +02:00
int modem_socket_poll_update(struct modem_socket *sock, struct zsock_pollfd *pfd,
struct k_poll_event **pev);
int modem_socket_poll_prepare(struct modem_socket_config *cfg, struct modem_socket *sock,
struct zsock_pollfd *pfd, struct k_poll_event **pev,
struct k_poll_event *pev_end);
modem: clang-format the modem_socket files Running clang-format on the modem socket files Signed-off-by: Wouter Cappelle <wouter.cappelle@crodeon.com>
2021-10-19 09:24:12 +02:00
void modem_socket_wait_data(struct modem_socket_config *cfg, struct modem_socket *sock);
void modem_socket_data_ready(struct modem_socket_config *cfg, struct modem_socket *sock);
int modem_socket_init(struct modem_socket_config *cfg, const struct socket_op_vtable *vtable);
drivers: modem: introduce socket helper layer 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>
2019-08-07 17:04:00 +02:00
#ifdef __cplusplus
}
#endif
#endif /* ZEPHYR_INCLUDE_DRIVERS_MODEM_MODEM_SOCKET_H_ */
Reference in a new issue Copy permalink