Currently, HCI packet handling does not consider the BT_RECV_CONTEXT
choice selection. It calls bt_recv() and bt_recv_prio() only depending
on the HCI packet type and event flags.
However, for selections other than BT_RECV_BLOCKING, the "HCI driver
shall not call bt_recv_prio()". Fix that by only calling bt_recv_prio()
when CONFIG_BT_RECV_BLOCKING is enabled.
Signed-off-by: Markus Fuchs <markus.fuchs@ch.sauter-bc.com>
There is some ambiguity with the DHCPv4 handling in the dns_resolve
sample. On one hand, the sample uses net_config library, which does
initiate the DHCPv4 on the interface (if enabled) and may block the
initialization until the address is assigned (in case there is no other
statically assigned IPv4 addresses.) On the other hand, the sample
registers for NET_EVENT_IPV4_ADDR_ADD in case DHCPv4 is in use, delaying
the DNS queries until address is assigned.
In case net_config delayed the initialization however, this will not
work, as the event handler will be registered only after DHCPv4 address
is assigned, so the callback will not get executed.
Fix this, by checking if DHCPv4 assigned address already exists on an
interface - if so, schedule DNS queries immediately. Otherwise (for
example in case when net_config was not configured to wait for address)
register an event callback, and schedule queries from there.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
Add tests cases which verify that net_if_ipv4/6_addr_foreach() executes
callbacks properly on assigned addresses.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
Add new net_if API functions which allow to loop over all valid
IPv4/IPv6 addresses assigned to the interface and execute a callback
function on them.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
When parsing user input for "wifi connect" and "wifi ap enable"
commands, the SSID and PSK lengths were not verified. It's better to
detect invalid connect/AP enable parameters early, so that help text can
be printed, instead of letting wifi_mgmt command to fail.
For WIFI_SECURITY_TYPE_SAE, follow the Linux convention of limiting the
size to 128 bytes.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
Some DHCPv4 servers do not respect BROADCAST flag set on DHCP Discover,
replying with unicast packet, making it impossible to obtain DHCP
address by Zephyr in such cases.
RFC1542 chapter 3.1.1 makes the following statement about the BROADCAST
flag:
This addition to the protocol is a workaround for old host
implementations. Such implementations SHOULD be modified so
that they may receive unicast BOOTREPLY messages, thus making
use of this workaround unnecessary. In general, the use of
this mechanism is discouraged.
Making it clear that being able to process unicast replies from the DHCP
server is not only an optional behavior, but a recommended solution.
Therefore, introduce a support for unicast DHCPv4 in Zephyr. To achieve
this, add additional filtering rule at the IPv4 level - in case DHCPv4
is enabled, there is an active query and the packet is destined for the
DHCPv4 module, let it through for the DHCPv4 module to process,
regardless of the destination IP address.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
- use CONFIG_HAS_HW_NRF_* symbols consistently in nRF multi-instance
drivers when creating particular driver instances
- remove unnecessary hidden Kconfig options that indicated the type of
peripheral to be used by a given instance (e.g. SPI, SPIM, or SPIS)
and enabled proper nrfx driver instance; instead, use one option per
peripheral type and include the corresponding shim driver flavor into
compilation basing on that option (not the one that enables the nrfx
driver as it was incorrectly done so far in some cases)
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
- use CONFIG_HAS_HW_NRF_* symbols consistently in nRF multi-instance
drivers when creating particular driver instances
- remove unnecessary hidden Kconfig options that indicated the type of
peripheral to be used by a given instance (e.g. SPI, SPIM, or SPIS)
and enabled proper nrfx driver instance; instead, use one option per
peripheral type and include the corresponding shim driver flavor into
compilation basing on that option (not the one that enables the nrfx
driver as it was incorrectly done so far in some cases)
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
- use CONFIG_HAS_HW_NRF_* symbols consistently in nRF multi-instance
drivers when creating particular driver instances
- remove unnecessary hidden Kconfig options that indicated the type of
peripheral to be used by a given instance (e.g. SPI, SPIM, or SPIS)
and enabled proper nrfx driver instance; instead, use one option per
peripheral type and include the corresponding shim driver flavor into
compilation basing on that option (not the one that enables the nrfx
driver as it was incorrectly done so far in some cases)
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
- use CONFIG_HAS_HW_NRF_* symbols consistently in nRF multi-instance
drivers when creating particular driver instances
- remove unnecessary hidden Kconfig options that indicated the type of
peripheral to be used by a given instance (e.g. SPI, SPIM, or SPIS)
and enabled proper nrfx driver instance; instead, use one option per
peripheral type and include the corresponding shim driver flavor into
compilation basing on that option (not the one that enables the nrfx
driver as it was incorrectly done so far in some cases)
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
- use CONFIG_HAS_HW_NRF_* symbols consistently in nRF multi-instance
drivers when creating particular driver instances
- remove unnecessary hidden Kconfig options that indicated the type of
peripheral to be used by a given instance (e.g. SPI, SPIM, or SPIS)
and enabled proper nrfx driver instance; instead, use one option per
peripheral type and include the corresponding shim driver flavor into
compilation basing on that option (not the one that enables the nrfx
driver as it was incorrectly done so far in some cases)
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
- use CONFIG_HAS_HW_NRF_* symbols consistently in nRF multi-instance
drivers when creating particular driver instances
- remove unnecessary hidden Kconfig options that indicated the type of
peripheral to be used by a given instance (e.g. SPI, SPIM, or SPIS)
and enabled proper nrfx driver instance; instead, use one option per
peripheral type and include the corresponding shim driver flavor into
compilation basing on that option (not the one that enables the nrfx
driver as it was incorrectly done so far in some cases)
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
Previously the driver was retrofitted to the kscan api, handling it as a
input device with one row and three columns. With the move to the input
subsystem each input can have its proper input code instead.
Signed-off-by: Fabian Blatz <fabianblatz@gmail.com>
STM32H5 series lacked support for MCO configuration.
Added SOC_SERIES_STM32H5X to approperiate kconfig MCO source
configurations. Added new MCO sources from H5 series and
updated the clock_stm32_ll_h5.c with MCO configuration.
Signed-off-by: Kacper Dalach <dalachowsky@gmail.com>
The 'zephyr,memory-region-mpu' property was addede gqas a
convenient way to create and configure MPU regions using information
coming from DT. It has been used a lot since it was introduced so I
guess we can consider it a Zephyr success story ™ .
Unfortunately it has been proved to be a bit limited and with some
important limitations:
1. It was introduced as a property of the compatible
zephyr,memory-region that is used to create linker regions and
sections from DT data. This means that we can actually create MPU
regions only for DT-defined regions and sections.
2. The naming is unfortunate because it is implying that it is used only
for MPU.
3. It is misplaced being in include/zephyr/linker/devicetree_regions.h
and still it has nothing to do with the linker at all.
4. It is exporting a function called LINKER_DT_REGION_MPU that again has
nothing to do with the linker.
Point (1) is also particularly limiting because it is preventing us to
characterize memory regions that are not generated using the
'zephyr,memory-region' compatible, like generic mmio-sram regions.
While we fix all the issues, we also want to extend a bit the range of
usefulness of this property. We are renaming it 'zephyr,memory-attr' and
it is now carrying information about the type of memory the property is
attached to (cacheable, non-cacheable, IO, eXecutable, etc...). The user
can use this property and the DT API coming with it to act on the memory
node it is accompanied by.
We are still providing the DT_MEMORY_ATTR_APPLY() macro that can be used
to create the MPU regions as before, but we are adding also a
DT_MEMORY_ATTR_FOREACH_NODE() macro that can be used to cycle through
the memory nodes and act on those.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
Allows the application to force the use of an NRPA.
This is applied regardless of any other roles running (ie scanner) or
advertising type.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
Co-authored-by: Aleksander Wasaznik <aleksander.wasaznik@nordicsemi.no>
Added several missing brief descriptions and documented some of the
fields guarded by Kconfig options.
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
Grouped some defines together, documented service classes and
attributes, and fixed some missing javadoc-style comments.
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
Compiling I2C target test for efr32bg22_brd4184a board so
that i2c_gecko.c driver is used in target mode.
Signed-off-by: Kai Meinhard <kaimeinhard@hotmail.de>
This commits adds the ability to use Silicon Lab chips as an I2C
target. This could be used together with the EEPROM target
driver.
Signed-off-by: Kai Meinhard <kaimeinhard@hotmail.de>
Some EFR32 build broke after 3d2194f11e with:
pm.c:152: undefined reference to `pm_state_exit_post_ops'
Add an extra empty function to make this one build again.
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
Increaing mesh scan window in order to reduce the number
of messages colliding into scan window end which happens
every 30ms currently. Increasing the window to 3000ms in
order to improve performance.
Keeping 30ms window only for legacy advertiser support.
Signed-off-by: Alperen Sener <alperen.sener@nordicsemi.no>
Using `arg + 0` in sizeof causes problems with `void *`, so use the
type name instead, but make sure it's at least `sizeof(int)` because
the variadic expects a minimum of `int` size. This allows deleting
the specialization for `void *`, which the linker wasn't choosing
reliably anyway.
Signed-off-by: Paul Fagerburg <pfagerburg@google.com>
CPU idle states are not board specific. This patch moves Nuvoton idle
states to the core SoC dts files. Board can always tweak some state
parameters (if needed), but the definition belongs to core SoC dts
files, same as e.g. peripherals.
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
CPU idle states are not board specific. This patch moves NXP idle states
to the core SoC dts files. Board can always tweak some state parameters
(if needed), but the definition belongs to core SoC dts files, same as
e.g. peripherals.
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
CPU idle states are not board specific. This patch moves Microchip MEC
idle states to the core SoC dts files. Board can always tweak some state
parameters (if needed), but the definition belongs to core SoC dts
files, same as e.g. peripherals.
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
CPU idle states are not board specific. This patch moves TI idle
states to the core SoC dts files. Board can always tweak some state
parameters (if needed), but the definition belongs to core SoC dts
files, same as e.g. peripherals.
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
CPU idle states are not board specific. This patch moves STM32 idle
states to the core SoC dts files. Board can always tweak some state
parameters (if needed), but the definition belongs to core SoC dts
files, same as e.g. peripherals.
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
CPU idle states are not board specific. This patch moves ESP32 idle
states to the core SoC dts files. Board can always tweak some state
parameters (if needed), but the definition belongs to core SoC dts
files, same as e.g. peripherals.
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
The test is failing for lpcxpresso51u68 with:
soc_flash_lpc.c:25:2: error: #error No matching compatible for
soc_flash_lpc.c
25 | #error No matching compatible for soc_flash_lpc.c
| ^~~~~
Add the board to the exclude list, sort the list as well.
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
