Renamed LWM2M_RD_CLIENT_EVENT_REG_UPDATE_FAILURE to
LWM2M_RD_CLIENT_EVENT_REG_TIMEOUT.
Changed reported event type for registration timeout to
LWM2M_RD_CLIENT_EVENT_REG_TIMEOUT from
LWM2M_RD_CLIENT_EVENT_REGISTRATION_FAILURE.
LWM2M_RD_CLIENT_EVENT_REGISTRATION_FAILURE should be only
reported case when server reject by response registration.
Signed-off-by: Juha Heiskanen <juha.heiskanen@nordicsemi.no>
The .yaml file states that CAN is supported, but the basic sample
application samples/drivers/can/counter cannot be compiled without
additional configuration.
The loopback driver does not require any additional steps like the
linux SocketCAN driver, so it is safe to enable it by default and
get rid of the many overlay files in the tests.
ISO-TP tests and the counter sample are excluded via .yaml from
twister tests because of timing issues.
Signed-off-by: Martin Jäger <martin@libre.solar>
This commit replaces the outdated link to the Tridonic net4more Border
Router product page, which now reports 404, with a link to its
datasheet (it seems like this product is no longer available).
Signed-off-by: Stephanos Ioannidis <stephanos.ioannidis@nordicsemi.no>
Up until now, the Zephyr CAN controller drivers set a default bitrate (or
timing) specified via devicetree and start the CAN controller in their
respective driver initialization functions.
This is fine for CAN nodes using only one fixed bitrate, but if the bitrate
is set by the user (e.g. via a DIP-switch or other HMI which is very
common), the CAN driver will still initialise with the default
bitrate/timing at boot and use this until the application has determined
the requested bitrate/timing and set it using
can_set_bitrate()/can_set_timing().
During this period, the CAN node will potentially destroy valid CAN frames
on the CAN bus (which is using the soon-to-be-set-by-the-application
bitrate) by sending error frames. This causes interruptions to the ongoing
CAN bus traffic when a Zephyr-based CAN node connected to the bus is
(re-)booted.
Instead, require all configuration (setting bitrate, timing, or mode) to
take place when the CAN controller is stopped. This maps nicely to entering
"reset mode" (called "configuration mode" or "freeze mode" for some CAN
controller implementations) when stopping and exiting this mode when
starting the CAN controller.
Fixes: #45304
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
If a L2 link has been established, then the DHCP is taking too long as
it has to go through its capped exponential backoff timers to trigger
discover (The DHCP starts immediately during init, this is itself wrong,
it should start on a link UP notification) that delays the DHCP for
few seconds to a minute.
And if we do stop and start DHCP then also it goes through the initial
delays (though configurable), which is also not ideal.
Add support for restarting DHCP without any delay, i.e., release and
send discover immediately.
This is also useful in case L2 switches to a different subnet, in this
case Zephyr doesn't restart DHCP automatically, this API can be used by
L2 apps/drivers to restart DHCP to get new subnet IP.
Signed-off-by: Krishna T <krishna.t@nordicsemi.no>
Moved all MBEDTLS dependencies from prj.conf
to Kconfig as WiFi depends on it.
Update esp32 wifi driver to enable `samples/net/wifi`
to work. Commands as such as `wifi connect` and `wifi scan` are now
available.
Signed-off-by: Sylvio Alves <sylvio.alves@espressif.com>
As of today <zephyr/zephyr.h> is 100% equivalent to <zephyr/kernel.h>.
This patch proposes to then include <zephyr/kernel.h> instead of
<zephyr/zephyr.h> since it is more clear that you are including the
Kernel APIs and (probably) nothing else. <zephyr/zephyr.h> sounds like a
catch-all header that may be confusing. Most applications need to
include a bunch of other things to compile, e.g. driver headers or
subsystem headers like BT, logging, etc.
The idea of a catch-all header in Zephyr is probably not feasible
anyway. Reason is that Zephyr is not a library, like it could be for
example `libpython`. Zephyr provides many utilities nowadays: a kernel,
drivers, subsystems, etc and things will likely grow. A catch-all header
would be massive, difficult to keep up-to-date. It is also likely that
an application will only build a small subset. Note that subsystem-level
headers may use a catch-all approach to make things easier, though.
NOTE: This patch is **NOT** removing the header, just removing its usage
in-tree. I'd advocate for its deprecation (add a #warning on it), but I
understand many people will have concerns.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
This header is also needed for struct can_filter, so it should not
only be included if one wants to set the device into loopback mode.
Signed-off-by: Martin Jäger <martin@libre.solar>
Now that Wifi drivers are enabled based on devicetree we can
remove any cases of them getting enabled by *.conf files.
Signed-off-by: Kumar Gala <galak@kernel.org>
Zephyr IEEE 802.15.4 drivers and L2 stack use the same constant names
for different MTU definitions. The intent of this change is to introduce
a consistent MTU definition which can be used everywhere in zephyr to
avoid confusion, bugs and name conflict.
Signed-off-by: Florian Grandel <jerico.dev@gmail.com>
Many device pointers are initialized at compile and never changed. This
means that the device pointer can be constified (immutable).
Automated using:
```
perl -i -pe 's/const struct device \*(?!const)(.*)= DEVICE/const struct
device *const $1= DEVICE/g' **/*.c
```
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Decouple the zephyr/net/socketcan.h and zephyr/drivers/can.h header files
by moving the SocketCAN utilities to their own header.
This is preparation for including the SocketCAN types defined in
socketcan.h in a native posix (Linux) SocketCAN driver context without name
clashes.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Rename the SocketCAN header from socket_can.h to socketcan.h to better
match the naming of the functionality.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Rename the SocketCAN utility functions to reflect the new naming of the CAN
controller API and SocketCAN API data types.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Remove the "z" prefix from the public CAN controller API types as this
makes them appear as internal APIs.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Rename the SocketCAN data types to "socketcan_*" in preparation of renaming
the low-level CAN controller API data types.
This breaks the naming compatibility with the similar SocketCAN data types
from the Linux kernel, but Zephyr and Linux SocketCAN are not 100%
compatible anyways (only the structure fields are compatible, extended
functionality such filtering, error reporting etc. are not).
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
So far LOG_DBG() was used inside debug hook for mbedTLS library. This meant
that it was hard to distinct log messages by simply looking at the log
level number, even though Zephyr logging subsystem supports colorful logs
depending on log level.
Choose an appropriate Zephyr LOG_*() macro based on log level coming from
mbedTLS library. Remove log level number from formatted log messages, as it
is now redundant.
One controversial thing about this change is that mbedTLS' "2 State change"
log level is mapped to Zephyr's "warning" log level. Those are not really
warnings in real life, but rather informational messages. However, using
"warning" log level for those allows to clearly distinguish between "2
State change" and "3 Informational" debug messages from mbedTLS.
Additionally, mbedTLS debug message implementation does not seem to be safe
to use in production, so keeping in mind MBEDTLS_DEBUG will be enabled just
during debugging phase, printing "2 State change" logs as warnings should
not be a big deal.
Set default MBEDTLS_DEBUG_LEVEL value depending on selected Zephyr logging
module level, so that only single option needs to be configured in
application project.
Remove prompt for MBEDTLS_DEBUG_LEVEL, so that interactively (e.g. via
menuconfig) adjusting MBEDTLS_LOG_LEVEL will always result in automatically
updating MBEDTLS_DEBUG_LEVEL option. This is to prevent so called "stuck
symbol syndrome".
Signed-off-by: Marcin Niestroj <m.niestroj@emb.dev>
Now that ethernet drivers are enabled based on devicetree we can
remove any cases of them getting enabled by proj.conf files.
Signed-off-by: Kumar Gala <galak@kernel.org>
Remove NET_CONFIG_IEEE802154_DEV_NAME in favor of DT based choice using
zephyr,ieee802154.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Remove usage of CONFIG_NET_CONFIG_IEEE802154_DEV_NAME as it now works
with DT based choice.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Remove Kconfig choice for IEEE802154. In this case, there's no in-tree
board, so there's no overlay or board to be updated.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Use the choisen zephyr,ieee802154 from DT as
CONFIG_NET_CONFIG_IEEE802154_DEV_NAME is being phased out.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Use the choisen zephyr,ieee802154 from DT as
CONFIG_NET_CONFIG_IEEE802154_DEV_NAME is being phased out.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Make a library out of the zperf shell sample. This makes to enable the
module in any application, not only the dedicated sample.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
RT1050 and RT1060 were selecting an invalid number of RX/TX buffers
(below the allowed default). Raise this value for the gptp sample.
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
enable hardware acceleration of ethernet checksum calculation for
RT1050 and RT1060
Performance change (as tested with iperf on RT1050)
TCP RX: 50.6Mbps->52.4Mbps
TCP TX: 49.5Mbps->50.2Mbps
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
Use systick timer for RT1050 to provide better performance than low
frequency GPT timer
Performance change (as tested with iperf on RT1050)
TCP RX: 49.1Mbps->50.8Mbps
TCP TX: 40.8Mbps->46.2Mbps
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
All IEEE 802.15.4 drivers are now automatically enabled if they are
'okay' in DT and all of its dependencies are 'y', including
CONFIG_IEEE802154. This means individual driver enablement is not
necessary anymore in Kconfig.defconfig files or samples/tests. Boards
need to still make sure any dependencies are enabled, e.g. SPI bus in
some cases.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Use Devicetree to describe the UART UPIPE IEEE 802.15.4 driver. This
allows to remove usage of IEEE802154_UPIPE_DRV_NAME in preparation for
the removal of NET_CONFIG_IEEE802154_DEV_NAME.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
samples should not use CONFIG_TEST_EXTRA_STACK_SIZE, instead, they
should set the recommended stack size directly.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
For further details about interoperability testing please see
* https://lwm2m.openmobilealliance.org/ - Test V1.1 12-Sep-2019
Signed-off-by: Veijo Pesonen <veijo.pesonen@nordicsemi.no>
Make sure that the network interface is up before running the sample.
Otherwise, the sample could stop rightaway due to send failure.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
First off, fix the FD check when closing a socket - currently not all
sockets were closed on exit (0 is also a valid file descriptor).
Second issue is the use of k_thread_abort() on tx/rx threads. The
receving thread was blocked in recv(), and aborting its thread prevented
it from ending gracefully (i. e. the socket mutex allocated in recv()
was not released as the function did not exit properly). This resulted
on a consecutive `close()` call lock. Fix this by setting a timeout on a
receiving socket, and instead of aborting threads allowing them to exit
gracefully.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
Sample code uses GPIO api's but wasn't enabling CONFIG_GPIO. So
on native_posix this would cause the sample to not build. Add
CONFIG_GPIO=y to prj.conf to fix this.
Fixes#48306
Signed-off-by: Kumar Gala <galak@kernel.org>
Add support for running the SocketCAN sample on
native_posix/native_posix_64 using the CAN loopback interface.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
