We were testing the value of a volatile variable inside a zassert,
which static analysis doesn't like. In principle, it might be
volatile because it's an MMIO register or something and the read is a
side effect, and an assertion will be optionally compiled. (Except
here the value is just regular memory marked volatile for
threadsafety, and zassert will never be elided in a test, but the tool
doesn't know that).
Refactor a little so we always read the variable in a way the tool can
detect is consistent.
Fixes#18446
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
It's shorter and may get rid of false Coverity positives 203489 and
203498 and fix#18424 and duplicate #18425.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
pthread_mutex_init() just redirects to Zephyr kernel primitive, for
initializing structure fields. So, use the knowledge that it can't
fail (for as long as structure pointer is initialized, and here it's
from pre-allocated array), and ignore return value of
pthread_mutex_init()
Coverity-CID: 203542
Fixes: #18371
Signed-off-by: Paul Sokolovsky <paul.sokolovsky@linaro.org>
Was "pkconfig", which may confuse users whether some different tool
than the standard pkgconfig is meant.
Signed-off-by: Paul Sokolovsky <paul.sokolovsky@linaro.org>
The code for checking space in the Friend queue was faulty in the case
that we receive a message with more segments than the configured Friend
Queue size. This is not an issue for the default configuration but
still a possible one. Move the check for exceeding Friend Queue Size
to the per-LPN function, so that bt_mesh_friend_queue_has_space()
iterates all LPNs before delivering its verdict. This allows us to
return success in case no LPN matched (which is how the code was
intended to work).
Fixes#18522
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Confirms build (and run) of C++17 applications that make use of STL
containers and other features.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
The solution from #14312 of using -isystem to prioritize the position of
the libc directory bypasses the effect of -ffreestanding with respect to
libc symbols expected to be present in a non-hosted environment.
Further, it breaks C++ with the ARM Embedded toolchain as the system
fails to find the right file with #include_next.
Use a more fine-grained solution that explicitly includes the underlying
newlib header required for <inttypes.h> support before moving on to
include the next available one, whether system or non-system.
Closes#17564
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
The order of the fonts in ROM has changed.
Since the sorting is not wrong, correct the
order in the application.
Signed-off-by: Johann Fischer <j.fischer@phytec.de>
Simplify algorithm to skip (aka calculate length) of encoded domain
name in a DNS answer. Now it's fully compliant to RFC 1035 regarding
handling of compressed FQDNs. Additionally, bounds checking is now
performed by the parsing code.
Fixes: #18334
Signed-off-by: Paul Sokolovsky <paul.sokolovsky@linaro.org>
Fix for Zephyr bug #17415
For settings_line_val_read function with following .conf setting:
CONFIG_SETTINGS_USE_BASE64=y
Signed-off-by: Declan Traill <declan.traill@setec.com.au>
Add test for check whether deleted entry is recognized properly
after settings reload.
Signed-off-by: Andrzej Puzdrowski <andrzej.puzdrowski@nordicsemi.no>
The variable enabling entry to the zero latency interrupt compensation
loop was named generically, and its logic inverted, making the code
difficult to understand. Change the name and initial value to more
clearly indicate its role.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Consistently place C++ use of extern "C" after all include directives,
within the negative branch of _ASMLANGUAGE if used.
Remove extern "C" support from files that don't declare objects or
functions.
In arch/arc/arch.h the extern "C" in the including context is left
active during an include to avoid more complex restructuring.
Background from issue #17997:
Declarations that use C linkage should be placed within extern "C"
so the language linkage is correct when the header is included by
a C++ compiler.
Similarly #include directives should be outside the extern "C" to
ensure the language-specific default linkage is applied to any
declarations provided by the included header.
See: https://en.cppreference.com/w/cpp/language/language_linkage
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Consistently place C++ use of extern "C" after all include directives,
within the negative branch of _ASMLANGUAGE if used.
Remove extern "C" support from files that don't declare objects or
functions.
Background from issue #17997:
Declarations that use C linkage should be placed within extern "C"
so the language linkage is correct when the header is included by
a C++ compiler.
Similarly #include directives should be outside the extern "C" to
ensure the language-specific default linkage is applied to any
declarations provided by the included header.
See: https://en.cppreference.com/w/cpp/language/language_linkage
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Consistently place C++ use of extern "C" after all include directives,
within the negative branch of _ASMLANGUAGE if used.
Background from issue #17997:
Declarations that use C linkage should be placed within extern "C"
so the language linkage is correct when the header is included by
a C++ compiler.
Similarly #include directives should be outside the extern "C" to
ensure the language-specific default linkage is applied to any
declarations provided by the included header.
See: https://en.cppreference.com/w/cpp/language/language_linkage
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Consistently place C++ use of extern "C" after all include directives,
within the negative branch of _ASMLANGUAGE if used.
Background from issue #17997:
Declarations that use C linkage should be placed within extern "C"
so the language linkage is correct when the header is included by
a C++ compiler.
Similarly #include directives should be outside the extern "C" to
ensure the language-specific default linkage is applied to any
declarations provided by the included header.
See: https://en.cppreference.com/w/cpp/language/language_linkage
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Consistently place C++ use of extern "C" after all include directives,
within the negative branch of _ASMLANGUAGE if used.
Remove extern "C" support from files that don't declare objects or
functions.
Background from issue #17997:
Declarations that use C linkage should be placed within extern "C"
so the language linkage is correct when the header is included by
a C++ compiler.
Similarly #include directives should be outside the extern "C" to
ensure the language-specific default linkage is applied to any
declarations provided by the included header.
See: https://en.cppreference.com/w/cpp/language/language_linkage
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Remove extern "C" support from files that don't declare symbols subject
to language linkage effects.
Consistently place C++ use of extern "C" after all include directives,
within the negative branch of _ASMLANGUAGE if used.
Background from issue #17997:
Declarations that use C linkage should be placed within extern "C"
so the language linkage is correct when the header is included by
a C++ compiler.
Similarly #include directives should be outside the extern "C" to
ensure the language-specific default linkage is applied to any
declarations provided by the included header.
See: https://en.cppreference.com/w/cpp/language/language_linkage
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Consistently place C++ use of extern "C" after all include directives,
within the negative branch of _ASMLANGUAGE if used.
In arch.h the extern "C" in the including context is left active during
include of target-specific mpu headers to avoid more complex
restructuring.
Background from issue #17997:
Declarations that use C linkage should be placed within extern "C"
so the language linkage is correct when the header is included by
a C++ compiler.
Similarly #include directives should be outside the extern "C" to
ensure the language-specific default linkage is applied to any
declarations provided by the included header.
See: https://en.cppreference.com/w/cpp/language/language_linkage
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Move the tail include file outside the extern "C" block.
Background from issue #17997:
Declarations that use C linkage should be placed within extern "C"
so the language linkage is correct when the header is included by
a C++ compiler.
Similarly #include directives should be outside the extern "C" to
ensure the language-specific default linkage is applied to any
declarations provided by the included header.
See: https://en.cppreference.com/w/cpp/language/language_linkage
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Remove extern "C" support from files that don't declare symbols subject
to language linkage effects.
Background from issue #17997:
Declarations that use C linkage should be placed within extern "C"
so the language linkage is correct when the header is included by
a C++ compiler.
Similarly #include directives should be outside the extern "C" to
ensure the language-specific default linkage is applied to any
declarations provided by the included header.
See: https://en.cppreference.com/w/cpp/language/language_linkage
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Consistently place C++ use of extern "C" after all include directives,
within the negative branch of _ASMLANGUAGE if used.
Background from issue #17997:
Declarations that use C linkage should be placed within extern "C"
so the language linkage is correct when the header is included by
a C++ compiler.
Similarly #include directives should be outside the extern "C" to
ensure the language-specific default linkage is applied to any
declarations provided by the included header.
See: https://en.cppreference.com/w/cpp/language/language_linkage
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Documents major driver changes (additions, removals, fixes, etc.) across
all driver families since the 1.14.0 release.
Signed-off-by: Maureen Helm <maureen.helm@nxp.com>
Consistently place C++ use of extern "C" after all include directives,
within the negative branch of _ASMLANGUAGE if used.
Background from issue #17997:
Declarations that use C linkage should be placed within extern "C"
so the language linkage is correct when the header is included by
a C++ compiler.
Similarly #include directives should be outside the extern "C" to
ensure the language-specific default linkage is applied to any
declarations provided by the included header.
See: https://en.cppreference.com/w/cpp/language/language_linkage
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Consistently place C++ use of extern "C" after all include directives,
within the negative branch of _ASMLANGUAGE if used.
Background from issue #17997:
Declarations that use C linkage should be placed within extern "C"
so the language linkage is correct when the header is included by
a C++ compiler.
Similarly #include directives should be outside the extern "C" to
ensure the language-specific default linkage is applied to any
declarations provided by the included header.
See: https://en.cppreference.com/w/cpp/language/language_linkage
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Consistently place C++ use of extern "C" after all include directives,
within the negative branch of _ASMLANGUAGE if used.
Background from issue #17997:
Declarations that use C linkage should be placed within extern "C"
so the language linkage is correct when the header is included by
a C++ compiler.
Similarly #include directives should be outside the extern "C" to
ensure the language-specific default linkage is applied to any
declarations provided by the included header.
See: https://en.cppreference.com/w/cpp/language/language_linkage
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Consistently place C++ use of extern "C" after all include directives,
within the negative branch of _ASMLANGUAGE if used.
Background from issue #17997:
Declarations that use C linkage should be placed within extern "C"
so the language linkage is correct when the header is included by
a C++ compiler.
Similarly #include directives should be outside the extern "C" to
ensure the language-specific default linkage is applied to any
declarations provided by the included header.
See: https://en.cppreference.com/w/cpp/language/language_linkage
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
If there is more than one IO Channel than generate a define with a
trailing index for the IO Channel. This matches what we do for GPIOs
and PWMs.
So something like:
DT_FOOBAR_IO_CHANNELS_CONTROLLER_0
DT_FOOBAR_IO_CHANNELS_CONTROLLER_1
...
DT_FOOBAR_IO_CHANNELS_CONTROLLER_<N>
Fixes#18352
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
We need SDK version 0.10.3 to fix a build regress on RISC-V when
linking. So bump the version to pickup that fix.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
In status variable in espi_pc_isr should have been a 32-bit unsigned int
as ESPI_PC_REGS->PC_STATUS is 32-bits.
Fixes#18359
Coverity-CID: 203521
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
According to Mesh Profile Specification 1.0.1 Figure 5.17, the
unprovisioned device should send its confirmation value after the
provisioner sends theirs. Previously, the confirmation value would be
sent immediately after OOB input complete. Now it first waits for the
input data, then from confirmation from the provisioner before sending
the confirmation.
Fixes: #18178.
Signed-off-by: Trond Einar Snekvik <Trond.Einar.Snekvik@nordicsemi.no>
Let's use IS_ENABLED() instead of the #ifdef to get clearer code. ret
variable is used only at one place, no need for the ARG_UNUSED()
Coverity-CID: 203397
Fixes#18419
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Let's use IS_ENABLED() instead of the #ifdef to get clearer code. ret
variable is used only at one place, no need for the ARG_UNUSED()
Coverity-CID: 203468
Fixes#18420
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
There is a bug where non-normalized paths can introduce multiple entries
for the same file. E.g. '/1/2/../2.file' and '/1/2/3/../../2.file' would
both be listed, and end in a ninja error because multiple targets
generate the same file.
This commit fixes this issue by normalizing the paths.
Signed-off-by: Håkon Øye Amundsen <haakon.amundsen@nordicsemi.no>
Qualification test case MESH/NODE/FRND/FN/BV-08-C requires that we do
not store more messages than the reported Friend Queue size. The
implementation was so far opportunistic and stored more if it could
(it would later discard if necessary to make sure all queues can store
the required amount). The spec also requires the queues to have new
messages overwrite old ones (in the style of a circular buffer), so we
have to keep track of which buffers are part of the same segmented
message (so we discard all buffers belonging to the same message).
To pass the test case, add APIs to check for space in the Friend
queue, and track the number of buffers for each incoming segmented
message.
Fixes#18090
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The bt_mesh_trans_resend() function had no users, and had in fact not
even a prototype in a header file. Just remove it.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
When sent solely to the Friend Queue the send callbacks were not
getting called for unsegmented messages.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
'timeout' needs to be a signed variable, so that the
check for less-than-zero is able to result to true (if
the timeout actually expires). Addresses the coverity
issue [Coverity CID :203493] reported in #18379.
Fixes#18379.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
