From 5d8e367efe23915a879620bcec61b0d7c1c0c1e0 Mon Sep 17 00:00:00 2001 From: "David B. Kinder" Date: Wed, 27 Mar 2019 08:43:42 -0700 Subject: [PATCH] doc: fix misspelling in docs and API comments Fix misspellings missed during regular reviews. Signed-off-by: David B. Kinder --- boards/arm/stm32_min_dev/doc/index.rst | 2 +- doc/development_process/code_flow.rst | 2 +- doc/development_process/release_process.rst | 2 +- doc/development_process/review_process.rst | 6 ++--- doc/guides/bluetooth/bluetooth-arch.rst | 30 ++++++++++----------- doc/guides/porting/cmsis_rtos_v1.rst | 2 +- doc/guides/porting/cmsis_rtos_v2.rst | 2 +- doc/guides/west/repo-tool.rst | 12 ++++----- doc/reference/networking/coap.rst | 2 +- doc/releases/release-notes-1.12.rst | 2 +- doc/releases/release-notes-1.13.rst | 4 +-- include/device.h | 4 +-- include/drivers/modem/modem_receiver.h | 2 +- include/misc/speculation.h | 2 +- include/net/lwm2m.h | 8 +++--- samples/net/mqtt_publisher/README.rst | 4 +-- 16 files changed, 43 insertions(+), 43 deletions(-) diff --git a/boards/arm/stm32_min_dev/doc/index.rst b/boards/arm/stm32_min_dev/doc/index.rst index 1654098b4b..fcce8430d3 100644 --- a/boards/arm/stm32_min_dev/doc/index.rst +++ b/boards/arm/stm32_min_dev/doc/index.rst @@ -142,4 +142,4 @@ You can debug an application in the usual way. Here is an example for the .. _Black Pill Board: https://wiki.stm32duino.com/index.php?title=Black_Pill .. _EmbedJournal: - https://embedjournal.com/tag/stm32-min-dev/ \ No newline at end of file + https://embedjournal.com/tag/stm32-min-dev/ diff --git a/doc/development_process/code_flow.rst b/doc/development_process/code_flow.rst index 495848b4f1..b339f2add6 100644 --- a/doc/development_process/code_flow.rst +++ b/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. diff --git a/doc/development_process/release_process.rst b/doc/development_process/release_process.rst index 4338622c01..fb36207ae5 100644 --- a/doc/development_process/release_process.rst +++ b/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 diff --git a/doc/development_process/review_process.rst b/doc/development_process/review_process.rst index 93439ccc7c..c4012baadd 100644 --- a/doc/development_process/review_process.rst +++ b/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 diff --git a/doc/guides/bluetooth/bluetooth-arch.rst b/doc/guides/bluetooth/bluetooth-arch.rst index 22290dfad5..c2311bed6c 100644 --- a/doc/guides/bluetooth/bluetooth-arch.rst +++ b/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 diff --git a/doc/guides/porting/cmsis_rtos_v1.rst b/doc/guides/porting/cmsis_rtos_v1.rst index 47efef5b7c..a476ae699f 100644 --- a/doc/guides/porting/cmsis_rtos_v1.rst +++ b/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 diff --git a/doc/guides/porting/cmsis_rtos_v2.rst b/doc/guides/porting/cmsis_rtos_v2.rst index da81d0b2e6..4f36faf9b2 100644 --- a/doc/guides/porting/cmsis_rtos_v2.rst +++ b/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 diff --git a/doc/guides/west/repo-tool.rst b/doc/guides/west/repo-tool.rst index ebe0bd2c84..d052b4bc38 100644 --- a/doc/guides/west/repo-tool.rst +++ b/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 - │   └── west/ + │ ├── config + │ └── 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 diff --git a/doc/reference/networking/coap.rst b/doc/reference/networking/coap.rst index 7d346e6385..c8106b1c61 100644 --- a/doc/reference/networking/coap.rst +++ b/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. diff --git a/doc/releases/release-notes-1.12.rst b/doc/releases/release-notes-1.12.rst index fc93790f83..29034277e8 100644 --- a/doc/releases/release-notes-1.12.rst +++ b/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" diff --git a/doc/releases/release-notes-1.13.rst b/doc/releases/release-notes-1.13.rst index f40f204c71..33d9293138 100644 --- a/doc/releases/release-notes-1.13.rst +++ b/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 diff --git a/include/device.h b/include/device.h index 921cb3f694..9c19a70518 100644 --- a/include/device.h +++ b/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); diff --git a/include/drivers/modem/modem_receiver.h b/include/drivers/modem/modem_receiver.h index 714cb3f965..9c17e080da 100644 --- a/include/drivers/modem/modem_receiver.h +++ b/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. diff --git a/include/misc/speculation.h b/include/misc/speculation.h index 7532aba293..1b05e226e4 100644 --- a/include/misc/speculation.h +++ b/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. diff --git a/include/net/lwm2m.h b/include/net/lwm2m.h index 4256ffc503..e70951e858 100644 --- a/include/net/lwm2m.h +++ b/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 diff --git a/samples/net/mqtt_publisher/README.rst b/samples/net/mqtt_publisher/README.rst index 603ffd5545..409b8f602d 100644 --- a/samples/net/mqtt_publisher/README.rst +++ b/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``