From 547c74cb3ce17826b04c84978bd86deebbaf81e8 Mon Sep 17 00:00:00 2001 From: "David B. Kinder" Date: Tue, 13 Jun 2017 15:16:40 -0700 Subject: [PATCH] doc: fix misspellings in docs Signed-off-by: David B. Kinder --- doc/dts/device_tree.rst | 2 +- doc/kernel/other/interrupts.rst | 2 +- doc/porting/arch.rst | 2 +- doc/subsystems/networking/l2-and-drivers.rst | 6 +++--- doc/subsystems/networking/network-management-api.rst | 2 +- 5 files changed, 7 insertions(+), 7 deletions(-) diff --git a/doc/dts/device_tree.rst b/doc/dts/device_tree.rst index 549594d20de..0c91bf01248 100644 --- a/doc/dts/device_tree.rst +++ b/doc/dts/device_tree.rst @@ -18,7 +18,7 @@ Rather than hard coding every detail of a board's hardware into the operating system, the hardware-describing DTB is passed to the operating system at boot time. This allows the same compiled Linux kernel to support different hardware configurations within an architecture family (e.g., ARM, -x86, PowerPC) and moves a significant part of the hardware description out of +x86, PowerPC) and moves a significant part of the hardware description out of the kernel binary itself. Traditional usage of device tree involves storing of the Device Tree Blob. diff --git a/doc/kernel/other/interrupts.rst b/doc/kernel/other/interrupts.rst index 6511ce8e30b..b47338196ab 100644 --- a/doc/kernel/other/interrupts.rst +++ b/doc/kernel/other/interrupts.rst @@ -277,7 +277,7 @@ which case the CONFIG_GEN_IRQ_VECTOR_TABLE option should be disabled. Some architectures may reserve some initial vectors for system exceptions and declare this in a table elsewhere, in which case -CONFIG_GEN_IRQ_START_VECTOR needs to be set to properly offset the indicies +CONFIG_GEN_IRQ_START_VECTOR needs to be set to properly offset the indices in the table. SW ISR Table diff --git a/doc/porting/arch.rst b/doc/porting/arch.rst index 6d14ba45a34..6d2dd82afdf 100644 --- a/doc/porting/arch.rst +++ b/doc/porting/arch.rst @@ -21,7 +21,7 @@ some are optional: take when the CPU comes out of reset (required). * **Interrupt and exception handling**: each architecture handles asynchronous - and un-requested events in a specific manner (required). + and unrequested events in a specific manner (required). * **Thread context switching**: the Zephyr context switch is dependent on the ABI and each ISA has a different set of registers to save (required). diff --git a/doc/subsystems/networking/l2-and-drivers.rst b/doc/subsystems/networking/l2-and-drivers.rst index 03324150d98..39d889aa8ae 100644 --- a/doc/subsystems/networking/l2-and-drivers.rst +++ b/doc/subsystems/networking/l2-and-drivers.rst @@ -90,14 +90,14 @@ parameter here. The Ethernet L2 layer will update such information once the packet's Ethernet header has been successfully parsed. In case :c:func:`net_recv_data()` call fails, it will be up to the -device driver to un-reference the buffer via +device driver to unreference the buffer via :c:func:`net_pkt_unref()`. On sending, it is up to the device driver to send the buffer all at once, with all the fragments. In case of a fully successful packet transmission only, the device -driver must un-reference the buffer via `net_pkt_unref()`. +driver must unreference the buffer via `net_pkt_unref()`. Each Ethernet device driver will need, in the end, to call `NET_DEVICE_INIT_INSTANCE()` like this: @@ -139,7 +139,7 @@ here as well. There are two specific differences however: :c:type:`struct net_if` send function. It turn, the implementation of :c:func:`ieee802154_radio_send()` will ensure the same behavior: sending one fragment at a time through :c:type:`struct - ieee802154_radio_api` tx function, and un-referencing the buffer + ieee802154_radio_api` tx function, and unreferencing the buffer 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/subsystems/networking/network-management-api.rst b/doc/subsystems/networking/network-management-api.rst index 43fb33d8c9a..525bc5c298c 100644 --- a/doc/subsystems/networking/network-management-api.rst +++ b/doc/subsystems/networking/network-management-api.rst @@ -44,7 +44,7 @@ more events that are relevant. Two functions are available, `net_mgmt_add_event_callback()` for registering the callback function, and `net_mgmt_del_event_callback()` -for un-registering. A helper function, `net_mgmt_init_event_cb()`, can +for unregistering. A helper function, `net_mgmt_init_event_cb()`, can be used to ease the initialization of the callback structure. When an event is raised that matches a registered event mask, the