doc: fix misspelling in docs and API comments

Fix misspellings missed during regular reviews.

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

doc/development_process/code_flow.rst

@@ -26,7 +26,7 @@ Changes submitted to a development topic branch can evolve and improve
 incrementally in a branch, before they are submitted to the mainline tree for
 final integration.
 
-By dedicating an isolated branch to complex features, it’s
+By dedicating an isolated branch to complex features, it's
 possible to initiate in-depth discussions around new additions before
 integrating them into the official project.
 

doc/development_process/release_process.rst

@@ -100,7 +100,7 @@ Here is the description of the various moderation levels:
 
   - Bug Fixes, all priorities
   - Enhancements
-  - Minor “self-contained” New Features
+  - Minor "self-contained" New Features
 - High:
 
   - Bug Fixes: P1 and P2

doc/development_process/review_process.rst

@@ -8,7 +8,7 @@ Code Review
 
 GitHub is intended to provide a framework for reviewing every commit before it
 is accepted into the code base. Changes, in the form of Pull Requests (PR) are
-uploaded to GitHub but don’t actually become a part of the project until they’ve
+uploaded to GitHub but don't actually become a part of the project until they've
 been reviewed, passed a series of checks (CI), and are approved by maintainers.
 GitHub is used to support the standard open source practice of submitting
 patches, which are then reviewed by the project members before being applied to
@@ -31,7 +31,7 @@ changes are proposed using pull request, we need to allow for a minimal review
 time to give developers and contributors the opportunity to review and comment
 on changes. There are different categories of changes and we know that some
 changes do require reviews by subject matter experts and owners of the subsystem
-being changed. Many changes fall under the “trivial” category that can be
+being changed. Many changes fall under the "trivial" category that can be
 addressed with general reviews and do not need to be queued for a maintainer or
 code-owner review. Additionally, some changes might require further discussions
 and a decision by the TSC or the Security working group. To summarize the above,
@@ -134,7 +134,7 @@ Developers and contributors should always seek review, however there are cases
 when reviewers are not available and there is a need to get a code change into
 the tree as soon as possible.
 
-Reviewers shall not ‘Request Changes’ without comments or justification
+Reviewers shall not 'Request Changes' without comments or justification
 =======================================================================
 
 Any change requests (-1) on a pull request have to be justified. A reviewer

doc/guides/bluetooth/bluetooth-arch.rst

@@ -20,7 +20,7 @@ stack.
 BLE Layers
 ==========
 
-There are 3 main layers that together constitute a full Bluetooth Low Enery
+There are 3 main layers that together constitute a full Bluetooth Low Energy
 protocol stack:
 
 * **Host**: This layer sits right below the application, and is comprised of
@@ -75,12 +75,12 @@ following configurations are commonly used:
   configuration. This configuration allows for a wider variety of combinations of
   Hosts when using the Zephyr OS as a Controller. Since HCI ensures
   interoperability among Host and Controller implementations, including of course
-  Zephyr’s very own BLE Host and Controller, users of the Zephyr Controller can
+  Zephyr's very own BLE Host and Controller, users of the Zephyr Controller can
   choose to use whatever Host running on any platform they prefer. For example,
   the host can be the Linux BLE Host stack (BlueZ) running on any processor
   capable of supporting Linux. The Host processor may of course also run Zephyr
   and the Zephyr OS BLE Host. Conversely, combining an IC running the Zephyr
-  Host with an external Controller that does not run Zephyr is alos supported.
+  Host with an external Controller that does not run Zephyr is also supported.
 
 .. _bluetooth-build-types:
 
@@ -90,7 +90,7 @@ Build Types
 The Zephyr software stack as an RTOS is highly configurable, and in particular,
 the BLE subsystem can be configured in multiple ways during the build process to
 include only the features and layers that are required to reduce RAM and ROM
-footprint as well as power consumption. Here’s a short list of the different
+footprint as well as power consumption. Here's a short list of the different
 BLE-enabled builds that can be produced from the Zephyr project codebase:
 
 * **Controller-only build**: When built as a BLE Controller, Zephyr includes
@@ -166,7 +166,7 @@ the BLE Controller.
 
 This configuration is not limited to using a Zephyr OS Host, as the right side
 of the image shows. One can indeed take one of the many existing GNU/Linux
-distributions, most of which include Linux’s own BLE Host (BlueZ), to connect it
+distributions, most of which include Linux's own BLE Host (BlueZ), to connect it
 via UART or USB to one or more instances of the Zephyr OS Controller build.
 BlueZ as a Host supports multiple Controllers simultaneously for applications
 that require more than one BLE radio operating at the same time but sharing the
@@ -250,14 +250,14 @@ peripheral implicitly enables broadcaster role. Usually the first step
 when creating an application is to decide which roles are needed and go
 from there. Bluetooth Mesh is a slightly special case, requiring at
 least the observer and broadcaster roles, and possibly also the
-Peripheral role. This will be descibed in more detail in a later
+Peripheral role. This will be described in more detail in a later
 section.
 
 Peripheral role
 ===============
 
 Most Zephyr-based BLE devices will most likely be peripheral-role
-devices. This means that they peform connectable advertising and expose
+devices. This means that they perform connectable advertising and expose
 one or more GATT services. After registering services using the
 :cpp:func:`bt_gatt_service_register` API the application will typically
 start connectable advertising using the :cpp:func:`bt_le_adv_start` API.
@@ -268,7 +268,7 @@ such as :zephyr_file:`samples/bluetooth/peripheral_hr`.
 Central role
 ============
 
-Central role may not be as common for Zephyr-based devices as periphal
+Central role may not be as common for Zephyr-based devices as peripheral
 role, but it is still a plausible one and equally well supported in
 Zephyr. Rather than accepting connections from other devices a central
 role device will scan for available peripheral device and choose one to
@@ -313,7 +313,7 @@ are not exposed to the application, but a limited amount of information
 counted, and the application is expected to use the
 :cpp:func:`bt_conn_ref` API whenever storing a connection pointer for a
 longer period of time, since this ensures that the object remains valid
-(even if the connection would get disconnected). Similarily the
+(even if the connection would get disconnected). Similarly the
 :cpp:func:`bt_conn_unref` API is to be used when releasing a reference
 to a connection.
 
@@ -329,12 +329,12 @@ connection object through the return value of the
 Security
 ========
 
-To acheive a secure relationship between two Bluetooth devices a process
+To achieve a secure relationship between two Bluetooth devices a process
 called pairing is used. This process can either be triggered implicitly
 through the security properties of GATT services, or explicitly using
 the :cpp:func:`bt_conn_security` API on a connection object.
 
-To acheive a higher security level, and protect against
+To achieve a higher security level, and protect against
 Man-In-The-Middle (MITM) attacks, it is recommended to use some
 out-of-band channel during the pairing. If the devices have a sufficient
 user interface this "channel" is the user itself. The capabilities of
@@ -377,7 +377,7 @@ configuration option: :option:`CONFIG_BT_L2CAP_DYNAMIC_CHANNEL`. This channels
 support segmentation and reassembly transparently, they also support credit
 based flow control making it suitable for data streams.
 
-Channels instaces are represented by the :cpp:class:`bt_l2cap_chan` struct which
+Channels instances are represented by the :cpp:class:`bt_l2cap_chan` struct which
 contains the callbacks in the :cpp:class:`bt_l2cap_chan_ops` struct to inform
 when the channel has been connected, disconnected or when the encryption has
 changed.
@@ -467,7 +467,7 @@ Discover procedures can be initiated with the use of
 :cpp:func:`bt_gatt_discover` API which takes the
 :cpp:class:`bt_gatt_dicover_params` struct which describes the type of
 discovery. The parameters also serves as a filter when setting the ``uuid``
-field only attributes which matches will be discovered, in contranst setting it
+field only attributes which matches will be discovered, in contrast setting it
 to NULL allows all attributes to be discovered.
 
 .. note::
@@ -503,8 +503,8 @@ default, mesh requires both observer and broadcaster role to be enabled.
 If the optional GATT Proxy feature is desired, then peripheral role
 should also be enabled.
 
-Peristent storage
+Persistent storage
-=================
+==================
 
 The Bluetooth host stack uses the settings subsystem to implement
 persistent storage to flash. This requires the presence of a flash

doc/guides/porting/cmsis_rtos_v1.rst

@@ -4,7 +4,7 @@ CMSIS RTOS v1
 ##########################
 
 Cortex-M Software Interface Standard (CMSIS) RTOS is a vendor-independent
-hardware abstraction layer for the ARM Cortex®-M processor series and defines
+hardware abstraction layer for the ARM Cortex-M processor series and defines
 generic tool interfaces. Though it was originally defined for ARM Cortex-M
 microcontrollers alone, it could be easily extended to other microcontrollers
 making it generic. For more information on CMSIS RTOS v1, please refer

doc/guides/porting/cmsis_rtos_v2.rst

@@ -4,7 +4,7 @@ CMSIS RTOS v2
 ##########################
 
 Cortex-M Software Interface Standard (CMSIS) RTOS is a vendor-independent
-hardware abstraction layer for the ARM Cortex®-M processor series and defines
+hardware abstraction layer for the ARM Cortex-M processor series and defines
 generic tool interfaces. Though it was originally defined for ARM Cortex-M
 microcontrollers alone, it could be easily extended to other microcontrollers
 making it generic. For more information on CMSIS RTOS v2, please refer to the

doc/guides/west/repo-tool.rst

@@ -31,10 +31,10 @@ a multi-repo installation. When using upstream Zephyr, it looks like this:
 
    └── zephyrproject/
        ├── .west/
-       │   ├── config
+       │   ├── config
-       │   └── west/
+       │   └── west/
        ├── zephyr/
-       │   └── west.yml
+       │   └── west.yml
        ├── a-project
        └── ...
 
@@ -108,7 +108,7 @@ Rationale for a custom tool
 During the different stages of design and development for west, using already
 established and proven multi-repo technologies was considered multiple times.
 After careful analysis, no existing tool or mechanism was found suitable for
-Zephyr’s use case set and requirements. The following two tools were examined
+Zephyr's use case set and requirements. The following two tools were examined
 in detail:
 
 * Google repo
@@ -277,7 +277,7 @@ installation:
   to the revisions present in the manifest file.
 
 West's view of multirepo history looks like this example (though some parts of
-the example are specific to upstream Zephyr’s use of west):
+the example are specific to upstream Zephyr's use of west):
 
 .. figure:: west-mr-model.png
     :align: center
@@ -312,7 +312,7 @@ Notice a few important details about the above picture:
 - Two zephyr commits can have the same external commits (like ``F`` and ``G``).
 - Not all commits in some projects are associated with a zephyr commit (``P3``
   "jumps" multiple commits in its history between zephyr commits ``B → C``).
-- Every zephyr commit’s manifest refers to exactly one version in each of the
+- Every zephyr commit's manifest refers to exactly one version in each of the
   other projects it cares about.
 
 The ``manifest-rev`` branch

doc/reference/networking/coap.rst

@@ -22,7 +22,7 @@ is implemented using plain buffers. Users of the API create sockets
 for communication and pass the buffer to the library for parsing and other
 purposes. The library itself doesn't create any sockets for users.
 
-On top of CoAP, Zephyr has support for LWM2M “Lightweight Machine 2 Machine”
+On top of CoAP, Zephyr has support for LWM2M "Lightweight Machine 2 Machine"
 protocol, a simple, low-cost remote management and service enablement mechanism.
 See :ref:`lwm2m_interface` for more information.
 

doc/releases/release-notes-1.12.rst

@@ -788,7 +788,7 @@ These GitHub issues were closed since the previous 1.11.0 tagged release:
 * :github:`8150` - Doc: Update Zephyr security overview
 * :github:`8171` - Tests failing with a stacking error on frdm_k64f
 * :github:`8172` - Networking tests failing with an assertion on frdm_k64f
-* :github:`8180` - objcopy bug？
+* :github:`8180` - objcopy bug
 * :github:`8182` - Problem with obtaining hop_limit from a received packet
 * :github:`8189` - lwm2m: Quickly running out of resources when using observe
 * :github:`8192` - MPU Fault on some platforms after THREAD_MONITOR "fix"

doc/releases/release-notes-1.13.rst

@@ -348,7 +348,7 @@ release:
 * :github:`9574` - tests/cmsis_rtos_v1 - test_mutex_lock_timeout results in Assertion failure on all targets with PR#9569
 * :github:`9561` - Question: Does it support passing the bootloader(mcuboot) parameter to the kernel(zephyr)?
 * :github:`9558` - DTC 1.4.7 breaks at least FRDM_K64F builds
-* :github:`9537` - ENC28J60 can‘t receive packets properly
+* :github:`9537` - ENC28J60 can't receive packets properly
 * :github:`9536` - console: missing kernel.h include in header
 * :github:`9535` - broken callback handling in nrfx gpio driver
 * :github:`9530` - Bluetooth/gatt: bt_gatt_notify never return -ENOMEM, undocumented return value.
@@ -582,7 +582,7 @@ release:
 * :github:`8039` - tests/shell failing on Arduino 101 / Quark SE arc
 * :github:`8026` - Verify TLS server side operation
 * :github:`8019` - ARP: should drop any packet pended when timeout
-* :github:`8013` - Open-AMP：power on can not communicate
+* :github:`8013` - Open-AMP power on can not communicate
 * :github:`7999` - HCI UART with Linux host cannot connect to nrf52 6lowpan peripheral
 * :github:`7978` - SSE and SSE_FP_MATH are set on frdm_k64f, which doesn't have it, triggering Kconfig warnings
 * :github:`7977` - ARC_INIT is set on boards that don't have it, triggering Kconfig warnings

include/device.h

@@ -539,7 +539,7 @@ void device_pm_disable(struct device *dev);
  * the caller is interested in.
  * @retval 0 If successfully queued the Async request. If queued,
  * the caller need to wait on the poll event linked to device
- * pm signal mechanism to know the comepletion of resume operation.
+ * pm signal mechanism to know the completion of resume operation.
  * @retval Errno Negative errno code if failure.
  */
 int device_pm_get(struct device *dev);
@@ -570,7 +570,7 @@ int device_pm_get_sync(struct device *dev);
  * the caller is interested in.
  * @retval 0 If successfully queued the Async request. If queued,
  * the caller need to wait on the poll event linked to device pm
- * signal mechanism to know the comepletion of suspend operation.
+ * signal mechanism to know the completion of suspend operation.
  * @retval Errno Negative errno code if failure.
  */
 int device_pm_put(struct device *dev);

include/drivers/modem/modem_receiver.h

@@ -73,7 +73,7 @@ int mdm_receiver_send(struct mdm_receiver_context *ctx,
 /**
  * @brief  Registers receiver context.
  *
- * @note   Aquires receivers device, and prepares the context to be used.
+ * @note   Acquires receivers device, and prepares the context to be used.
  *
  * @param  *ctx: receiver context to register.
  * @param  *uart_dev_name: communication device for the receiver context.

include/misc/speculation.h

@@ -14,7 +14,7 @@
  * Spectre V1 vulnerability.
  *
  * CPUs with speculative execution may speculate past any size checks and
- * leak confidential data due to analyzsis of micro-architectural properties.
+ * leak confidential data due to analysis of micro-architectural properties.
  * This will unconditionally truncate any out-of-bounds indexes to
  * zero in the speculative execution path using bit twiddling instead of
  * any branch instructions.

include/net/lwm2m.h

@@ -261,7 +261,7 @@ int lwm2m_device_add_err(u8_t error_code);
 
 
 /**
- * @brief LWM2M Firemware Update object states
+ * @brief LWM2M Firmware Update object states
  *
  * An LwM2M client or the LwM2M Firmware Update object use the following codes
  * to represent the LwM2M Firmware Update state (5/0/3).
@@ -272,7 +272,7 @@ int lwm2m_device_add_err(u8_t error_code);
 #define STATE_UPDATING		3
 
 /**
- * @brief LWM2M Firemware Update object result codes
+ * @brief LWM2M Firmware Update object result codes
  *
  * After processing a firmware update, the client sets the result via one of
  * the following codes via lwm2m_engine_set_u8("5/0/5", [result code])
@@ -311,7 +311,7 @@ lwm2m_engine_set_data_cb_t lwm2m_firmware_get_write_cb(void);
  * @brief Set data callback to handle firmware update execute events.
  *
  * LwM2M clients use this function to register a callback for receiving the
- * update resource "execute" operation on the LwM2M Firmware Update oject.
+ * update resource "execute" operation on the LwM2M Firmware Update object.
  *
  * @param[in] cb A callback function to receive the execute event.
  */
@@ -655,7 +655,7 @@ int lwm2m_engine_register_read_callback(char *path,
  *
  * This callback is triggered before setting the value of a resource.  It
  * can pass a special data buffer to the engine so that the actual resource
- * value can be calulated later, etc.
+ * value can be calculated later, etc.
  *
  * @param[in] path LwM2M resource path string (obj/obj-instance/resource)
  * @param[in] cb Pre-write resource callback

samples/net/mqtt_publisher/README.rst

@@ -94,7 +94,7 @@ following macros to specify those values:
 	#define BLUEMIX_FORMAT		"json"
 
 On your Linux host computer, open a terminal window, locate the source code
-of this sample application (i.e. :zephyr_file:`samples/net/mqtt_publisher`) and type:
+of this sample application (i.e., :zephyr_file:`samples/net/mqtt_publisher`) and type:
 
 .. zephyr-app-commands::
    :zephyr-app: samples/net/mqtt_publisher
@@ -132,7 +132,7 @@ try this sample with TLS enabled, by following these steps:
   enabled on your platform and :option:`CONFIG_TLS_CREDENTIAL_FILENAMES` is
   set to ``y``).
 - In :file:`src/config.h`, set SERVER_ADDR to the IP address to connect to,
-  ie. the IP address of test.mosquitto.org ``"37.187.106.16"``
+  i.e., the IP address of test.mosquitto.org ``"37.187.106.16"``
 - In :file:`src/main.c`, set TLS_SNI_HOSTNAME to ``"test.mosquitto.org"``
   to match the Common Name (CN) in the downloaded certificate.
 - Build the sample by specifying ``-DOVERLAY_CONFIG=overlay-tls.conf``