If the socket descriptor is invalid (fd < 0), there is no
need to try to close it.
Coverity-CID: 198949
Fixes#16785
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
This is testing size_mul_overflow() in z_impl_k_msgq_alloc_init() so
make sure OVERFLOW_SIZE_MSG is large enough even on 64-bit targets.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
... because this test does use userspace, as seen in the source or
demonstrated by the failure of this command:
sanitycheck --extra-args=CONFIG_TEST_USERSPACE=n
See commit message of 4afcc0f8af for the long story.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
sizeof(value) returns the size of the pointer, not the pointed string.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
tests/bluetooth/gatt/src/main.c
Over time, this has been reduced to a few functions dealing solely
with floating-point support, referenced only from core/ia32/float.c.
Thus they are moved into that file and the header is eliminated.
Signed-off-by: Charles E. Youse <charles.youse@intel.com>
The accounting data stored at the beginning of a memory block used by
malloc must push the returned memory address to a word boundary. This
is already the case on 32-bit systems, but not on 64-bit systems where
e.g. struct k_mem_block_id still has a size of 4.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
Add support to STM LSM6DSO 6-axis IMU sensor driver.
This driver supports communication with device though both
I2C and SPI bus and both polling and drdy trigger mode.
This driver supports also the sensorhub mode with the possibility
to connect a maximum of two external devices, typically a
magnetometer and an environmental sensor, currently selected among
following devices: lis2mdl magnetometer, lps22hh or lps22hb
pressure and temperature sensors, HTS221 humidity sensor.
Signed-off-by: Armando Visconti <armando.visconti@st.com>
Add support to STM LPS22HH pressure and temperature sensor.
The driver support I2C and SPI bus communication and both
polling and drdy trigger mode.
Signed-off-by: Armando Visconti <armando.visconti@st.com>
This was dumping coverage before the test code even ran.
Ideally, this gets re-written to use ztest, but meanwhile
place a dummy main thread which sleeps forever, and dump
coverage once the test succeeds.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Adds coverage for the uncovered json_calc_encoded_len()
and covers a bunch more error cases.
This gets us up to 90.1% line coverage and 100% function
coverage.
Fixes: #16944
Partial fix for: #16011
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
The current CMSIS v2 implementation is clearly assuming that timeout
arguments being passed to e.g. osDelay() are in units of Zephyr ticks,
not milliseconds as specified by ARM or (inconsistently) assumed by
our test code.
Most tests work with the ~100 Hz default tick rate, but they tend to
fail on precision issues at higher tick rates. Force the CMSIS v2
applications to be 1000 Hz for now as a workaround, and detect the
mismatch as a build failure.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This test was written to assume that k_busy_wait() and CMSIS
osKernelSysTick() (which is just k_cycle_get_32()) were perfectly
synchronized. On nRF, they aren't (one is the 32 kHz RTC timer, the
other is a calibrated spin loop using the CPU frequency).
When ticks were being reported at 100 Hz granularity, there wasn't
enough precision to detect the mismatch. Now there is. Rework the
test to require that the clocks match to within 1%.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This test seems a little confused. It does a POSIX usleep() for 90ms,
then checks the time taken, and verifies that it was no less
than... 91ms!
On existing platforms, tick alignment makes sure that we always take a
little longer, so this passes. But on high tick rate configurations we
get it exactly right. And fail.
Adjust the calibration to allow (exactly) 90ms sleeps. Also fixed a
comment that described the wrong units.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This test was written to properly align its millisecond-measured wait
time and assumed that there would be no other overhead. In fact on
fast tick rate systems (or even ones where the alignment computation
doesn't provide the needed padding as "slop") that's not quite enough
time to complete the full test. There are cycles between the sleep
calls that need to be accounted for, and aren't.
Just give it one extra work item of time before failing. We aren't
testing work queue timing precision here, just evaluation semantics.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
"50" ticks is fine with 100 Hz timer precision but way too short to
survive the conversion to milliseconds on fast, non-decimal tick
rates. Make it half a second, which was the original intent.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This test was written to assume ~100 Hz ticks in ways that are
difficult to fix. It wants to sleep for periods on the order of the
TICKLESS_IDLE_THRESH kconfig, which is extremely small on high tick
rate systems and (on nRF in particular) does not have a cleanly
divisible representation in milliseconds.
Fixing precision issues by cranking the idle threshold up on a
per-system basis seems like an abuse, as that is what we want to be
testing in the first place. Just let the test run at the tick rate it
has always expected.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The logic about minimal sleep sizes due to "tick" aliasing was
correct, but drivers also have similar behavior with "cycle" aliasing
too. When cycles are 3-4 orders of magnitude faster than ticks, it's
undetectable noise. But now on nRF they're exactly the same and we
need to correct for that, essentially doubling the number of ticks a
usleep() might wait for.
The logic here was simply too strict, basically. Fast tick rates
can't guarantee what the test promised.
Note that this relaxes the test bounds on the other side of the
equation too: it's no longer an error to usleep() for only one tick
(i.e. an improved sleep/timeout implementation no longer gets detected
as a test failure).
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The sleep test was checking that the sleep took no longer than "2
ticks" longer than requested. But "2 ticks" for fast tick rate
configurations can be "zero ms", and for aliasing reasons it's always
possible to delay for 1 unit more than requested (becuase you can
cross a millisecond/tick/whatever boundary in your own code on either
side of the sleep). So that "slop" value needs to be no less than
1ms.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The test for the k_uptime_delta utilities was calling it in a loop and
waiting for the uptime to advance. But the code was specifically
wanting it to advance 5ms or more at one go, which clearly isn't going
to work for a tick rate above 200 Hz.
The weird thing is that the test knew this and even commented about
the limitation. Which seems silly: it's perfectly fine for the clock
to advance just a single millisecond. That's correct behavior too.
Let's test for that, and it will work everywhere.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
When ticks are sub-millisecond, the math produces minimum and maximum
values for the slice duration test that are equal. But because of
aliasing across tick boundaries, it's always possible (for any time
period, nothing specific to time slicing here) to measure one tick
more than an intended duration. So make sure there's always at least
a range of 1ms.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Tick rate is becoming a platform tunable in the tickless world. Some
apps were setting it due to requirements of drivers or subsystems (or
sometimes for reasons that don't make much sense), but the dependency
goes the other way around now: board/soc/arch level code is
responsible for setting tick rates that work with their devices.
A few tests still use hard-configured tick rates, as they have
baked-in assumptions (like e.g. "a tick will be longer than a
millisecond") that need to be addressed first.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This code was clearly written to assume that the timeout argument to
k_mem_pool_alloc() was in ticks and not ms. Adjust to what appears to
have been the intent. It was working as intended (i.e waiting one or
1/10th of a second) only on systems where the default tick rate was
100 Hz.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
If maxsize is smaller than _MPOOL_MINBLK, then Z_MPOOL_LVLS() will be 0.
That means the loop in z_sys_mem_pool_base_init() that initializes the
block free list for the nonexistent level 0 will corrupt whatever memory
at the location the zero-sized struct sys_mem_pool_lvl array was
located. And the corruption happens to be done with a perfectly legit
memory pool block address which makes for really nasty bugs to solve.
This is more likely on 64-bit systems due to _MPOOL_MINBLK being twice
the size of 32-bit systems.
Let's prevent that with a build-time assertion on maxsize when defining
a memory pool, and adjust the affected test accordingly.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
This header is currently IA32-specific, so move it into the subarch
directory and update references to it.
Signed-off-by: Charles E. Youse <charles.youse@intel.com>
Making room for the Intel64 subarch in this tree. This header is
32-bit specific and so it's relocated, and references rewritten
to find it in its new location.
Signed-off-by: Charles E. Youse <charles.youse@intel.com>
This file is 32-bit specific, so it is moved into the ia32/ directory
and references to it are updated accordingly.
Also, SP_ARG* definitions are no longer used, so they are removed.
Signed-off-by: Charles E. Youse <charles.youse@intel.com>
Check return value of net_if_ipv6_get_ll() before accessing it.
Coverity-CID: 199437
Fixes#17201
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
This mechanism had multiple problems:
- Missing parameter documentation strings.
- Multiple calls to k_thread_name_set() from user
mode would leak memory, since the copied string was never
freed
- k_thread_name_get() returns memory to user mode
with no guarantees on whether user mode can actually
read it; in the case where the string was in thread
resource pool memory (which happens when k_thread_name_set()
is called from user mode) it would never be readable.
- There was no test case coverage for these functions
from user mode.
To properly fix this, thread objects now have a buffer region
reserved specifically for the thread name. Setting the thread
name copies the string into the buffer. Getting the thread name
with k_thread_name_get() still returns a pointer, but the
system call has been removed. A new API k_thread_name_copy()
is introduced to copy the thread name into a destination buffer,
and a system call has been provided for that instead.
We now have full test case coverge for these APIs in both user
and supervisor mode.
Some of the code has been cleaned up to place system call
handler functions in proximity with their implementations.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
This test uses ztest, there is no need to set this and it
was breaking builds with CONFIG_COVERAGE=y
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Test AF_NET_MGMT API getsockopt() and setsockopt() functions that
they work properly when called from kernel or from userspace.
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Add unit tests to net_addr_ntop() and net_addr_pton() in order to
verify that the functions can be called from userspace.
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
The info parameter is difficult to use if the caller does not
get information how long the info struct is. So add info_length
parameter to net_mgmt_event_wait_on_iface() and
net_mgmt_event_wait() APIs.
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
HW stack protection in ARMv8-M is implemented by default
with the built-in stack guard mechanism. Therefore, by
default all tests for ARMv8-M will use the built-in stack
overflow mechanism (CONFIG_BUILTIN_STACK_GUARD is set in
tests). However, we would like have some coverage on the
MPU stack guard mechanism for ARMv8-M. The added test case
manually disables BUILTIN_STACK_GUARD and enables the
MPU_STACK_GUARD option, to provide that test coverage.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
CONFIG_TEST_HW_STACK_PROTECTION is set by default in tests,
and that one selects HW_STACK_PROTECTION option. Therefore,
we do not need to set that one explicitly in the test project
configuration files. We clean up some redundant occurrences of
CONFIG_HW_STACK_PROTECTION=y from the tree.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
sflists have a couple APIs related to sfnodes that aren't
present for slists. There were uncovered, write some tests
for them.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
We were testing all the slist APIs, but not the sflist
variant. Make a copy of the slist tests for sflist,
with the names properly changed.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Some of the slist APIs were only being indirectly exercised;
add to the slist test case to cover everything explicitly.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
There's no need for a system call for this; futexes live in
user memory and the initialization bit is ignored.
It's sufficient to just do an atomic_set().
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Introduce a separate buffer pool for events which the HCI driver
considers discardable. Examples of such events could be e.g.
Advertising Reports. The benefit of having such a pool means that the
if there is a heavy inflow of such events it will not cause the
allocation for other critical events to block and may even eliminate
deadlocks in some cases.
Also update all mesh samples not to specify explicit RX buffer counts
anymore. Instead, create appropriate defaults in Kconfig so that we
only need to override this in the app for cases like the bbc:microbit
with limited memory.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
This event is a priority one, so it's not safe to have it use the RX
buffer pool which may be depleted due to non-priority events (e.g.
advertising events). Since the event is consumed synchronously it's
safe to have a single-buffer pool for it. Also introduce a new
bt_buf_get_evt() API for HCI drivers to simplify the driver-side code,
this effectively also deprecates bt_buf_get_cmd_complete() which now
has no in-tree HCI driver users anymore.
Fixes#16864
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Allow application to call net_if_ipv4_set_gw_by_index()
and set the gateway if enabled by configuration.
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Allow application to call net_if_ipv4_set_netmask_by_index()
and set the netmask if enabled by configuration.
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Andrew Boie