Files including <zephyr/kernel.h> do not have to include
<zephyr/zephyr.h>, a shim to <zephyr/kernel.h>.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
This driver uses stack buffers to hold AT command strings which are
generated at runtime using sprintk. The buffers are only sized for the
expected range of values, not the full possible range given the datatypes
involved. Values outside this expected range could cause a buffer overflow.
To mitigate this, increase the size of each buffer to hold the full range
of each parameter type.
Signed-off-by: Keith Packard <keithp@keithp.com>
`esp_close_work` can be queued from the `on_cmd_closed`, which clears
`ESP_SOCK_CONNECTED` and sets `ESP_SOCK_CLOSE_PENDING`, but does no
further work. The receive callback should still be run with no data when
the socket is closed through this mechanism.
Signed-off-by: Jordan Yates <jordan.yates@data61.csiro.au>
Use the proper `%p` printf specifier when printing memory addresses,
instead of casting to an integer, which may not be the same size as a
pointer.
Signed-off-by: Jordan Yates <jordan.yates@data61.csiro.au>
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>
This is more or less the flow of AT+CIPSEND:
RX TX
-- --
AT+CIPSEND=<...>
OK
>
<data to be sent>
SEND OK / SEND FAIL
'sem_response' semaphore is released by receiving 'OK'. Then after
receiving '>' (which releases 'sem_tx_ready' semaphore) actual data is
sent. Waiting for 'SEND OK' or 'SEND FAIL' is implemented by waiting on
'sem_response' (the same as for 'OK'), which mean that resetting this
semaphore just after sending all data is racy.
Fix that race condition by resetting 'sem_response' just after receiving
'OK', so that neither 'SEND OK' nor 'SEND FAIL' will appear yet (they
will not be sent as long as we won't send whole payload).
Signed-off-by: Marcin Niestroj <m.niestroj@grinn-global.com>
Sending AT+CIPSEND=<...> command results in following reply:
OK
>
modem_cmd_send_nolock() invocation was setting command handlers for '>',
but as 'OK' was received first, it was handled as a generic reply. After
receiving 'OK' this function was unsetting command handlers. Then
modem_cmd_handler_update_cmds() was called once again in order to
register '>' handler once again. There was a small period of time where
'>' was not being handled at all.
Fix that race condition by using just introduced modem_cmd_send_ext(),
which allows to leave commands handlers in place and get rid of race
condition where expected command could be missed.
Signed-off-by: Marcin Niestroj <m.niestroj@grinn-global.com>
If stream socket is marked as pending close, make sure that send()
caller gets notified about it, so that application layer can decide to
stop trying to send anything more.
Signed-off-by: Marcin Niestroj <m.niestroj@grinn-global.com>
So far send errors were silently ignored. This is okay for
UDP (datagram) sockets, as there is no guarantee that packets will
actually be sent successfully. In case of TCP (stream) stream sockets
however, application layer expects network stack to send requested data
as stream, without losing any part of it.
In case of send errors on stream sockets mark that socket to be closed
and stop sending any subsequent network packets, so that data stream
won't have any holes.
Signed-off-by: Marcin Niestroj <m.niestroj@grinn-global.com>
Usage of k_work object from within net_pkt results in undefined behavior
in case when net_pkt is deallocated (by net_pkt_unref()) before work has
been finished.
Use per socket k_work object (sock->send_work) to submit send work and
put net_pkt objects onto k_fifo (sock->tx_fifo). Add a helper function
esp_socket_queue_tx() for that, which will make sure that packets are
enqueued only when send work handler will be successfully submitted (so
that all packets are consumed/dereferenced).
Signed-off-by: Marcin Niestroj <m.niestroj@grinn-global.com>
Recently WiFi ESP32 driver (utilizing WiFi radio in ESP32 SoC) was
introduced into drivers/wifi/esp32/ and it already caused confusion as
there was existing drivers/wifi/esp/ directory for ESP-AT
driver (utilizing external WiFi chip, by communicating using AT commands
from any serial capable platform). So question has arisen whether it is
good to merge both, while they are totally different drivers.
Rename ESP-AT driver to be placed in drivers/wifi/esp_at/, so that it is
easier to figure out difference between "esp32" and "esp_at" just by
looking at driver name. Rename also DT compatible and all Kconfig
options for the same reason.
Signed-off-by: Marcin Niestroj <m.niestroj@grinn-global.com>
2021-05-06 13:21:39 -04:00
Renamed from drivers/wifi/esp/esp_offload.c (Browse further)
