This is no longer necessary, as this option is selected as a dependency
for class implementations where it is required.
Also remove redundant test cases.
Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
Added a driver for the DFRobot A01NYUB distance sensor. This sensor
sends its readings via UART at 9600 baud. This driver uses interrupts
to read the data from the sensor.
Signed-off-by: Oliver King <oliver.king@steadconnect.com>
Test that `pm_device_driver_init` puts devices into the appropriate
state depending on the devicetree configuration.
Signed-off-by: Jordan Yates <jordan.yates@data61.csiro.au>
Update the expected power domain behaviour in the tests in line with
the driver implementation changes.
Signed-off-by: Jordan Yates <jordan.yates@data61.csiro.au>
Variant of JSON_OBJ_DESCR_ARRAY_ARRAY that can be used when the
structure and JSON field names differ.
Signed-off-by: Bartosz Bilas <bartosz.bilas@hotmail.com>
Add initial version of Infineon CAT1 counter driver
Add initial version of binding file for Infineon
Add counters to psco6 dtsi
Add external trigger pin that runs counter
Signed-off-by: Pavlo Havrylyuk <pavlo.havrylyuk@infineon.com>
Refactor the ESP32 target SOCs together with
all related boards. Most braking changes includes:
- changing the CONFIG_SOC_ESP32* to refer to
the actual soc line (esp32,esp32s2,esp32s3,esp32c3)
- replacing CONFIG_SOC with the CONFIG_SOC_SERIES
- creating CONFIG_SOC_FAMILY_ESP32 to embrace all
the ESP32 across all used architectures
- introducing CONFIG_SOC_PART_NUMBER_* to
provide a SOC model config
- introducing the 'common' folder to hide all
commonly used configs and files.
- updating west.yml to reflect previous changes in hal
Signed-off-by: Marek Matej <marek.matej@espressif.com>
Remove virtual esp32 board and replace it with the
real word boards:
- esp32_devkitc_wroom
- esp32_devkitc_wrover (with PSRAM option)
Signed-off-by: Marek Matej <marek.matej@espressif.com>
Add `CONFIG_DEVICE_DEPS` to force two stage linking, otherwise the
following check means the test never runs:
```
if (TARGET zephyr_pre1)
add_dependencies(zephyr_pre1 check_init_priorities_output)
endif()
```
Signed-off-by: Jordan Yates <jordan.yates@data61.csiro.au>
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>
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>
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>
