move tty.h to console/tty.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>
move console.h to console/console.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>
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>
