diff --git a/doc/reference/kernel/data_passing/fifos.rst b/doc/reference/kernel/data_passing/fifos.rst index 0e0868a96b4..aecb68f5cdf 100644 --- a/doc/reference/kernel/data_passing/fifos.rst +++ b/doc/reference/kernel/data_passing/fifos.rst @@ -62,7 +62,7 @@ Implementation Defining a FIFO =============== -A FIFO is defined using a variable of type :c:type:`struct k_fifo`. +A FIFO is defined using a variable of type :c:type:`k_fifo`. It must then be initialized by calling :cpp:func:`k_fifo_init()`. The following code defines and initializes an empty FIFO. diff --git a/doc/reference/kernel/data_passing/lifos.rst b/doc/reference/kernel/data_passing/lifos.rst index bb0c3814271..6c53b7efdbb 100644 --- a/doc/reference/kernel/data_passing/lifos.rst +++ b/doc/reference/kernel/data_passing/lifos.rst @@ -53,7 +53,7 @@ Implementation Defining a LIFO =============== -A LIFO is defined using a variable of type :c:type:`struct k_lifo`. +A LIFO is defined using a variable of type :c:type:`k_lifo`. It must then be initialized by calling :cpp:func:`k_lifo_init()`. The following defines and initializes an empty LIFO. diff --git a/doc/reference/kernel/data_passing/mailboxes.rst b/doc/reference/kernel/data_passing/mailboxes.rst index 6b431a75f54..45ab134045a 100644 --- a/doc/reference/kernel/data_passing/mailboxes.rst +++ b/doc/reference/kernel/data_passing/mailboxes.rst @@ -118,7 +118,7 @@ Implementation Defining a Mailbox ================== -A mailbox is defined using a variable of type :c:type:`struct k_mbox`. +A mailbox is defined using a variable of type :c:type:`k_mbox`. It must then be initialized by calling :cpp:func:`k_mbox_init()`. The following code defines and initializes an empty mailbox. @@ -141,7 +141,7 @@ The following code has the same effect as the code segment above. Message Descriptors =================== -A message descriptor is a structure of type :c:type:`struct k_mbox_msg`. +A message descriptor is a structure of type :c:type:`k_mbox_msg`. Only the fields listed below should be used; any other fields are for internal mailbox use only. diff --git a/doc/reference/kernel/data_passing/message_queues.rst b/doc/reference/kernel/data_passing/message_queues.rst index ed5d836de85..9f5d6934f08 100644 --- a/doc/reference/kernel/data_passing/message_queues.rst +++ b/doc/reference/kernel/data_passing/message_queues.rst @@ -70,7 +70,7 @@ Implementation Defining a Message Queue ======================== -A message queue is defined using a variable of type :c:type:`struct k_msgq`. +A message queue is defined using a variable of type :c:type:`k_msgq`. It must then be initialized by calling :cpp:func:`k_msgq_init()`. The following code defines and initializes an empty message queue diff --git a/doc/reference/kernel/data_passing/pipes.rst b/doc/reference/kernel/data_passing/pipes.rst index 5f1e523c058..94d28100274 100644 --- a/doc/reference/kernel/data_passing/pipes.rst +++ b/doc/reference/kernel/data_passing/pipes.rst @@ -52,8 +52,8 @@ waiting sender(s). Implementation ************** -A pipe is defined using a variable of type :c:type:`struct k_pipe` and an -optional character buffer of type :c:type:`unsigned char`. It must then be +A pipe is defined using a variable of type :c:type:`k_pipe` and an +optional character buffer of type ``unsigned char``. It must then be initialized by calling :cpp:func:`k_pipe_init()`. The following code defines and initializes an empty pipe that has a ring diff --git a/doc/reference/kernel/data_passing/stacks.rst b/doc/reference/kernel/data_passing/stacks.rst index 6facaf9964e..4f8cceae3f8 100644 --- a/doc/reference/kernel/data_passing/stacks.rst +++ b/doc/reference/kernel/data_passing/stacks.rst @@ -55,7 +55,7 @@ Implementation Defining a Stack ================ -A stack is defined using a variable of type :c:type:`struct k_stack`. +A stack is defined using a variable of type :c:type:`k_stack`. It must then be initialized by calling :cpp:func:`k_stack_init()` or :cpp:func:`k_stack_alloc_init()`. In the latter case, a buffer is not provided and it is instead allocated from the calling thread's resource diff --git a/doc/reference/kernel/memory/heap.rst b/doc/reference/kernel/memory/heap.rst index e0e3323cee9..fba17d9c45f 100644 --- a/doc/reference/kernel/memory/heap.rst +++ b/doc/reference/kernel/memory/heap.rst @@ -13,8 +13,8 @@ Creating a Heap =============== The simplest way to define a heap is statically, with the -:c:macro:`K_HEAP_DEFINE` macro. This creates a static :c:type:`struct -k_heap` variable with a given name that manages a memory region of the +:c:macro:`K_HEAP_DEFINE` macro. This creates a static :c:type:`k_heap` variable +with a given name that manages a memory region of the specified size. Heaps can also be created to manage arbitrary regions of @@ -46,9 +46,9 @@ returned by :cpp:func:`k_heap_alloc()` for the same heap. Freeing a Low Level Heap Allocator ************************ -The underlying implementation of the :c:type:`struct k_heap` -abstraction is provided a data structure named :c:type:`struct -sys_heap`. This implements exactly the same allocation semantics, but +The underlying implementation of the :c:type:`k_heap` +abstraction is provided a data structure named :c:type:`sys_heap`. This +implements exactly the same allocation semantics, but provides no kernel synchronization tools. It is available for applications that want to manage their own blocks of memory in contexts (for example, userspace) where synchronization is unavailable @@ -79,7 +79,7 @@ combined with adjacent free blocks to prevent fragmentation. All metadata is stored at the beginning of the contiguous block of heap memory, including the variable-length list of bucket list heads (which depend on heap size). The only external memory required is the -:c:type:`struct sys_heap` structure itself. +:c:type:`sys_heap` structure itself. The ``sys_heap`` functions are unsynchronized. Care must be taken by any users to prevent concurrent access. Only one context may be diff --git a/doc/reference/kernel/memory/pools.rst b/doc/reference/kernel/memory/pools.rst index 7f575d6d66a..7ea03af9933 100644 --- a/doc/reference/kernel/memory/pools.rst +++ b/doc/reference/kernel/memory/pools.rst @@ -5,12 +5,12 @@ Memory Pools .. note:: - The ``k_mem_pool`` data structure defined here has been deprecated + The :c:type:`k_mem_pool` data structure defined here has been deprecated in current Zephyr code. It still exists for applications which require the specific memory allocation and alignment patterns detailed below, but the default heap implementation (including the - default backend to the k_mem_pool APIs) is now a :c:type:`struct - k_heap` allocator, which is a better choice for general purpose + default backend to the k_mem_pool APIs) is now a :c:type:` k_heap` + allocator, which is a better choice for general purpose code. A :dfn:`memory pool` is a kernel object that allows memory blocks @@ -119,7 +119,7 @@ Implementation Defining a Memory Pool ====================== -A memory pool is defined using a variable of type :c:type:`struct k_mem_pool`. +A memory pool is defined using a variable of type :c:type:`k_mem_pool`. However, since a memory pool also requires a number of variable-size data structures to represent its block sets and the status of its quad-blocks, the kernel does not support the runtime definition of a memory pool. diff --git a/doc/reference/kernel/memory/slabs.rst b/doc/reference/kernel/memory/slabs.rst index 5d7c50095d6..680469b6f48 100644 --- a/doc/reference/kernel/memory/slabs.rst +++ b/doc/reference/kernel/memory/slabs.rst @@ -67,7 +67,7 @@ Implementation Defining a Memory Slab ====================== -A memory slab is defined using a variable of type :c:type:`struct k_mem_slab`. +A memory slab is defined using a variable of type :c:type:`k_mem_slab`. It must then be initialized by calling :cpp:func:`k_mem_slab_init()`. The following code defines and initializes a memory slab that has 6 blocks diff --git a/doc/reference/kernel/other/polling.rst b/doc/reference/kernel/other/polling.rst index 3e6de6ace22..4828305d83a 100644 --- a/doc/reference/kernel/other/polling.rst +++ b/doc/reference/kernel/other/polling.rst @@ -68,7 +68,7 @@ Using k_poll() ============== The main API is :cpp:func:`k_poll()`, which operates on an array of poll events -of type :c:type:`struct k_poll_event`. Each entry in the array represents one +of type :c:type:`k_poll_event`. Each entry in the array represents one event a call to :cpp:func:`k_poll()` will wait for its condition to be fulfilled. @@ -82,7 +82,7 @@ this). The user **tag** is optional and completely opaque to the API: it is there to help a user to group similar events together. Being optional, it is passed to the static initializer, but not the runtime ones for performance reasons. If using runtime initializers, the user must set it separately in the -:c:type:`struct k_poll_event` data structure. If an event in the array is to be +:c:type:`k_poll_event` data structure. If an event in the array is to be ignored, most likely temporarily, its type can be set to K_POLL_TYPE_IGNORE. .. code-block:: c @@ -125,12 +125,12 @@ satisfied and not sooner. Only one thread can poll on a semaphore or a FIFO at a time. If a second thread tries to poll on the same semaphore or FIFO, :cpp:func:`k_poll()` immediately -returns with the return value :c:macro:`-EADDRINUSE`. In that case, if other +returns with the return value -:c:macro:`EADDRINUSE`. In that case, if other conditions passed to :cpp:func:`k_poll` were met, their state will be set in the corresponding poll event. In case of success, :cpp:func:`k_poll()` returns 0. If it times out, it returns -:c:macro:`-EAGAIN`. +-:c:macro:`EAGAIN`. .. code-block:: c @@ -179,7 +179,7 @@ One of the types of events is :c:macro:`K_POLL_TYPE_SIGNAL`: this is a "direct" signal to a poll event. This can be seen as a lightweight binary semaphore only one thread can wait for. -A poll signal is a separate object of type :c:type:`struct k_poll_signal` that +A poll signal is a separate object of type :c:type:`k_poll_signal` that must be attached to a k_poll_event, similar to a semaphore or FIFO. It must first be initialized either via :c:macro:`K_POLL_SIGNAL_INITIALIZER()` or :cpp:func:`k_poll_signal_init()`. diff --git a/doc/reference/kernel/other/ring_buffers.rst b/doc/reference/kernel/other/ring_buffers.rst index 40cc0b56bdc..3c618884802 100644 --- a/doc/reference/kernel/other/ring_buffers.rst +++ b/doc/reference/kernel/other/ring_buffers.rst @@ -117,7 +117,7 @@ Implementation Defining a Ring Buffer ====================== -A ring buffer is defined using a variable of type :c:type:`struct ring_buf`. +A ring buffer is defined using a variable of type :c:type:`ring_buf`. It must then be initialized by calling :cpp:func:`ring_buf_init()`. The following code defines and initializes an empty **data item mode** ring diff --git a/doc/reference/kernel/synchronization/mutexes.rst b/doc/reference/kernel/synchronization/mutexes.rst index 31b76e245cd..57b8ddd5dd9 100644 --- a/doc/reference/kernel/synchronization/mutexes.rst +++ b/doc/reference/kernel/synchronization/mutexes.rst @@ -93,7 +93,7 @@ Implementation Defining a Mutex ================ -A mutex is defined using a variable of type :c:type:`struct k_mutex`. +A mutex is defined using a variable of type :c:type:`k_mutex`. It must then be initialized by calling :cpp:func:`k_mutex_init()`. The following code defines and initializes a mutex. diff --git a/doc/reference/kernel/synchronization/semaphores.rst b/doc/reference/kernel/synchronization/semaphores.rst index a714ed28c47..3387ed24626 100644 --- a/doc/reference/kernel/synchronization/semaphores.rst +++ b/doc/reference/kernel/synchronization/semaphores.rst @@ -47,7 +47,7 @@ Implementation Defining a Semaphore ==================== -A semaphore is defined using a variable of type :c:type:`struct k_sem`. +A semaphore is defined using a variable of type :c:type:`k_sem`. It must then be initialized by calling :cpp:func:`k_sem_init()`. The following code defines a semaphore, then configures it as a binary diff --git a/doc/reference/kernel/threads/index.rst b/doc/reference/kernel/threads/index.rst index 48f35e15d4c..db576255972 100644 --- a/doc/reference/kernel/threads/index.rst +++ b/doc/reference/kernel/threads/index.rst @@ -24,7 +24,7 @@ A thread has the following key properties: stack memory regions. * A **thread control block** for private kernel bookkeeping of the thread's - metadata. This is an instance of type :c:type:`struct k_thread`. + metadata. This is an instance of type :c:type:`k_thread`. * An **entry point function**, which is invoked when the thread is started. Up to 3 **argument values** can be passed to this function. diff --git a/doc/reference/kernel/threads/workqueue.rst b/doc/reference/kernel/threads/workqueue.rst index 548ed0e377f..a1c28e150b9 100644 --- a/doc/reference/kernel/threads/workqueue.rst +++ b/doc/reference/kernel/threads/workqueue.rst @@ -179,7 +179,7 @@ Implementation Defining a Workqueue ==================== -A workqueue is defined using a variable of type :c:type:`struct k_work_q`. +A workqueue is defined using a variable of type :c:type:`k_work_q`. The workqueue is initialized by defining the stack area used by its thread and then calling :cpp:func:`k_work_q_start()`. The stack area must be defined using :c:macro:`K_THREAD_STACK_DEFINE` to ensure it is properly set up in @@ -202,7 +202,7 @@ The following code defines and initializes a workqueue. Submitting a Work Item ====================== -A work item is defined using a variable of type :c:type:`struct k_work`. +A work item is defined using a variable of type :c:type:`k_work`. It must then be initialized by calling :cpp:func:`k_work_init()`. An initialized work item can be submitted to the system workqueue by @@ -250,7 +250,7 @@ Submitting a Delayed Work Item ============================== A delayed work item is defined using a variable of type -:c:type:`struct k_delayed_work`. It must then be initialized by calling +:c:type:`k_delayed_work`. It must then be initialized by calling :cpp:func:`k_delayed_work_init()`. An initialized delayed work item can be submitted to the system workqueue by diff --git a/doc/reference/kernel/timing/timers.rst b/doc/reference/kernel/timing/timers.rst index ebbc677c8d3..286cd07401d 100644 --- a/doc/reference/kernel/timing/timers.rst +++ b/doc/reference/kernel/timing/timers.rst @@ -103,7 +103,7 @@ Implementation Defining a Timer ================ -A timer is defined using a variable of type :c:type:`struct k_timer`. +A timer is defined using a variable of type :c:type:`k_timer`. It must then be initialized by calling :cpp:func:`k_timer_init()`. The following code defines and initializes a timer. diff --git a/doc/reference/misc/notify.rst b/doc/reference/misc/notify.rst index 0a34dda87cb..f3431a14f6e 100644 --- a/doc/reference/misc/notify.rst +++ b/doc/reference/misc/notify.rst @@ -21,7 +21,7 @@ API. A limitation is that this API is not suitable for :ref:`syscalls` because: -* :c:type:`struct sys_notify` is not a kernel object; +* :c:type:`sys_notify` is not a kernel object; * copying the notification content from userspace will break use of :c:macro:`CONTAINER_OF` in the implementing function; * neither the spin-wait nor callback notification methods can be @@ -29,7 +29,7 @@ because: Where a notification is required for an asynchronous operation invoked from a user mode thread the subsystem or driver should provide a syscall -API that uses :c:type:`struct k_poll_signal` for notification. +API that uses :c:type:`k_poll_signal` for notification. API Reference ************* diff --git a/doc/reference/networking/lwm2m.rst b/doc/reference/networking/lwm2m.rst index e76c7930d5c..cfbfc8bf5c5 100644 --- a/doc/reference/networking/lwm2m.rst +++ b/doc/reference/networking/lwm2m.rst @@ -247,7 +247,7 @@ Sample usage ************ To use the LwM2M library, start by creating an LwM2M client context -:c:type:`struct lwm2m_ctx` structure: +:c:type:`lwm2m_ctx` structure: .. code-block:: c diff --git a/doc/reference/networking/net_l2.rst b/doc/reference/networking/net_l2.rst index 65f799ba9e1..49d862bc221 100644 --- a/doc/reference/networking/net_l2.rst +++ b/doc/reference/networking/net_l2.rst @@ -12,12 +12,12 @@ Overview The L2 stack is designed to hide the whole networking link-layer part and the related device drivers from the upper network stack. This is made -through a :c:type:`struct net_if` declared in +through a :c:type:`net_if` declared in :zephyr_file:`include/net/net_if.h`. The upper layers are unaware of implementation details beyond the net_if object and the generic API provided by the L2 layer in -:zephyr_file:`include/net/net_l2.h` as :c:type:`struct net_l2`. +:zephyr_file:`include/net/net_l2.h` as :c:type:`net_l2`. Only the L2 layer can talk to the device driver, linked to the net_if object. The L2 layer dictates the API provided by the device driver, @@ -39,7 +39,7 @@ See also :ref:`network stack architecture ` for more details. The generic L2 API has these functions: - ``recv()``: All device drivers, once they receive a packet which they put - into a :c:type:`struct net_pkt`, will push this buffer to the network + into a :c:type:`net_pkt`, will push this buffer to the network stack via :c:func:`net_recv_data()`. At this point, the network stack does not know what to do with it. Instead, it passes the buffer along to the L2 stack's ``recv()`` function for handling. @@ -69,13 +69,13 @@ basis. Please refer to :ref:`device_model_api`. There are, however, two differences: -- The driver_api pointer must point to a valid :c:type:`struct net_if_api` +- The driver_api pointer must point to a valid :c:type:`net_if_api` pointer. - The network device driver must use ``NET_DEVICE_INIT_INSTANCE()`` or ``ETH_NET_DEVICE_INIT()`` for Ethernet devices. These macros will call the ``DEVICE_AND_API_INIT()`` macro, and also - instantiate a unique :c:type:`struct net_if` related to the created + instantiate a unique :c:type:`net_if` related to the created device driver instance. Implementing a network device driver depends on the L2 stack it @@ -90,7 +90,7 @@ Ethernet device driver On reception, it is up to the device driver to fill-in the network packet with as many data buffers as required. The network packet itself is a -:c:type:`struct net_pkt` and should be allocated through +:c:type:`net_pkt` and should be allocated through :c:func:`net_pkt_rx_alloc_with_buffer()`. Then all data buffers will be automatically allocated and filled by :c:func:`net_pkt_write()`. @@ -116,9 +116,8 @@ Device drivers for IEEE 802.15.4 L2 work basically the same as for Ethernet. What has been described above, especially for ``recv()``, applies here as well. There are two specific differences however: -- It requires a dedicated device driver API: :c:type:`struct - ieee802154_radio_api`, which overloads :c:type:`struct - net_if_api`. This is because 802.15.4 L2 needs more from the device +- It requires a dedicated device driver API: :c:type:`ieee802154_radio_api`, + which overloads :c:type:`net_if_api`. This is because 802.15.4 L2 needs more from the device driver than just ``send()`` and ``recv()`` functions. This dedicated API is declared in :zephyr_file:`include/net/ieee802154_radio.h`. Each and every IEEE 802.15.4 device driver must provide a valid pointer on such @@ -129,15 +128,15 @@ here as well. There are two specific differences however: payload and frame checksum. Buffers are meant to fit such frame size limitation. But a buffer containing an IPv6/UDP packet might have more than one fragment. IEEE 802.15.4 drivers - handle only one buffer at a time. This is why the :c:type:`struct - ieee802154_radio_api` requires a tx function pointer which differs - from the :c:type:`struct net_if_api` send function pointer. + handle only one buffer at a time. This is why the + :c:type:`ieee802154_radio_api` requires a tx function pointer which differs + from the :c:type:`net_if_api` send function pointer. Instead, the IEEE 802.15.4 L2, provides a generic :c:func:`ieee802154_radio_send()` meant to be given as - :c:type:`struct net_if` send function. It turn, the implementation + :c:type:`net_if` send function. It turn, the implementation of :c:func:`ieee802154_radio_send()` will ensure the same behavior: - sending one buffer at a time through :c:type:`struct - ieee802154_radio_api` tx function, and unreferencing the network packet + sending one buffer at a time through :c:type:`ieee802154_radio_api` tx + function, and unreferencing the network packet only when all the transmission were successful. Each IEEE 802.15.4 device driver, in the end, will need to call diff --git a/doc/reference/networking/net_pkt.rst b/doc/reference/networking/net_pkt.rst index 2dca1b7761e..1714eaef040 100644 --- a/doc/reference/networking/net_pkt.rst +++ b/doc/reference/networking/net_pkt.rst @@ -74,7 +74,7 @@ Buffer allocation ================= The net_pkt object does not define its own buffer, but instead uses an -existing object for this: :c:type:`struct net_buf`. (See +existing object for this: :c:type:`net_buf`. (See :ref:`net_buf_interface` for more information). However, it mostly hides the usage of such a buffer because net_pkt brings network awareness to buffer allocation and, as we will see later, its diff --git a/doc/reference/peripherals/sensor.rst b/doc/reference/peripherals/sensor.rst index 7a15416ecd8..b7856418a45 100644 --- a/doc/reference/peripherals/sensor.rst +++ b/doc/reference/peripherals/sensor.rst @@ -29,7 +29,7 @@ description and units of measurement: Values ====== -Sensor devices return results as :c:type:`struct sensor_value`. This +Sensor devices return results as :c:type:`sensor_value`. This representation avoids use of floating point values as they may not be supported on certain setups. @@ -41,7 +41,7 @@ application instructs the driver to fetch a sample of all its channels. Then, individual channels may be read. In the case of channels with multiple axes, they can be read in a single operation by supplying the corresponding :literal:`_XYZ` channel type and a buffer of 3 -:c:type:`struct sensor_value` objects. This approach ensures consistency +:c:type:`sensor_value` objects. This approach ensures consistency of channels between reads and efficiency of communication by issuing a single transaction on the underlying bus. @@ -55,8 +55,8 @@ compensates data for both channels. :lines: 12- :linenos: -The example assumes that the returned values have type :c:type:`struct -sensor_value`, which is the case for BME280. A real application +The example assumes that the returned values have type :c:type:`sensor_value`, +which is the case for BME280. A real application supporting multiple sensors should inspect the :c:data:`type` field of the :c:data:`temp` and :c:data:`press` values and use the other fields of the structure accordingly. @@ -89,9 +89,9 @@ Many sensor chips support one or more triggers. Some examples of triggers include: new data is ready for reading, a channel value has crossed a threshold, or the device has sensed motion. -To configure a trigger, an application needs to supply a :c:type:`struct -sensor_trigger` and a handler function. The structure contains the trigger -type and the channel on which the trigger must be configured. +To configure a trigger, an application needs to supply a +:c:type:`sensor_trigger` and a handler function. The structure contains the +trigger type and the channel on which the trigger must be configured. Because most sensors are connected via SPI or I2C busses, it is not possible to communicate with them from the interrupt execution context. The diff --git a/doc/reference/usermode/kernelobjects.rst b/doc/reference/usermode/kernelobjects.rst index 258379e8e01..e692e7913bc 100644 --- a/doc/reference/usermode/kernelobjects.rst +++ b/doc/reference/usermode/kernelobjects.rst @@ -6,7 +6,7 @@ Kernel Objects A kernel object can be one of three classes of data: * A core kernel object, such as a semaphore, thread, pipe, etc. -* A thread stack, which is an array of :c:type:`struct z_thread_stack_element` +* A thread stack, which is an array of :c:type:`z_thread_stack_element` and declared with :c:macro:`K_THREAD_STACK_DEFINE()` * A device driver instance (struct device) that belongs to one of a defined set of subsystems @@ -109,14 +109,14 @@ When a system call is made and the kernel is presented with a memory address of what may or may not be a valid kernel object, the address can be validated with a constant-time lookup in this table. -Drivers are a special case. All drivers are instances of :c:type:`struct -device`, but it is important to know what subsystem a driver belongs to so that +Drivers are a special case. All drivers are instances of :c:type:`device`, but +it is important to know what subsystem a driver belongs to so that incorrect operations, such as calling a UART API on a sensor driver object, can be prevented. When a device struct is found, its API pointer is examined to determine what subsystem the driver belongs to. The table itself maps kernel object memory addresses to instances of -:c:type:`struct z_object`, which has all the metadata for that object. This +:c:type:`z_object`, which has all the metadata for that object. This includes: * A bitfield indicating permissions on that object. All threads have a @@ -129,7 +129,7 @@ includes: * A set of flags for that object. This is currently used to track initialization state and whether an object is public or not. * An extra data field. The semantics of this field vary by object type, see - the definition of :c:type:`union z_object_data`. + the definition of :c:type:`z_object_data`. Dynamic objects allocated at runtime are tracked in a runtime red/black tree which is used in parallel to the gperf table when validating object pointers. @@ -250,7 +250,7 @@ Instances of the new struct should now be tracked. Creating New Driver Subsystem Kernel Objects ============================================ -All driver instances are :c:type:`struct device`. They are differentiated by +All driver instances are :c:type:`device`. They are differentiated by what API struct they are set to. * In ``scripts/gen_kobject_list.py``, add the name of the API struct for the diff --git a/doc/reference/usermode/memory_domain.rst b/doc/reference/usermode/memory_domain.rst index 89cdd42d3bc..ae06f699ea1 100644 --- a/doc/reference/usermode/memory_domain.rst +++ b/doc/reference/usermode/memory_domain.rst @@ -324,7 +324,7 @@ Create a Memory Domain ---------------------- A memory domain is defined using a variable of type -:c:type:`struct k_mem_domain`. It must then be initialized by calling +:c:type:`k_mem_domain`. It must then be initialized by calling :cpp:func:`k_mem_domain_init()`. The following code defines and initializes an empty memory domain. diff --git a/include/kernel.h b/include/kernel.h index 6fc4e5725dd..1dae9d23891 100644 --- a/include/kernel.h +++ b/include/kernel.h @@ -4299,7 +4299,7 @@ struct k_pipe { struct { _wait_q_t readers; /**< Reader wait queue */ _wait_q_t writers; /**< Writer wait queue */ - } wait_q; + } wait_q; /** Wait queue */ _OBJECT_TRACING_NEXT_PTR(k_pipe) _OBJECT_TRACING_LINKED_FLAG