diff --git a/doc/contribute/external.rst b/doc/contribute/external.rst index 14417bab0e3..b60f150f9fe 100644 --- a/doc/contribute/external.rst +++ b/doc/contribute/external.rst @@ -137,7 +137,7 @@ source code is the best solution, and the external source code is licensed under the Apache-2.0 license, the submission process is complete and the external source code can be integrated. -If, however, the esternal source code uses a license other than Apache-2.0, +If, however, the external source code uses a license other than Apache-2.0, then these additional steps must be followed: #. The TSC chair will forward the link to the GitHub issue created during the diff --git a/doc/contribute/index.rst b/doc/contribute/index.rst index 9dacacf5359..0eb08582eb1 100644 --- a/doc/contribute/index.rst +++ b/doc/contribute/index.rst @@ -215,7 +215,7 @@ on https://github.com and have Git tools available on your development system. are only available on Linux and macOS. On Windows, instead of running these tools yourself, you will need to rely on the Continuous Integration (CI) service ``buildkite``, which runs automatically on GitHub when you submit - your Pull Request (PR). You can see any failure results in the Shippable + your Pull Request (PR). You can see any failure results in the Buildkite details link near the end of the PR conversation list. See `Continuous Integration`_ for more information diff --git a/doc/reference/kernel/threads/index.rst b/doc/reference/kernel/threads/index.rst index db7abc29632..11d26a3f236 100644 --- a/doc/reference/kernel/threads/index.rst +++ b/doc/reference/kernel/threads/index.rst @@ -179,11 +179,11 @@ met: sized and aligned such that a memory protection region may be programmed to exactly fit. -The aligment constraints can be quite restrictive, for example some MPUs +The alignment constraints can be quite restrictive, for example some MPUs require their regions to be of some power of two in size, and aligned to its own size. -Becasue of this, portable code can't simply pass an arbitrary character buffer +Because of this, portable code can't simply pass an arbitrary character buffer to :c:func:`k_thread_create`. Special macros exist to instantiate stacks, prefixed with ``K_KERNEL_STACK`` and ``K_THREAD_STACK``. diff --git a/doc/reference/kernel/threads/workqueue.rst b/doc/reference/kernel/threads/workqueue.rst index c647ecbbb2f..16ad9213841 100644 --- a/doc/reference/kernel/threads/workqueue.rst +++ b/doc/reference/kernel/threads/workqueue.rst @@ -479,7 +479,7 @@ Many race conditions have been present in Zephyr code because the results of an operation were not checked. There may be good reason to believe that a return value indicating that the -operation did not complete as expected is not a problem. In thoses cases the +operation did not complete as expected is not a problem. In those cases the code should clearly document this, by (1) casting the return value to ``void`` to indicate that the result is intentionally ignored, and (2) documenting what happens in the unexpected case. For example: diff --git a/doc/reference/kernel/timing/clocks.rst b/doc/reference/kernel/timing/clocks.rst index 3489e9220a0..acb4ed5a2f5 100644 --- a/doc/reference/kernel/timing/clocks.rst +++ b/doc/reference/kernel/timing/clocks.rst @@ -33,7 +33,7 @@ CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC). For asynchronous timekeeping, the kernel defines a "ticks" concept. A "tick" is the internal count in which the kernel does all its internal -uptime and timeout bookeeping. Interrupts are expected to be +uptime and timeout bookkeeping. Interrupts are expected to be delivered on tick boundaries to the extent practical, and no fractional ticks are tracked. The choice of tick rate is configurable via :c:option:`CONFIG_SYS_CLOCK_TICKS_PER_SEC`. Defaults on most @@ -188,7 +188,7 @@ provide irregular interrupts. But a traditional, "ticked" or "dumb" counter driver can be trivially implemented also: * The driver can receive interrupts at a regular rate corresponding to - the OS tick rate, calling z_clock_anounce() with an argument of one + the OS tick rate, calling :c:func:`sys_clock_announce` with an argument of one each time. * The driver can ignore calls to :c:func:`sys_clock_set_timeout`, as every @@ -269,7 +269,7 @@ acceptable. One complexity is :c:macro:`K_FOREVER`. Subsystems that might have been able to accept this value to their millisecond API in the past no -longer can, becauase it is no longer an intergral type. Such code +longer can, because it is no longer an intergral type. Such code will need to use a different, integer-valued token to represent "forever". :c:macro:`K_NO_WAIT` has the same typesafety concern too, of course, but as it is (and has always been) simply a numerical zero, diff --git a/doc/reference/kernel/timing/timers.rst b/doc/reference/kernel/timing/timers.rst index 56291e969c6..b42c3a717a6 100644 --- a/doc/reference/kernel/timing/timers.rst +++ b/doc/reference/kernel/timing/timers.rst @@ -54,7 +54,7 @@ the **running** state and begins counting down towards expiry. Note that the timer's duration and period parameters specify **minimum** delays that will elapse. Because of internal system timer -precision (and potentially runtime interractions like interrupt delay) +precision (and potentially runtime interactions like interrupt delay) it is possible that more time may have passed as measured by reads from the relevant system time APIs. But at least this much time is guaranteed to have elapsed. diff --git a/doc/reference/usermode/memory_domain.rst b/doc/reference/usermode/memory_domain.rst index 2773d1eec20..e2f5b35c2cd 100644 --- a/doc/reference/usermode/memory_domain.rst +++ b/doc/reference/usermode/memory_domain.rst @@ -256,7 +256,7 @@ BSS. The build system will ensure that the base address of my_partition will be properly aligned, and the total size of the region conforms to the memory -management hardware requirments, adding padding if necessary. +management hardware requirements, adding padding if necessary. If multiple partitions are being created, a variadic preprocessor macro can be used as provided in ``app_macro_support.h``: diff --git a/doc/security/reporting.rst b/doc/security/reporting.rst index 76f40b1b04f..31ab0457118 100644 --- a/doc/security/reporting.rst +++ b/doc/security/reporting.rst @@ -50,7 +50,7 @@ number of states according to this diagram: - Release: The PR has been included in a released version of Zephyr. - Public: The embargo period has ended. The issue will be made - publically visible, the associated CVE updated, and the + publicly visible, the associated CVE updated, and the vulnerabilities page in the docs updated to include the detailed information. @@ -185,4 +185,4 @@ security vulnerabilities before the embargo period ends: members. - As needed, release managers and maintainers may be invited to attend - additional security meetings to discuss vulnerabilties. + additional security meetings to discuss vulnerabilities. diff --git a/doc/security/sensor-threat.rst b/doc/security/sensor-threat.rst index 98de9c6ebed..5f1a0ca4b47 100644 --- a/doc/security/sensor-threat.rst +++ b/doc/security/sensor-threat.rst @@ -398,7 +398,7 @@ Threats Reprovisioning a device shall be done securely. .. [th-destruction] - Upon decomissioning, the device secret shall be rendered + Upon decommissioning, the device secret shall be rendered ineffective. Notes diff --git a/doc/security/vulnerabilities.rst b/doc/security/vulnerabilities.rst index 191f9f19995..e683cb91648 100644 --- a/doc/security/vulnerabilities.rst +++ b/doc/security/vulnerabilities.rst @@ -6,7 +6,7 @@ Vulnerabilities This page collects all of the vulnerabilities that are discovered and fixed in each release. It will also often have more details than is available in the releases. Some vulnerabilities are deemed to be -sensitive, and will not be publically discussed until there is +sensitive, and will not be publicly discussed until there is sufficient time to fix them. Because the release notes are locked to a version, the information here can be updated after the embargo is lifted. @@ -51,7 +51,7 @@ CVE-2017-14202 -------------- The shell implementation does not protect against buffer overruns -resulting in unpredicable behavior. +resulting in unpredictable behavior. Improper Restriction of Operations within the Bounds of a Memory Buffer vulnerability in the shell component of Zephyr allows a serial diff --git a/kernel/Kconfig b/kernel/Kconfig index 3f5b48b5957..6e3e0792202 100644 --- a/kernel/Kconfig +++ b/kernel/Kconfig @@ -555,7 +555,7 @@ config SYS_CLOCK_TICKS_PER_SEC For asynchronous timekeeping, the kernel defines a "ticks" concept. A "tick" is the internal count in which the kernel does all its internal - uptime and timeout bookeeping. Interrupts are expected to be delivered + uptime and timeout bookkeeping. Interrupts are expected to be delivered on tick boundaries to the extent practical, and no fractional ticks are tracked. diff --git a/kernel/sched.c b/kernel/sched.c index edbabdad175..5e515162cc2 100644 --- a/kernel/sched.c +++ b/kernel/sched.c @@ -893,7 +893,7 @@ void *z_get_next_switch_handle(void *interrupted) #ifdef CONFIG_SPIN_VALIDATE /* Changed _current! Update the spinlock - * bookeeping so the validation doesn't get + * bookkeeping so the validation doesn't get * confused when the "wrong" thread tries to * release the lock. */ diff --git a/samples/userspace/shared_mem/src/enc.c b/samples/userspace/shared_mem/src/enc.c index b4648ca8118..e0496a1bbf7 100644 --- a/samples/userspace/shared_mem/src/enc.c +++ b/samples/userspace/shared_mem/src/enc.c @@ -19,7 +19,7 @@ * into the function. The output was compared to the original * pt text and matched. The result of the test matched the * expected outcome, but it does not validate the algorithm - * meets any security requirments. + * meets any security requirements. * * ********************************************************** *