The macros likely() and unlikely() used by the compiler for
optimization are always used inside an if condition.
According to MISRA we need to have bool type and not long.
Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
In _pend_current_thread the argument key is always a unsigned
interger type and this function forces it to become a signed
interger. This is a dangerous behavior and cant be trusted to
work as expected.
Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
Always compare unsigned interger type with another unsigned
integer type. Currently in nios2, posix, riscv32, x86 and xtensa
we were comparing the _kernel.nested variable with a signed
interger type. Fixed this violation.
Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
The function _arc_v2_irq_unit_is_in_isr computes a Boolean
value but the function returns a integer value.
Fix the return type of the function.
This makes the zephyr api _is_in_isr() return a boolean type.
Thereby making it consistent across all the architectures.
Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
The function _IsInIsr computes a Boolean value but the function
returns a integer value. Fix the return type of the function.
This makes the zephyr api _is_in_isr() return a boolean type.
Thereby making it consistent across all the architectures.
Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
Duh: "remove()" is a POSIX symbol, and on at least some platforms
stdio.h can be included here out of platform headers causing a name
collision.
Fixes#10669's direct issue, though the broader issue of how to choose
names for statics remains controversial.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Log_core test was failing due to test structure elements not being
correctly reset before the test.
Signed-off-by: Krzysztof Chruscinski <krzysztof.chruscinski@nordicsemi.no>
The 'value' param in ACCESS_BY_PORT mode means the state of a port,
one bit represented one pin in param 'value'.
Signed-off-by: qianfan Zhao <qianfanguijin@163.com>
This API shouldn't take a int type but instead it should take
u32_t. This argument has to be similar to irq_lock() and
irq_unlock().
Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
This patch removes the typecast (void*). This can be better
handled by typecasting to the actual typdef. This fixes the
misra rule of 11.6 for alert.
Part of GH-10042.
Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
Python's open() by default using "system character encoding", which
may vary from system to system (e.g. LOCALE=C aka "ascii" on bare-OS
systems, something on Windows, etc.). But Zephyr files are utf-8, so
read them as such, by explicitly specifying encoding.
This is similar to changes earlier done to another script in 94620bd.
Signed-off-by: Paul Sokolovsky <paul.sokolovsky@linaro.org>
Check for NULL IPv6 addr values from net_if_ipv6_get_ll() in rpl.c
If NULL, print out an error statement stating that no proper IPv6
address was found
Coverity-CID: 188169
Fixes#10094.
Signed-off-by: Satya Bhattacharya <satyacube@gmail.com>
Improve the error feedback when calling bt_le_adv_start and inputting
too much data in the advertisement.
Error feedback before:
Bluetooth initialized
Advertising failed to start (err -22)
Error feedback after:
Bluetooth initialized
[bt] [ERR] set_ad: Advertising data does not fit in buffer
Advertising failed to start (err -22)
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
Some new yaml bindings that got committed added back in the 'id:' field
which we have removed. Remove it from those dts binding files.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Add support for ST Micro Nucleo-64 board with the STM32F302R8
processor. nucleo_f429zi and nucleo_f334r8 were used as
references.
Signed-off-by: Galen Seitz <galens@seitzassoc.com>
Add pin muxing for STM32F302x8 by sharing most of the definitions
of the STM32F303xC. Add USART3 for both the 302x8 and the 303xC.
Add a PWM that is specific to the 302x8.
Signed-off-by: Galen Seitz <galens@seitzassoc.com>
This is a new test and we have riscv32 failing on that all of the
sudden. Disabling while we look into it and identify if that is a
testcase issue or not.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Add console harness support for USB mass storage test.
Also, using overlay config for DISK_ACCESS configuration
and accessing the different config file with different
method.
Signed-off-by: Ajay Kishore <ajay.kishore@intel.com>
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Introduces the location property and adds the ability to use values
generated by the device tree configuration.
Signed-off-by: Diego Sueiro <diego.sueiro@gmail.com>
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Use user data to replace DMA's device pointer in
the callback function so that the user can retrieve
its context by that private data.
Signed-off-by: Jun Li <jun.r.li@intel.com>
The first argument in DMA callback can be set to
arbitrary user data instead of DMA device pointer
so the user can pass its private context
in the callback function.
Signed-off-by: Jun Li <jun.r.li@intel.com>
For the 'app' build scripts to be able to do post-processing on the
elf file they need to know what the target name for the elf file is.
In zephyr this name varies depending on whether one does a single or
multiple link, so we export a variable with the name.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
I committed a user error and edited a file named in the sphinx output
to correct an error. To my dismay later, I discovered my work had been
lost as that file is not versioned.
Warn the others.
Signed-off-by: Marti Bolivar <marti@foundries.io>
In a clean build, Ninja is creating copies of the extracted
documentation outputs regardless of whether they already exist or
not. I can't explain this behavior from the documentation of the build
command, but it's so, even if extract_content.py is patched to use
copyfile() instead of copy2() so that outputs (copied .rst files in
the build directory) have strictly newer mtimes than inputs (source
tree .rst files).
This extra copying doesn't happen for incremental builds, for some
reason.
To account for this behavior, add and use an extract_content.py option
that skips content extraction completely and leaves that all up to the
add_custom_command() which tracks each individual input->output build
command.
Reported-by: Carles Cufi <carles.cufi@nordicsemi.no>
Signed-off-by: Marti Bolivar <marti@foundries.io>
In tickless mode, not all elapsed ticks may have been announced yet,
so future z_time_slice() calls will include "extra" ticks that we have
to account for when setting up the slice count.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Our funny convention holds that passing ticks==1 to _add_timeout()
means "at the next tick". But that means that 1, 0, and all negative
numbers are expected to behave the same. In ticked mode, that's fine
because it will, after all, expire at the next tick.
But in tickless, the next announcement may be for several ticks, and
that zero will appear to expire "before" the next tick in the
consumption loop.
Make sure all "next tick" expirations look the same.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This test was written to assume that on idle the CPU would wake up on
the next tick boundary because of the timer interrupt. No such
interrupt arrives in tickless mode and it hangs forever.
A more whiteboxy test involving setting a clock timout will have to be
written for this feature if we want to keep it on tickless systems.
Alternatively we could move this test out of tests/kernel/context and
always disable tickless.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
When fetching the next timeout to expire, the value is relative to the
last announced tick, so you subtract the timer-provided elapsed time
to get the true delta from "now". When adding a new timeout, you
*have* a value relative to now, so you compute the delta vs. the last
announced tick by adding the elapsed() time. Duh.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The theory behind this test seems to be that taking an IRQ lock should
prevent the advance of the kernel's tick counter. That works on
traditional timers only. In tickless mode the timer hardware/driver
is expected to be able to give us an answer for time independent of
interrupt delivery, so the test fails spuriously. The "bug" detected
is a feature of tickless!
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This was wrong in subtle ways. In tickless mode it's possible to get
an announcement for multiple ticks at a time and have multiple
callbacks to execute that were technically scheduled at different
times. We want to fix the current tick at the value represented by
the currently-executing callback's EXPIRATION (even if we missed it!),
so that any new timeouts it sets (c.f. a k_timer period) happen at the
right point, in phase with the expected series. In single-tick mode
the code ends up the same always, so the bug wasn't visible.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
