move flash_map.h to storage/flash_map.h and
create a shim for backward-compatibility.
No functional changes to the headers.
A warning in the shim can be controlled with CONFIG_COMPAT_INCLUDES.
Related to #16539
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Fix path for system_timer.h and loapic.h, we moved it to
include/drivers/timer/ and include/drivers/interrupt_controller/
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
USBD_CFG_DATA_DEFINE macro has not consider that a class
could have more than one set of usb_cfg_data struct.
If a class has more than one set of usb_cfg_data
then they should be sorted the same way like by
USBD_DEVICE_DESCR_DEFINE macro.
Fixes: #16240
Signed-off-by: Johann Fischer <j.fischer@phytec.de>
Updated the bluetooth module to use static handlers. Removed the
old bt specific static registration.
The routine bt_settings_init() is still calling settings_init() which
IMO is not needed anymore.
Updates:
changed SETTINGS_REGISTER_STATIC() to SETTINGS_STATIC_HANDLER_DEFINE()
changed settings_handler_stat type to settings_handler_static type
removed NULL declarations
renamed bt_handler to bt_settingshandler, as bt_handler already exists.
renamed all bt_XXX_handler to bt_xxx_settingshandler to avoid any
overlap.
changed SETTINGS_STATIC_HANDLER_DEFINE() to create variable names from
_hname by just prepending them with settings_handler_.
updated all bt_xxx_settings_handler to just bt_xxx.
Signed-off-by: Laczen JMS <laczenjms@gmail.com>
Add the possibility to register handles to ROM using a new macro
SETTINGS_REGISTER_STATIC(handler), the handler is of type
settings_handler_stat and has to be declared as const:
```
const struct settings_handler_stat test_handler = {
.name = "test", /* this can also be "ps/data"
.h_get = get,
.h_set = set,
.h_commit = NULL, /* NULL defines can be ommited */
.h_export = NULL /* NULL defines can be ommited */
};
SETTINGS_REGISTER_STATIC(test_handler);
```
To maintain support for handlers stored in RAM (dynamic handlers)
`CONFIG_SETTINGS_DYNAMIC_HANDLERS`must be enabled, which is by default.
When registering static handlers there is no check if this handler has
been registered earlier, the latest registered static handler will be
considered valid for any set/get routine, while the commit and export
routines will be executed for both registered handlers.
When a dynamic handler is registered a check is done to see if there was
an earlier registration of the name as a static or dynamic handler
registration will fail.
To get to the lowest possible RAM usage it is advised to set
`CONFIG_SETTINGS_DYNAMIC_HANDLERS=n`.
Updates:
a. Changed usage of RAM to DYNAMIC/dynamic, ROM to STATIC/static
b. Updated settings.h to remove added #if defined()
c. Make static handlers always enabled
d. Corrected error introduced in common-rom.ld.
e. Changed return value of settings_parse_and_lookup to
settings_handler_stat type to reduce stack usage.
f. Updated the name generated to store a handler item in ROM. It now
uses the name used to register in combination with the line where
SETTINGS_REGISTER_STATIC() is called.
g. renamed settings_handler_stat type to settings_handler_static
h. renamed SETTINGS_REGISTER_STATIC to SETTINGS_STATIC_HANDLER_DEFINE()
Signed-off-by: Laczen JMS <laczenjms@gmail.com>
The first word is used as a pointer, meaning it is 64 bits on 64-bit
systems. To reserve it, it has to be either a pointer, a long, or an
intptr_t. Not an int nor an u32_t.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
The string returned by bt_uuid_str() is not in ROM so log_strdup()
must be used on it. This also eliminates the following kind of warning
messages: "<err> log: argument 3 in log message "%s: start_handle
0x%04x end_handle 0x%04x type %s" missing log_strdup()."
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Folks found the use of @rststar/@endrststar non-intuitive (wanted to use
@rststart). The "star" was there indicating the doxygen comment lines
had a leading asterisk that needed to be stripped, but since our
commenting convention is to use the leading asterisk on continuation
lines, the leading asterisk is always there. So, change the doxygen
alias to the more expected @rst/@endrst.
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
Compilers (at least gcc and clang) already provide definitions to
create standard types and their range. For example, __INT16_TYPE__ is
normally defined as a short to be used with the int16_t typedef, and
__INT16_MAX__ is defined as 32767. So it makes sense to rely on them
rather than hardcoding our own, especially for the fast types where
the compiler itself knows what basic type is best.
Using compiler provided definitions makes even more sense when dealing
with 64-bit targets where some types such as intptr_t and size_t must
have a different size and range. Those definitions are then adjusted
by the compiler directly.
However there are two cases for which we should override those
definitions:
* The __INT32_TYPE__ definition on 32-bit targets vary between an int
and a long int depending on the architecture and configuration.
Notably, all compilers shipped with the Zephyr SDK, except for the
i586-zephyr-elfiamcu variant, define __INT32_TYPE__ to a long int.
Whereas, all Linux configurations for gcc, both 32-bit and 64-bit,
always define __INT32_TYPE__ as an int. Having variability here is
not welcome as pointers to a long int and to an int are not deemed
compatible by the compiler, and printing an int32_t defined with a
long using %d makes the compiler to complain, even if they're the
same size on 32-bit targets. Given that an int is always 32 bits
on all targets we might care about, and given that Zephyr hardcoded
int32_t to an int before, then we just redefine __INT32_TYPE__ and
derrivatives to an int to keep the peace in the code.
* The confusion also exists with __INTPTR_TYPE__. Looking again at the
Zephyr SDK, it is defined as an int, even even when __INT32_TYPE__ is
initially a long int. One notable exception is i586-zephyr-elf where
__INTPTR_TYPE__ is a long int even when using -m32. On 64-bit targets
this is always a long int. So let's redefine __INTPTR_TYPE__ to always
be a long int on Zephyr which simplifies the code, works for both
32-bit and 64-bit targets, and mimics what the Linux kernel does.
Only a few print format strings needed adjustment.
In those two cases, there is a safeguard to ensure the type we're
enforcing has the right size and fail the build otherwise.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
Currently, the free block bitmap is roughly 4 times larger than it
needs to, wasting memory.
Let's assume maxsz = 128, minsz = 8 and n_max = 40.
Z_MPOOL_LVLS(128, 8) returns 3. The block size for level #0 is 128,
the block size for level #1 is 128/4 = 32, and the block size for
level #2 is 32/4 = 8. Hence levels 0, 1, and 2 for a total of 3 levels.
So far so good.
Now let's look at Z_MPOOL_LBIT_WORDS(). We get:
Z_MPOOL_LBIT_WORDS_UNCLAMPED(40, 0) = ((40 << 0) + 31) / 32 = 2
Z_MPOOL_LBIT_WORDS_UNCLAMPED(40, 1) = ((40 << 2) + 31) / 32 = 5
Z_MPOOL_LBIT_WORDS_UNCLAMPED(40, 2) = ((40 << 4) + 31) / 32 = 20
None of those are < 2 so Z_MPOOL_LBIT_WORDS() takes the results from
Z_MPOOL_LBIT_WORDS_UNCLAMPED().
Finally, let's look at _MPOOL_BITS_SIZE(. It sums all possible levels
with Z_MPOOL_LBIT_BYTES() which is:
#define Z_MPOOL_LBIT_BYTES(maxsz, minsz, l, n_max) \
(Z_MPOOL_LVLS((maxsz), (minsz)) >= (l) ? \
4 * Z_MPOOL_LBIT_WORDS((n_max), l) : 0)
Or given what we already have:
Z_MPOOL_LBIT_BYTES(128, 8, 0, 40) = (3 >= 0) ? 4 * 2 : 0 = 8
Z_MPOOL_LBIT_BYTES(128, 8, 1, 40) = (3 >= 1) ? 4 * 5 : 0 = 20
Z_MPOOL_LBIT_BYTES(128, 8, 2, 40) = (3 >= 2) ? 4 * 20 : 0 = 80
Z_MPOOL_LBIT_BYTES(128, 8, 3, 40) = (3 >= 3) ? 4 * ??
Wait... we're missing this one:
Z_MPOOL_LBIT_WORDS_UNCLAMPED(40, 3) = ((40 << 6) + 31) / 32 = 80
then:
Z_MPOOL_LBIT_BYTES(128, 8, 3, 40) = (3 >= 3) ? 4 * 80 : 0 = 320
Further levels yeld (3 >= 4), (3 >= 5), etc. so they're all false and
produce 0.
So this means that we're statically allocating 428 bytes to the bitmap
when clearly only the first 3 Z_MPOOL_LBIT_BYTES() results for the
corresponding 3 levels that we have should be summed e.g. only
108 bytes.
Here the code logic gets confused between level numbers and the number
levels, hence the extra allocation which happens to be exponential.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
When splitting the pointer from the flag, ~SYS_SFLIST_FLAGS_MASK remains
a 32-bit value because of the lack of an L qualifier. Let's qualify it
with UL so the top half of 64-bit pointers is not truncated.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
Move modem_receiver.h to the driver directory. No other users in the
tree and it is a private header.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Move internal and architecture specific headers from include/drivers to
subfolder for timer:
include/drivers/timer
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Move internal and architecture specific headers from include/drivers to
subfolder for interrupt_controller:
include/drivers/interrupt_controller/
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Although the Characteristic Value descriptor is required to be
immediately after the characteristic descriptor, the specification
allows for gaps in the corresponding Attribute handles. Use the value
handle from the characteristic descriptor for value reads.
See BLUETOOTH CORE SPECIFICATION Version 5.1 Vol 3, Part G section 2.5.1
(p. 2345), first paragraph.
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
It is useful that the ptp_clock_get() function can be called from
the userspace. Create also unit test for calling that function
from userspace.
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Make net_eth_get_ptp_clock_by_index() clock API to work with user space.
Create also unit test for testing this user mode support.
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
This was only enabled by the MVIC, which in turn was only used
by the Quark D2000, which has been removed.
Signed-off-by: Charles E. Youse <charles.youse@intel.com>
The Quark D2000 is the only x86 with an MVIC, and since support for
it has been dropped, the interrupt controller is orphaned. Removed.
Signed-off-by: Charles E. Youse <charles.youse@intel.com>
This commit introduces new top_value setting configuration structure
with flag for controlling resetting of the counter during change of
top value.
Such change allows for #12068 implementation on hardware which
does not provide alarms.
Signed-off-by: Piotr Zięcik <piotr.ziecik@nordicsemi.no>
Signed-off-by: Krzysztof Chruscinski <krzysztof.chruscinski@nordicsemi.no>
Signed-off-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
A k_futex is a lightweight mutual exclusion primitive designed
to minimize kernel involvement. Uncontended operation relies
only on atomic access to shared memory. k_futex structure lives
in application memory. And when using futexes, the majority of
the synchronization operations are performed in user mode. A
user-mode thread employs the futex wait system call only when
it is likely that the program has to block for a longer time
until the condition becomes true. When the condition comes true,
futex wake operation will be used to wake up one or more threads
waiting on that futex.
This patch implements two futex operations: k_futex_wait and
k_futex_wake. For k_futex_wait, the comparison with the expected
value, and starting to sleep are performed atomically to prevent
lost wake-ups. If different context changed futex's value after
the calling use-mode thread decided to block himself based on
the old value, the comparison will help observing the value
change and will not start to sleep. And for k_futex_wake, it
will wake at most num_waiters of the waiters that are sleeping
on that futex. But no guarantees are made on which threads are
woken, that means scheduling priority is not taken into
consideration.
Fixes: #14493.
Signed-off-by: Wentong Wu <wentong.wu@intel.com>
In z_sys_mem_pool_block_alloc() the size of the first level block
allocation is rounded up to the next 4-bite boundary. This means one
or more of the trailing blocks could overlap the free block bitmap.
Let's consider this code from kernel.h:
#define K_MEM_POOL_DEFINE(name, minsz, maxsz, nmax, align) \
char __aligned(align) _mpool_buf_##name[_ALIGN4(maxsz * nmax) \
+ _MPOOL_BITS_SIZE(maxsz, minsz, nmax)]; \
The static pool allocation rounds up the product of maxsz and nmax not
size of individual blocks. If we have, say maxsz = 10 and nmax = 20,
the result of _ALIGN4(10 * 20) is 200. That's the offset at which the
free block bitmap will be located.
However, because z_sys_mem_pool_block_alloc() does this:
lsizes[0] = _ALIGN4(p->max_sz);
Individual level 0 blocks will have a size of 12 not 10. That means
the 17th block will extend up to offset 204, 18th block up to 216, 19th
block to 228, and 20th block to 240. So 4 out of the 20 blocks are
overflowing the static pool area and 3 of them are even located
completely outside of it.
In this example, we have only 20 blocks that can't be split so there is
no extra free block bitmap allocation beyond the bitmap embedded in the
sys_mem_pool_lvl structure. This means that memory corruption will
happen in whatever data is located alongside the _mpool_buf_##name
array. But even with, say, 40 blocks, or larger blocks, the extra bitmap
size would be small compared to the extent of the overflow, and it would
get corrupted too of course.
And the data corruption will happen even without allocating any memory
since z_sys_mem_pool_base_init() stores free_list pointer nodes into
those blocks, which in turn may get corrupted if that other data is
later modified instead.
Fixing this issue is simple: rounding on the static pool allocation is
"misparenthesized". Let's turn
_ALIGN4(maxsz * nmax)
into
_ALIGN4(maxsz) * nmax
But that's not sufficient.
In z_sys_mem_pool_base_init() we have:
size_t buflen = p->n_max * p->max_sz, sz = p->max_sz;
u32_t *bits = (u32_t *)((u8_t *)p->buf + buflen);
Considering the same parameters as above, here we're locating the extra
free block bitmap at offset `buflen` which is 20 * 10 = 200, again below
the reach of the last 4 memory blocks. If the number of blocks gets past
the size of the embedded bitmap, it will overlap memory blocks.
Also, the block_ptr() call used here to initialize the free block linked
list uses unrounded p->max_sz, meaning that it is initially not locating
dlist nodes within the same block boundaries as what is expected from
z_sys_mem_pool_block_alloc(). This opens the possibility for allocated
adjacent blocks to overwrite dlist nodes, leading to random crashes in
the future.
So a complete fix must round up p->max_sz here too.
Given that runtime usage of max_sz should always be rounded up, it is
then preferable to round it up once at compile time instead and avoid
further mistakes of that sort. The existing _ALIGN4() usage on p->max_sz
at run time are then redundant.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
We introduce linker symbols to hold the start and end address of
the memory area holding the thread privilege stack buffers,
applicable when building with support for User Mode.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
We introduce a new define to describe the alignment for a
privilege stack buffer. This macro definition is used by the
privilege stack generation script, to determine the required
alignment of threads' privilege stacks when building with
support for user mode.
We cannot use Z_THREAD_MIN_STACK_ALIGN in this case, because
the privilege stacks do not need to respect the minimum MPU
region alignment requirement, unless, of course, this is
enforced via the MPU Stack Guard feature.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
This commit re-organizes the macro definitions in arch.h for
the ARM architecture. In particular, the commit:
- defines the minimum alignment requirement for thread stacks,
that is, excluding alignment requirement for (possible)
MPU stack guards.
- defines convenience macros for the MPU stack guard align and
size for threads using the FP services under Shared registers
mode (CONFIG_FP_SHARING=y). For that, a hidden Kconfig option
is defined in arch/arm/core/cortex_m/mpu/Kconfig.
- enforces stack alignment with a wide MPU stack guard (128
bytes) under CONFIG_FP_SHARING=y for the ARMv7-M architecture,
which requires start address alignment with power-of-two and
region size.
The commit does not change the amount of stack that is reserved
with K_THREAD_STACK_DEFINE; it only determines the stack buffer
alignment as explained above.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
These constants do not need global exposure, as they're only
referenced in the reboot API implementation. Also their names
are trimmed to fit into the X86-arch-specific namespace.
Signed-off-by: Charles E. Youse <charles.youse@intel.com>
Log records may store either data or pointers to more records. In both
cases they must have the same size. With 64-bit pointers, the amount
of data that can occupy the same space as a pointer has to be adjusted.
And storage alignment has to accommodate actual pointers not u32_t.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
Log arguments were hardcoded to u32_t values. On 64-bit systems, this
is rather restrictive. To make things clear, arguments now have their
own type, log_arg_t, which now can be adjusted in only one location
if need be. It is currently defined as unsigned long whose effective
width is equivalent to u32_t on 32-bit systems, and u64_t on 64-bit
systems.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
There is no point allowing smaller alignments. And on 64-bit systems the
minimum becomes 8 rather than 4, so let's adjust things automatically.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
Many things are currently aligned on 32-bit boundaries. On 64-bit
targets this should be 64-bit boundaries instead. Provide a pair of
macros, namely WB_UP() and WB_DN(), that do the right thing in both
cases.
The naming is short on purpose as this gets will be used within other
macro definitions, sometimes multiple times per line, and having a
longer name would make for excessively long lines.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
This function uses mqtt_read_publish_payload_blocking to perform a
blocking read of the specified number of bytes.
When reading out a payload, the normal use case is to read the
entire payload. This function facilitates that use case.
Signed-off-by: Håkon Øye Amundsen <haakon.amundsen@nordicsemi.no>
Found a few annoying typos and figured I better run script and
fix anything it can find, here are the results...
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Commit b65fe62719 updated the minimum
required net_buf user data to 8 bytes, so increase this define as
well. It has no other practical purpose except to trigger build
asserts if the user data is for some reason ever decreased below this
minimum.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The settings module processes the variable name by splitting it up in
a set of variables. This PR removes the splitting up and keeps the
variable name as one string.
It is an alternative to #16609
The possibility is introduced to register handler including a
separator, or to register a handler for each variable.
The ability is introduced to load a subtree from flash or even to load
a single item.
Two ways to operate on variable and settings_handler names are provided:
settings_name_steq(const char *name, const char *key, const char **next)
which checks if name starts with key, returns 1/0 if it does/does not
the remaining part of name is in next.
settings_name_split(const char *name, char *argv, const char **next)
which splits up name in a part before "/"" that is found in argv and
the remaining part that is in next.
A mutex is added to make settings thread-safe
The settings_handlers list is stored in reverse alphabetical order, this
allows registration of e.g. bt and bt/mesh in separate handlers, the bt
handler itself should not contain any handling of bt/mesh.
A settings_deregister() method is added. Settings_handlers can now be
added/removed when required. This saves RAM when settings_handlers are
not needed.
Tests have been updated to reflect changes in the settings api.
Updates after meeting:
1. Removed settings_deregister
2. Changed settings_name_split() in settings_name_next:
int settings_name_next(const char *name, const char **next): returns
the number of characters before the first separator. This can then be
used to read the correct number of characters from name using strncpy
for processing.
3. New functional test added
Update in settings.h: settings_name_next() changed position -> index
Added some comments in settings.h (settings_name_steq())
Updated tests to reflect change to settings_name_next() and pointer
value comparison. The functional test can now also run on qemu_x86.
Corrected some documentation in header.
Changed registration of handlers to be non ordered.
Changed handler lookup to handle non ordered list of handlers, this
improves handler matching in case different length names are compared
and also makes it easier to add rom based handlers as they will not be
ordered.
Signed-off-by: Laczen JMS <laczenjms@gmail.com>
If the socket is closed, then do CAN detach if that is needed.
This way the CAN interrupts are not received if there are no
CAN sockets listening the data.
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
As title says, struct wdt_config and enum wdt_clock_timeout_cycles are
not used anymore so they can be removed.
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
As seen previously, some toolchain are willing to insert padding
at section changes to apply greater alignments by default. This is
especially true with 64-bit builds. USB structures are marked with the
packed attribute and therefore the linker section they land into
must also be byte aligned.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
On 64-bit systems the most notable difference is due to longs and
pointers being 64-bit wide. Therefore there must be a distinction
between ints and longs. Similar to the prf.c case, this patch properly
implements the h, hh, l, ll and z length modifiers as well as some small
cleanups.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
Remove unused definition of MEMDOMAIN_ALIGN_SIZE macro
from include/app_memory/app_memdomain.h.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
This API had several issues:
- The parameter types and order were inconsistent with e.g.
bt_le_adv_start()
- There were no real users of num_params, which just caused increased
code size and memory consumption for no good reason.
- The error handling policy was arbitrary: if one of the
notifications would fail it would be impossible for the caller to
know if some notifications succeeded, i.e. at what point the
failure happened. Some callers might also want to make note of the
failure but continue trying to notify for the remaining parameters.
The first issue is easily fixable, but because of the other two I
think it's best we don't have this code as part of the stack, rather
require whoever needs it to do the for loop themselves. It's just a
few lines of code, so the benefit of having this in the stack was
anyway quite minimal.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The only we support cores that don't have CMOV insns are the MINUTEIAs,
so we simply check for that rather this using a layer of indirection.
Signed-off-by: Charles E. Youse <charles.youse@intel.com>
The k_stack data type cannot be u32_t on a 64-bit system as it is
often used to store pointers. Let's define a dedicated type for stack
data values, namely stack_data_t, which can be adjusted accordingly.
For now it is defined to uintptr_t which is the integer type large
enough to hold a pointer, meaning it is equivalent to u32_t on 32-bit
systems and u64_t on 64-bit systems.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
