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>
This fixes the coverity problem which which in fact is a non-issue as
the code would assert before reaching that line which makes the NULL
pointer check useless so this removes it.
Fixes#18431
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This fixes the dead code when parsing Find Information response since
the index counter can never be zero, instead it checks there are any
attributes found and if there nothing don't proceed with discovering
which was the original intent of the now dead code.
Fixes#18384
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Due to conditional compile path ending in LL_ASSERT(0), the compiler
sees code following the assert as using uninitialized variables.
Signed-off-by: Morten Priess <mtpr@oticon.com>
The number of arguments for a format string is approximated by the
number of conversion specifications. This count may exceed the maximum
supported argument count. Limit the extraction to the available space.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Newer pyocd versions (specifically the 0.21.0 we have in our
requirements.txt) no longer support -b and have moved the same option
to -u. Keep up.
Fixes: #17554
Signed-off-by: Marti Bolivar <marti.bolivar@nordicsemi.no>
'recoverable' is a value passed by reference and we
should be dereferencing the pointer, to check if the
fault has been classified as recoverable.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
Fix ASSERT expressions with volatile variables in
arch/arm/arm_thread_swap test suite.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
Fix a memset function call so the sizeof() argument is
evaluated using the appropriate struct type.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
Fix ASSERT expression with volatile test variables
in arch/arm/arm_ramfunc test suite. Fix, also, an
logical expression in an if-statement in the test.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
Fix expressions with volatile variables in ASSERT
statements in arch/arm/arm_zero_latency_irq test
suite.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
Closes#18392 by asserting and returning an error if the block size is
not positive.
Closes#18458. The diagnosis here was not relevant as an in-range EOS
is written before the buffer is used, but using the non-terminated
length is slightly more clear about intent and may avoid a read overrun
of the mount point.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
This PR updates the documentation to cover a technical solution to
providing a driver instance that extends the functionality of a
subsystem API. The solution described was mooted in Zephyr PR #17072
and approved by the Technical Steering Committee during its 2019-08-07
meeting.
Relates-to: #11993
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
To avoid a Coverity warning (203449):
https://github.com/zephyrproject-rtos/zephyr/issues/18354
Initialize a pointer to NULL, and check it later before
de-referencing it.
Coverity could not see that posix_print_error_and_exit()
never returns even that it ends with exit()
Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com>
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>
Declan Traill