doc: fix misspellings in docs

Signed-off-by: David B. Kinder <david.b.kinder@intel.com>

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.

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

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).

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

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