| /Zephyr-latest/tests/cmake/overlays/soc_folder_kconfig/src/ |
| D | main.c | 65 zassert_false(INCLUDED_BOARD_SUFFIX, "Did not expect board suffix config to be present"); in ZTEST()
68 zassert_false(INCLUDED_BOARD, "Did not expect board config to be present"); in ZTEST()
69 zassert_true(INCLUDED_BOARD_QUALIFIERS, "Expected board qualifier config to be present"); in ZTEST()
72 zassert_true(INCLUDED_BOARD, "Expected board config to be present"); in ZTEST()
74 "Did not expect board qualifier config to be present"); in ZTEST()
78 zassert_false(INCLUDED_BOARD_OTHER, "Did not expect board other config to be present"); in ZTEST()
79 zassert_true(INCLUDED_SOC, "Expect soc config to be present"); in ZTEST()
80 zassert_false(INCLUDED_SOC_SUFFIX, "Did not expect soc suffix config to be present"); in ZTEST()
81 zassert_false(INCLUDED_SOC_OTHER, "Did not expect soc other config to be present"); in ZTEST()
87 zassert_true(INCLUDED_BOARD_SUFFIX, "Expected board suffix config to be present"); in ZTEST()
[all …]
|
| /Zephyr-latest/dts/bindings/regulator/ |
| D | regulator.yaml | 52 description: boolean, regulator should never be disabled
61 This property is intended to only be used for regulators where
67 Regulator should be disabled on boot.
75 description: allow the regulator performance level to be configured
81 ramp rate, it should be explicitly initialised to zero
129 regulator at run-time. Elements may be specified in any order. The set of
151 emergency shutdown. Zero can be passed to disable protection and value '1'
152 indicates that protection should be enabled but limit setting can be
159 probably is malfunctional and damage prevention is requested. Zero can be
161 should be enabled but limit setting can be omitted.
[all …]
|
| /Zephyr-latest/tests/cmake/overlays/soc_folder_overlay/src/ |
| D | main.c | 53 zassert_false(INCLUDED_APP, "Did not expect app overlay to be present"); in ZTEST()
54 zassert_false(INCLUDED_BOARD_SUFFIX, "Did not expect board suffix overlay to be present"); in ZTEST()
57 zassert_false(INCLUDED_BOARD, "Did not expect board overlay to be present"); in ZTEST()
58 zassert_true(INCLUDED_BOARD_QUALIFIERS, "Expected board qualifier overlay to be present"); in ZTEST()
60 zassert_true(INCLUDED_BOARD, "Expected board overlay to be present"); in ZTEST()
62 "Did not expect board qualifier overlay to be present"); in ZTEST()
65 zassert_true(INCLUDED_SOC, "Expect soc overlay to be present"); in ZTEST()
66 zassert_false(INCLUDED_SOC_SUFFIX, "Did not expect soc suffix overlay to be present"); in ZTEST()
72 zassert_false(INCLUDED_APP, "Did not expect app overlay to be present"); in ZTEST()
73 zassert_true(INCLUDED_BOARD_SUFFIX, "Expected board suffix overlay to be present"); in ZTEST()
[all …]
|
| /Zephyr-latest/tests/net/conn_mgr_monitor/src/ |
| D | main.c | 281 * this will be called twice by the test suites for each combination of iface type (except
297 "No events should be fired if connectivity availability did not change."); in cycle_ready_ifaces()
306 "NET_EVENT_L4_CONNECTED should be fired when connectivity is gained."); in cycle_ready_ifaces()
308 "Only NET_EVENT_L4_CONNECTED should be fired when connectivity is gained."); in cycle_ready_ifaces()
309 zassert_equal(stats.conn_iface_gen, ifa, "ifa should be blamed."); in cycle_ready_ifaces()
318 "No events should be fired if connectivity availability did not change."); in cycle_ready_ifaces()
327 "No events should be fired if connectivity availability did not change."); in cycle_ready_ifaces()
336 "NET_EVENT_L4_DISCONNECTED should be fired when connectivity is lost."); in cycle_ready_ifaces()
338 "Only NET_EVENT_L4_DISCONNECTED should be fired when connectivity is lost."); in cycle_ready_ifaces()
339 zassert_equal(stats.dconn_iface_gen, ifb, "ifb should be blamed."); in cycle_ready_ifaces()
[all …]
|
| /Zephyr-latest/dts/bindings/dai/ |
| D | nxp,dai-esai.yaml | 20 index will be considered 0.
25 FIFO. This value needs to be in FIFO words (NOT BYTES). This
26 value needs to be in the following interval: (0, DEFAULT_FIFO_DEPTH],
27 otherwise a BUILD_ASSERT() failure will be raised. If unspecified,
28 the TX FIFO watermark will be set to DEFAULT_FIFO_DEPTH / 2.
33 FIFO. This values needs to be in FIFO words (NOT BYTES). This
34 value needs to be in the following interval: (0, DEFAULT_FIFO_DEPTH],
35 otherwise a BUILD_ASSERT() failure will be raised. If unspecified,
36 the RX FIFO watermark will be set to DEFAULT_FIFO_DEPTH / 2.
40 Use this property to set the FIFO depth that will be reported
[all …]
|
| D | nxp,dai-sai.yaml | 17 By default, if this property is not specified, MCLK will be
25 FIFO. This value needs to be in FIFO words (NOT BYTES). This
26 value needs to be in the following interval: (0, DEFAULT_FIFO_DEPTH],
27 otherwise a BUILD_ASSERT() failure will be raised.
32 FIFO. This value needs to be in FIFO words (NOT BYTES). This
33 value needs to be in the following interval: (0, DEFAULT_FIFO_DEPTH],
34 otherwise a BUILD_ASSERT() failure will be raised.
40 Use this property to set the FIFO depth that will be reported
42 should be in the following interval: (0, DEFAULT_FIFO_DEPTH],
43 otherwise a BUILD_ASSERT() failure will be raised.
[all …]
|
| /Zephyr-latest/doc/security/ |
| D | sensor-threat.rst | 8 be used to help prioritize these efforts as well.
15 images. A general diagram can be seen in Figure 1:
24 model in unexpected ways, and variants on this will need to be
29 as this seems to be in wide use [1]_.
40 a root of trust, this image must be immutable. This model assumes
42 from future writes, and that this will be done after this image is
47 is made because this part of the image will need to be updated
51 a. The image shall only be replaced with an authorized image
55 shall be done in a timely manner [th-timely-update]_.
57 c. The image update shall be seen as atomic, meaning that when the
[all …]
|
| D | secure-coding.rst | 14 uncontrolled access can be devastating [#attackf]_.
41 should have. This knowledge will be necessary for the review process
49 Finally, the document covers how changes are to be made to this
55 Designing an open software system such as Zephyr to be secure requires
61 protection mechanisms cannot be kept secret on any system in
64 well established cryptographic libraries shall be used.
67 system shall be kept as simple and small as possible. In the context
68 of the Zephyr project, this can be realized, e.g., by modular code
72 process needs to be authenticated first. Mechanisms to store access
73 conditions shall be avoided if possible.
[all …]
|
| D | security-overview.rst | 13 to be created. After the process is implemented and all supporting
35 Finally, a process shall be defined for reporting, classifying,
40 how these assets are protected. Certification claims shall be
60 "OPTIONAL" are to be interpreted as described in [RFC2119]_.
67 SHOULD NOT be done may be very subtle. Document authors should take the
77 changes are identified, they will be added to this document through the
80 1. Changes will be submitted from the interested party(ies) via pull
105 requires all code to be reviewed before being committed to the
178 concrete and detailed guidelines need to be developed and aligned with
199 Execution protection is supported and can be categorized into the
[all …]
|
| /Zephyr-latest/doc/develop/api/ |
| D | api_lifecycle.rst | 8 maintaining and extending Zephyr's APIs need to be able to introduce
20 An up-to-date table of all APIs and their maturity level can be found in the
30 or be removed in future versions. Try it out and provide feedback
36 explaining its design and assumptions, how it is to be used, current
38 - The API introduction should be accompanied by at least one implementation
53 The API shall be promoted to ``unstable`` when it has at least two
62 testing to be considered stable. The API is considered generic in nature and can
63 be used on different hardware platforms.
71 Changes will not be announced.
76 The API shall be promoted from ``experimental`` to ``unstable`` when it has at
[all …]
|
| D | design_guidelines.rst | 8 be followed when developing a new capability or interface.
14 configuration structure. The following policies should be followed when
17 * The first parameter should be a pointer to the object most closely
19 would be ``const struct device *dev``. For library functions it may be a
23 * The next parameter(s) should be additional information specific to the
27 * The final parameter should be a ``void *user_data`` pointer carrying
31 An exception to providing ``user_data`` as the last parameter may be
33 will be embedded in another structure. An example of such a case is
64 occurred, as well as user context which may or may not be the
72 code size but are optional in the sense that some applications can be
[all …]
|
| /Zephyr-latest/include/zephyr/kernel/ |
| D | smp.h | 18 * by @a id. It may be called to restart a CPU that had been
20 * After the CPU has finished initialization, the CPU will be
23 * @note This function must not be used on currently running
24 * CPU. The target CPU must be in off state, or in
27 * Detection of such state(s) must be provided by
36 * @param fn Function to be called before letting scheduler
50 * must be provided by the platform layers). It may be used
52 * data on the interrupt or idle stack be preserved.
54 * @note This function must not be used on currently running
55 * CPU. The target CPU must be in suspended state, or
[all …]
|
| /Zephyr-latest/include/zephyr/crypto/ |
| D | cipher.h | 42 * More to be added as required.
112 /** Place for driver to return function pointers to be invoked per
113 * cipher operation. To be populated by crypto driver on return from
118 /** To be populated by the app before calling begin_session() */
120 /* Cryptographic key to be used in this session */
128 /** The device driver instance this crypto context relates to. Will be
137 * max simultaneous sessions they intend to support. To be populated
149 * in a session. To be populated by the app before calling
158 /** Cryptographic keylength in bytes. To be populated by the app
163 /** How certain fields are to be interpreted for this session.
[all …]
|
| /Zephyr-latest/doc/contribute/ |
| D | bin_blobs.rst | 7 many different IC families, some functionality may be unavailable without the
35 Blobs must be hosted on the Internet and managed by third-party infrastructure.
48 The blobs themselves must be specified in the :ref:`module.yml
52 module repository must exist first or be created as part of the submission
55 Each blob which may be fetched must be individually identified in the
61 - The blob’s :ref:`type <bin-blobs-types>`, which must be one of the allowed types
71 The :ref:`west blobs <west-blobs>` command can be used to list metadata of
75 Any accompanying code, including interface header files for the blobs, must be
84 in the context of Zephyr, a tainted image will be one that includes binary blobs
87 Tainting will be communicated to the user in the following manners:
[all …]
|
| /Zephyr-latest/doc/services/device_mgmt/ |
| D | mcumgr_callbacks.rst | 12 that provides control over if the action should be allowed or not. An example
13 of this is with the fs_mgmt group, whereby file access can be gated, the
24 The base callback/notification system can be enabled using
28 be selected by enabling the Kconfig's for the required callbacks (see
30 :c:type:`mgmt_cb` type definition can then be declared and registered by
35 With the system enabled, a basic handler can be set up and defined in
66 event, which will be called after a MCUmgr command has been processed and
68 :kconfig:option:`CONFIG_MCUMGR_SMP_COMMAND_STATUS_HOOKS` be enabled to receive
71 Multiple callbacks can be setup to use a single function as a common callback,
72 and many different functions can be used for each event by registering each
[all …]
|
| /Zephyr-latest/include/zephyr/kernel/mm/ |
| D | demand_paging.h | 87 * Useful if it is known that a memory region will not be used for some time.
88 * All the data pages within the specified region will be evicted to the
93 * be pinned.
95 * Note that there are no guarantees how long these pages will be evicted,
98 * If CONFIG_DEMAND_PAGING_ALLOW_IRQ is enabled, this function may not be
99 * called by ISRs as the backing store may be in-use.
105 * The region may be partially paged out.
113 * function will be paged in. However, they are not guaranteed to stay there.
114 * This is useful if the region is known to be used soon.
116 * If CONFIG_DEMAND_PAGING_ALLOW_IRQ is enabled, this function may not be
[all …]
|
| /Zephyr-latest/dts/bindings/pinctrl/ |
| D | nxp,imx-iomuxc.yaml | 5 This compatible binding should be applied to the device's iomuxc DTS node.
6 the DTS node will be populated with all pinmux options for the specific SOC.
7 These options can then be used in a pinctrl node with the "nxp,mcux-rt-pinctrl"
31 mux_register: register that will be written to make mux selection
46 # Note: the below properties should ideally be an enum. However, the pinctrl driver
55 different register layouts. This property can be set to indicate
57 and should not be modified by the user.
62 different register layouts. This property can be set to indicate
64 and should not be modified by the user.
69 different register layouts. This property can be set to indicate
[all …]
|
| /Zephyr-latest/doc/connectivity/bluetooth/api/ |
| D | gatt.rst | 10 Services can be registered using :c:func:`bt_gatt_service_register` API
13 can be used to declare a service.
15 Attributes can be declared using the :c:struct:`bt_gatt_attr` struct or using
47 callbacks can be set to NULL if the attribute permission don't allow their
51 32-bit UUIDs are not supported in GATT. All 32-bit UUIDs shall be converted
58 Attribute value changes can be notified using :c:func:`bt_gatt_notify` API,
60 pass a callback to be called when it is necessary to know the exact instant when
64 Client procedures can be enabled with the configuration option:
67 Discover procedures can be initiated with the use of
71 field only attributes which matches will be discovered, in contrast setting it
[all …]
|
| /Zephyr-latest/tests/net/conn_mgr_conn/src/ |
| D | main.c | 58 /* Some tests mark ifaces as ignored, this must be reset between each test. */ in reset_test_iface_state()
162 * event propagation times longer than a millisecond would be a sign of a problem,
180 zassert_equal(ifa1_data->init_calls_a, 1, "ifa1->init should be called exactly once."); in ZTEST()
183 zassert_equal(ifa2_data->init_calls_a, 1, "ifa2->init should be called exactly once."); in ZTEST()
186 zassert_equal(ifb_data->init_calls_b, 1, "ifb->init should be called exactly once."); in ZTEST()
189 zassert_equal(ifni_data->init_calls_a, 0, "ifni->init should not be called."); in ZTEST()
190 zassert_equal(ifni_data->init_calls_b, 0, "ifni->init should not be called."); in ZTEST()
209 zassert_false(net_if_is_up(ifa1), "Ifaces must be disconnected before test"); in ZTEST()
210 zassert_false(net_if_is_up(ifa2), "Ifaces must be disconnected before test"); in ZTEST()
211 zassert_false(net_if_is_up(ifb), "Ifaces must be disconnected before test"); in ZTEST()
[all …]
|
| /Zephyr-latest/doc/kernel/memory_management/ |
| D | demand_paging.rst | 17 the eviction algorithm is invoked to select a data page to be paged out,
18 thus freeing up a page frame for new data to be paged in. If this data
19 page has been modified after it is first paged in, the data will be
28 There are functions where paging in and out can be invoked manually
30 :c:func:`k_mem_page_in()` can be used to page in data pages
33 memory, and thus minimizing latency. :c:func:`k_mem_page_out()` can be
34 used to page out data pages where they are not going to be accessed for
36 page in can be executed faster as the paging code does not need to invoke
44 or be paged out to some backing store. Its location can always be looked
46 The data type will always be ``void *`` or in some cases ``uint8_t *``
[all …]
|
| /Zephyr-latest/doc/kernel/usermode/ |
| D | kernelobjects.rst | 6 A kernel object can be one of three classes of data:
20 All kernel objects must be placed in memory that is not accessible by
36 may be called to release any runtime-allocated buffers the object was using.
39 will be freed.
45 and can be located anywhere in the binary, or even declared on stacks. However,
47 not be located in any memory that user threads have direct access to.
49 In order for a static kernel object to be usable by a user thread via system
50 call APIs, several conditions must be met on how the kernel object is declared:
52 * The object must be declared as a top-level global at build time, such that it
56 in a special table of kernel object metadata. Kernel objects may be members
[all …]
|
| /Zephyr-latest/doc/kernel/services/threads/ |
| D | workqueue.rst | 16 Any number of workqueues can be defined (limited only by available RAM). Each
24 thread is configurable, allowing it to be either cooperative or preemptive
31 A workqueue must be initialized before it can be used. This sets its queue to
40 caller need not be concerned that an item may be processing when the
56 delayable work is scheduled, should be avoided to prevent race conditions
63 Any number of **work items** can be defined. Each work item is referenced
71 A work item must be initialized before it can be used. This records the work
74 A work item may be **queued** (:c:enumerator:`K_WORK_QUEUED`) by submitting it to a
80 other items in the queue, a queued work item may be processed quickly or it
83 A delayable work item may be **scheduled** (:c:enumerator:`K_WORK_DELAYED`) to a
[all …]
|
| /Zephyr-latest/dts/bindings/ethernet/ |
| D | xlnx,gem.yaml | 24 frequency will be derived using two dividers in the respective GEM's
27 which it will be adjusted at run-time. Therefore, the value of this
28 item must be set to the clock frequency of the PLL supplying the
48 interval, link-speed and advertise-lower-link-speeds should be checked
57 PHY will be claimed by the driver, watch out in case of shared MDIO
72 the respective controller will be configured to match the link speed
74 the link speed specified here will be requested. If the optional pro-
77 be requested.
108 of memory accesses. This option CAN NOT be used if any component ex-
136 8 kB should be the default.
[all …]
|
| /Zephyr-latest/tests/cmake/hwm/board_extend/src/ |
| D | main.c | 51 zassert_true(EXTENDED_BOARD_A, "Expected extended board to be set");
52 zassert_true(EXTENDED_BOARD_ONE_B, "Expected extended board to be set");
53 zassert_false(EXTENDED_BOARD_TWO_C, "Did not expect extended board two to be set");
54 zassert_true(EXTENDED_BOARD_D, "Expected extended board to be set");
55 zassert_false(BASE_BOARD_CONFIG, "Did not expect base board to be set");
60 zassert_true(EXTENDED_BOARD_A, "Expected extended board to be set");
61 zassert_false(EXTENDED_BOARD_ONE_B, "Did not expect extended board one to be set");
62 zassert_true(EXTENDED_BOARD_TWO_C, "Expected extended board to be set");
63 zassert_true(EXTENDED_BOARD_D, "Expected extended board to be set");
64 zassert_false(BASE_BOARD_CONFIG, "Did not expect base board to be set");
[all …]
|
| /Zephyr-latest/arch/arm/core/mpu/ |
| D | arm_core_mpu_dev.h | 25 * may be defined in a memory domain, given the amount of available HW MPU
33 * For ARM MPU architectures, where the domain partitions cannot be defined
37 * the memory partitions of the domain, the desired memory map can still be
44 * For ARM MPU architectures, where the domain partitions can be defined
58 /* When dynamic regions may not be defined on top of statically
60 * requires two additional MPU regions to be configured; one for
66 /* When dynamic regions may be defined on top of statically allocated
67 * memory regions, a thread stack area may be configured using a
81 * When dynamic regions may not be defined on top of statically
83 * thread stack guard requires two additional MPU regions to be
[all …]
|
