Unit test project for bt_keys_update_usage().
This part of subsys/bluetooth/host/keys.c unit testing.
Signed-off-by: Ahmed Moheb <ahmed.moheb@nordicsemi.no>
This sets the RNG node that will be used by the Nordic
devices which support TF-M (nRF5340/nRF9160) to use the
defined scheme with psa_generate_random.
Signed-off-by: Georgios Vasilakis <georgios.vasilakis@nordicsemi.no>
Zephyr's default settings usually enable the only minimum of peripherals,
and rpi_pico already has `i2c0` enabled.
Remove the `i2c1` node configuration.
Signed-off-by: TOKITA Hiroshi <tokita.hiroshi@fujitsu.com>
Fixes an issue with the documentation whereby the wrong hash/sha
sections were described, also adds a link to upstream MCUboot
documentation for further information.
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
A follow up to commit 1d7a077e11 - apparently the PPP interface should
not be brought entirely down internally, as this can break further
communication with the host. Because of that, reintroduce functionality
that used to be covered by net_if_carrier_down() (which basically
skips the L2 enable(false) call), but limited to PPP scope only.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
Fixes#53786
The variable slot_plus_us is assumed to be a number in us unit.
To assign the maximum possible CTE length to this variable,
BT_HCI_LE_CTE_LEN_MAX has been used while this parameter is defined
in a 8us units (it's 0x14=20 that corresponds to 160us).
To convert this number to us, it's needed to be multiplied by 8.
Signed-off-by: Saleh Mehdikhani <saleh.mehdikhani@unikie.com>
This is important for applications which are chain-loaded by a broken
bootloader which doesn't reset the peripheral before handing over control.
Signed-off-by: Armin Brauns <armin.brauns@embedded-solutions.at>
The documentation for the fixed-partitions binding is missing critical
information and is vague in other important respects. This is an
important binding that deserves to be crystal clear. Fix it.
Signed-off-by: Marti Bolivar <marti.bolivar@nordicsemi.no>
The build system currently links the toolchain-provided C++ standard
library even when the C++ support (`CONFIG_CPP`) is not enabled.
This commit updates the build system to link the toolchain-provided C++
standard library when the C++ support is enabled and a C++ library
implementation other than the Zephyr minimal C++ library is selected.
Signed-off-by: Stephanos Ioannidis <stephanos.ioannidis@nordicsemi.no>
The bt_has_register_param's preset_sync_support and independent_presets
make sense only if CONFIG_BT_HAS_PRESET_COUNT is non-zero meaning the
CONFIG_BT_HAS_PRESET_SUPPORT is enabled.
Otherwise, those parameters shall be skipped.
Signed-off-by: Mariusz Skamra <mariusz.skamra@codecoup.pl>
Add command to perform the Periodic Advertising Set
Info Transfer procedure, which transfers information
about a periodic advertising set to a connected device.
In essence this is just PAST but from the advertiser
instead of a 3rd device.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
In ascs.c we had a case where we assigned stream->conn
without taking the ref.
In bt_audio_stream_attach we did not check if stream->conn
was NULL before taking a reference, causing multiple calls
to ase_config to take multiple references.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
The same board can be used to test multiple regulators, so let's
explicitely set overlays and fixture name.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Regulator voltage needs to be within allowed range before enabling. It
could happen that regulator default voltage is out of the allowed range,
so the regulator could be enabled at boot time producing a not-allowed
voltage.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The existing linear_range API did not allow values or windows outside of
the linear range (returned -EINVAL). With this change values are allowed
outside of the range, being adjusted to the edge values (min/max)
instead. In the case of windows, it is allowed to have partial
intersection. In both cases, the API assigns a valid index (nearest) and
returns -ERANGE. This change is useful because the main client of the
linear range API, regulators, needs such behavior. For example, If an
application specifies a voltage range from 1.0V to 1.5V and the
regulator supports from 1.2V to 2.7V, the regulator can configure a
voltage that satisfies the condition: 1.2V. With the current API, the
input would be refused because 1.0V lies outside of the 1.2V-2.7V range.
Also, for constant ranges, the minimum index is returned.
Tests have been updated/extended accordingly.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Update the Readme file of the large mtu sample because the orginal PR
(https://github.com/zephyrproject-rtos/zephyr/pull/53593) has been merged
before the last comment could be addressed.
Signed-off-by: Théo Battrel <theo.battrel@nordicsemi.no>
The purpose of this commit is to facilitate future improvements to the
LPN and friendship feature. By being able to identify friendship related
messages on the advertising layer, it will be possible to treat these in
a specific manner so that message exchange between LPN and friend
devices can be conducted in a more power efficient manner.
This commit adds the following:
- A separate tag for friendship related messages
- A optional separate advertising set for friend related messages
Signed-off-by: Anders Storrø <anders.storro@nordicsemi.no>
Adds Kconfig option to enable tuning the Friend receive delay window.
Friend poll events can be made more efficient by compensating for the
time the non-ideal advertising latency otherwise would add to the receive
delay.
Signed-off-by: Anders Storrø <anders.storro@nordicsemi.no>
Add nrf5340_audio_dk_nrf5340_cpunet to the platform_allow
as having it only in integration_platforms causes issues
with the CI system.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
In order to clean up clock related code, replace static build time
clock configuration code by a runtime check.
Since I'm not able to guarantee this check will provide a correct
verdict in 100% of the cases (I'm thinking to ULPI or exotic configurations
like F7 OTG-HS), add a config option to disable it if needed.
It also doesn't apply on F1/F3 series. Keep the build time check for now.
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
This change doesn't consider STM32F1 series.
There are 5 categories of STM32 regarding USB domain clock:
A] USB domain clocks directly driven by CK48 clocks
B] USB domain clocks which can select either CK48 or an alternative clock
C] USB domain clocks which can select between MSI or PLL
D] USB domain clocks relying statically on a PLL output
E] USB domain clocks which can be set on 2 different PLL ouputs
For case A], there is nothing to be done. Clk48 was already configured
in a previous change (51c7643295b02ba26ddcd0fd915484114db7101c).
For case B] and C] USB domain clocks will need to be configured in
each board.
For case D] and E] relying on existing dts configuration. Though
there is no easy build time chekc that can be done.
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
STM32F7 allow to run at significantly higher speed that the one configured
on these boards.
Configure clocks to make benefit of full potential.
Additionally, configure PLL_Q output to provide USB compatible 48MHz freq.
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
For boards configuring USB device, enable or configure matching domain
clock when not done already.
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
Describe USB default domain clock on all USB devices.
When available select HSI48.
On some series, a default clock my be set by default at start up.
On those series, in order to be able to compute USB clock at runtime,
clock_control driver needs to be aware of configuration and then this
default config has to be described explicitly too.
Default clocks are not enabled though. It is up to board configuration
to provide correct clock configuration (and we should not enabled by
default clocks that would not be required by board configuration).
Note: This change doesn't consider STM32F1/F3 devices, which
have a specific USB clock configuration.
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
Use STM32_DT_INST_CLOCKS() to access usb device clock information.
This will help accessing domain clock information from dt nodes.
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
Remove this code to clean up the driver.
Clock activation is done from device tree configuration in clock_control
driver.
Users are informed by warning about missing configuration.
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
On stm32wb, M0 core may enable and disable CLK48 when using RNG.
Lock related hsem to prevent M0 to disable CLK48 when it doesn't need it
anymore.
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
In platforms where the linker is capable of doing global optimizations,
like relaxing address mode and synthesize new instructions, Zephyr has to
disable it when enabling USERSPACE since the build expects that address
don't change after the first stage build.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
In some architectures the linker performs global optimization relaxing
address modes and changing intructions in the output object file. This
is a problem when userspace is enabled since it assumes that addresses
won't change after certain build stage. In no supported architectures
this option is ignored.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
Inconsistency between python-devicetree version numbers
may be confusing:
- the last version at PyPI is 0.0.2
- zephyr-rtos/python-devicetree/setup.py sets the version
to 0.0.2 (this is probably the setup file used when uploading
to PyPI)
- zephyr-rtos/zephyr/scripts/dts/python-devicetree/setup.py sets
the version to 0.0.1
This may suggest that the mirror repository, and PyPI, are more
up-to-date than zephyr-rtos/zephyr/scripts/dts/python-devicetree.
Repositories being otherwise mostly identical (1), also bumping
the python-devicetree's version here seems a sane option.
(1) Ignoring the doc directory (only at zephyr-rtos/python-devicetree).
Signed-off-by: Chris Duf <chris@openmarl.org>
This is essentially a revert of PR #46311 "python-devicetree: CI hotfix",
assuming the original issue has been resolved, either upstream in
types-PyYAML or in Zephyr itself.
Tested with types-PyYAML 6.0.12.2 (current version at PyPI):
$ python -m mypy --config-file=tox.ini --package=devicetree
dtlib.py:962: note: By default the bodies of untyped functions [...]
dtlib.py:964: note: By default the bodies of untyped functions [...]
dtlib.py:965: note: By default the bodies of untyped functions [...]
dtlib.py:967: note: By default the bodies of untyped functions [...]
Success: no issues found in 4 source files
The "notes" above are harmless (use of type hinting to define local
variables while mypy won't "check the bodies of untyped functions").
References:
- python-devicetree tox run fails (issue #46286)
- python-devicetree: CI hotfix (PR #46311)
- python-devicetree: CI hotfix (commit f6a6843)
Signed-off-by: Chris Duf <chris@openmarl.org>
This changes some of the MCUmgr transport CMake select statements
to depends on, this is to align with other in-tree symbols that
do not pull in whole subsystems and instead only allow selection
if those subsystems are already enabled.
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
Update the README to add more informations on MTUs. Also add a diagram of
the different MTU and Kconfig symbols in the Host.
Signed-off-by: Théo Battrel <theo.battrel@nordicsemi.no>
Add a new sample that demonstrate how to exchange MTU to allow larger
packet transmission.
The sample is split in two applications. One is the Central, it will
initiate the MTU exchange. The other one is the Peripheral and will try to
send a large notification. If the MTU exchange fail or the new size is not
big enough, the Peripheral will not be able to send the notification.
Signed-off-by: Théo Battrel <theo.battrel@nordicsemi.no>
