Add missing declarations of functions that are compiled in when
CONFIG_BT_CTLR_ADV_EXT_PDU_EXTRA_DATA_MEMORY is selected
Add missing include of header file.
Signed-off-by: Piotr Pryga <piotr.pryga@nordicsemi.no>
Fix duplicate include of lll_test.c file under the
unsupported ISR profiling feature in OpenISA port.
Signed-off-by: Vinayak Kariappa Chettimada <vich@nordicsemi.no>
Use `#if defined(...)` instead of `#if IS_ENABLED(..)` when
conditional compilation of definitions in source code.
Signed-off-by: Vinayak Kariappa Chettimada <vich@nordicsemi.no>
Commits affecting Zephyr that are included with the new revision:
fb489e1f mgmt: Add support for un-registering a group along with
the same support in img_mgmt
c8151d80 zephyr: Rely on img_mgmt_find_best_area_id to select update
partition
b92aa0b8 Fix encoding usage for halffloat
Signed-off-by: Dominik Ermel <dominik.ermel@nordicsemi.no>
Use timeout mechanism instead of unbounded loop during enabling ITIM32
module which source clock is LFCLK (32KHz).
Signed-off-by: Mulin Chao <mlchao@nuvoton.com>
Add quadspi node in stm32f7.dtsi and quadspi support to boards
stm32f746g_disco and stm32f769i_disco.
Note! Does not support DMA.
Signed-off-by: Helge Juul <helge@fastmail.com>
This commit prepares supporting sdmmc on
stm32l4+ devices. When trying to compile the
sdmmc driver there is a compilation error
because `HAL_SDEx_DriveTransceiver_1_8V_Callback`
is not implemented. We solve this by compiling
also `sd_ex` in cube as this function is implemented
there as weak.
Signed-off-by: Shlomi Vaknin <shlomi.39sd@gmail.com>
mpu9250 is a single package that contains both an mpu6050 6-axis
motion sensor and an ak8963 magnetometer. The two parts have
separate i2c addresses, yet despite the common mpu6050 component,
it has a different value in the "WHOAMI" register -- 0x71 instead
of 0x68.
This adds the additional chip id value in order to enable the use
of mpu9250.
Signed-off-by: Adam Serbinski <adam@serbinski.com>
We should verify that the buffer has sufficient data before attempting
to parse the SDU length field. If we get a too short packet just
disconnect the channel.
Fixes#32497
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Add pwm to board yaml as supported peripherals on the bbc_microbit.
This is needed as the servo_motor sample requires it.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Add a newer, much smaller and simpler implementation of abort and
join. No need to involve the idle thread. No need for a special code
path for self-abort. Joining a thread and waiting for an aborting one
to terminate elsewhere share an implementation. All work in both
calls happens under a single locked path with no unexpected
synchronization points.
This fixes a bug with the current implementation where the action of
z_sched_single_abort() was nonatomic, releasing the lock internally at
a point where the thread to be aborted could self-abort and confuse
the state such that it failed to abort at all.
Note that the arm32 and native_posix architectures, which have their
own thread abort implementations, now see a much simplified
"z_thread_abort()" internal API.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
THIS COMMIT DELIBERATELY BREAKS BISECTABILITY FOR EASE OF REVIEW.
SKIP IF YOU LAND HERE.
Remove the existing implementatoin of k_thread_abort(),
k_thread_join(), and the attendant facilities in the thread subsystem
and idle thread that support them.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This function would correctly suppress attempts to set timeouts that
were too soon for the driver or farther out than what was already set,
but when it actually set the timeout it would use the requested value
and not clamp it to the minimum of it and the current timeout
expiration, leading to "too-long" timeouts being set at the driver.
In uniprocessor configurations, that turns out to have been benign
because something else would always come back along when timeout state
changed and fix the broken value before the expiration.
But in SMP, this opens up races. For example, the idle thread on one
CPU can see that there are no active threads and schedule a maximum
value timeout at the same time as the other thread adds a new timeout
that expects a near-term expiration. The broken code here would see
that the new timeout exists, decide that yes it needs to override, but
then set the K_TICKS_FOREVER value it got from the idle thread!
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Qemu when running more than one processor has a known synchronization
bug where counter values read from the HPET (notionally a single
global device) can be seen going "backwards" when read from different
CPUs.
There was a pre-existing workaround in the ISR that knew about this,
but the problem can crop up anywhere the counter value is used. In
particular I caught it aliasing with the "max_ticks" computation in
z_clock_set_timeout(), where it would cause a rollover and the
resulting negative comparator value would result in no end of
hilarity.
Wrap all access to the counter register with a counter() inline that
(when the workaround is enabled) forces the result to be monotonic by
clamping it to a minimum of one more than the previously read value.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
When the kernel is TICKLESS, timeouts are set as needed, and drivers
all have some minimum amount of time before which they can reliably
schedule an interrupt. When this happens, drivers will kick the
requested interrupt out by one tick. This means that it's not
reliably possible to get a timeout set for "one tick in the
future"[1].
And attempting to do that is dangerous anyway. If the driver will
delay a one-tick interrupt, then code that repeatedly tries to
schedule an imminent interrupt may end up in a state where it is
constantly pushing the interrupt out into the future, and timer
interrupts stop arriving! The timeout layer actually has protection
against this case.
Finally getting to the point: in recent changes, the timeslice layer
lost its integration with the "imminent" test in the timeout code, so
it's now able to run into this situation: very rapidly context
switching code (or rapidly arriving interrupts) will have the effect
of infinitely[2] delaying timeouts and stalling the whole timeout
subsystem.
Don't try to be fancy. Just clamp timeslice duration such that a
slice is 2 ticks at minimum and we'll never hit the problem. Adjust
the two tests that were explicitly requesting very short slice rates.
[1] Of course, the tradeoff is that the tick rate can be 100x higher
or more, so on balance tickless is a huge win.
[2] Actually it only lasts until a 31 bit signed rollover in the HPET
cycle count in practice.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Recent work to normalize use of the thread QUEUED state bit means that
we never attempt to remove unqueued threads from the low-level run
queue. So the old workaround for SWAP_NONATOMIC that was trying to
detect this condition isn't necessary anymore.
Which is serendipitous, because it was written to encode some very
specific logic about the circumstances where _current could be
dequeued that I'd like to be able to break.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This is part of the scheduler API, and was always just a synchronized
wrapper around the internal ready_thread() function. But where the
internal users seem to be careful not to call it on threads that are
not known to be already queued or running, the general users in the
IPC code seem to be less strict.
Add a simple test to detect the case where a thread is already
running. Right now this just loops over the array of CPUs, so is O(N)
in the CPU count even though N is never more than four for us
currently. But this is possible without modifying data structures. A
more scalable way to do this if we ever need to run on very parallel
systems would be to use another state bit for RUNNING, or to keep a
backpointer in the thread struct to the CPU it's running on, etc...
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Swap was originally written to use the scheduler lock just to select a
new thread, but it would be nice to be able to rely on scheduler
atomicity later in the process (in particular it would be nice if the
assignment to cpu.current could be seen atomically). Rework the code
a bit so that swap takes the lock itself and holds it until just
before the call to arch_switch().
Note that the local interrupt mask has always been required to be held
across the swap, so extending the lock here has no effect on latency
at all on uniprocessor setups, and even on SMP only affects average
latency and not worst case.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Aborted threads will cancel their timeouts, but the timeout subsystem
isn't protected under the same lock so it's possible for a timeout to
fire just as a thread is being aborted and wake it up unexpectedly.
Check the state before blowing anything up.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This got missed, leaving garbage there for restarted threads to trip
on. Actually I see multiple uninitialized fields, which seems odd.
This code deserves some rework, thread initialization isn't a
performance path and we should probably be zeroing the struct out.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
sometimes a test instance hasn't been boot up to execute successfully,
so the results is an empty dictionary, it will not be added into final
twister_report.xml file.
in order to include it, fill the results as BLOCK.
Signed-off-by: peng1 chen <peng1.chen@intel.com>
RFC template mentioned in the doc is broken.
Fixing it to direct to the correct one.
Signed-off-by: Spoorthy Priya Yerabolu <spoorthy.priya.yerabolu@intel.com>
gen_isr_table uses 6 IRQs for testing. Originally, it uses IRQ 41-36.
However, the IRQ37 & 36 are enabled by other modules in NPCX chips.
Change TEST_NUM_IRQS to use 45-40 for the test.
Signed-off-by: Wealian Liao <WHLIAO@nuvoton.com>
Fix array overrun of client features bitset, where CF_BYTE_LAST was
incorrectly defined as 2 using module instead of divide.
Also fix additional bit-logic when number of bits would exceed a byte:
- Inner for loop iterates from 0 to number of bits on a single byte.
- Same bitmask used for all bytes.
Signed-off-by: Joakim Andersson <joakim.andersson@nordicsemi.no>
The board's main I2C bus controller doesn't have a compatible set, so
it's not detected as an I2C bus at all.
This breaks the build when trying to build the samples/sensor/lis2dh
application with the lis2dh sensor on that bus.
Fixes: #32420
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
ARC mpu version used a wrong number 3, could cause conflict in future.
This commit fix this issue to version number 4.
Signed-off-by: Yuguo Zou <yuguo.zou@synopsys.com>
The timeout might take more than 10ms in a heavily loaded system,
so increase the timeout to 20ms.
For example this is often seen for mps2_an385 platform.
Assertion failed at \
WEST_TOPDIR/zephyr/tests/net/socket/select/src/main.c:101: \
test_select: (tstamp <= FUZZ is false)
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
This also makes it into arch_printk_char_out() which gets linked
in place of the weak symbol version, meaning printk() is usable
as soon as the stack is set up.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
