diff mbox series

[01/35] Documentation: arm64: correct spelling

Message ID	20230127064005.1558-3-rdunlap@infradead.org
State	New
Headers	Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; From: Randy Dunlap <rdunlap@infradead.org> To: linux-kernel@vger.kernel.org Cc: Randy Dunlap <rdunlap@infradead.org>, Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>, linux-arm-kernel@lists.infradead.org, Jonathan Corbet <corbet@lwn.net>, linux-doc@vger.kernel.org Subject: [PATCH 01/35] Documentation: arm64: correct spelling Date: Thu, 26 Jan 2023 22:39:32 -0800 Message-Id: <20230127064005.1558-3-rdunlap@infradead.org> In-Reply-To: <20230127064005.1558-1-rdunlap@infradead.org> References: <20230127064005.1558-1-rdunlap@infradead.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk
Series	Documentation: correct lots of spelling errors (series 1) \| [00/35] Documentation: correct lots of spelling errors (series 1) [02/35] Documentation: arm: correct spelling [01/35] Documentation: arm64: correct spelling [03/35] Documentation: block: correct spelling [04/35] Documentation: bpf: correct spelling [05/35] Documentation: core-api: correct spelling [06/35] Documentation: fault-injection: correct spelling [07/35] Documentation: fb: correct spelling [08/35] Documentation: features: correct spelling [09/35] Documentation: firmware-guide/acpi: correct spelling [10/35] Documentation: hid: correct spelling [11/35] Documentation: i2c: correct spelling [12/35] Documentation: input: correct spelling [13/35] Documentation: isdn: correct spelling [14/35] Documentation: leds: correct spelling [15/35] Documentation: litmus-tests: correct spelling [16/35] Documentation: livepatch: correct spelling [17/35] Documentation: locking: correct spelling [18/35] Documentation: mm: correct spelling [19/35] Documentation: openrisc: correct spelling [20/35] Documentation: PCI: correct spelling [22/35] Documentation: power: correct spelling [21/35] Documentation: powerpc: correct spelling [23/35] Documentation: s390: correct spelling [24/35] Documentation: scheduler: correct spelling [25/35] Documentation: security: correct spelling [26/35] Documentation: sound: correct spelling [27/35] Documentation: spi: correct spelling [28/35] Documentation: target: correct spelling [29/35] Documentation: timers: correct spelling [30/35] Documentation: tools/rtla: correct spelling [31/35] Documentation: trace: correct spelling [32/35] Documentation: usb: correct spelling [33/35] Documentation: w1: correct spelling [34/35] Documentation: x86: correct spelling [35/35] Documentation: xtensa: correct spelling

Commit Message

Randy Dunlap Jan. 27, 2023, 6:39 a.m. UTC

  Correct spelling problems for Documentation/arm64/ as reported
by codespell.

Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: linux-doc@vger.kernel.org
---
 Documentation/arm64/booting.rst    |    2 +-
 Documentation/arm64/elf_hwcaps.rst |    2 +-
 Documentation/arm64/sve.rst        |    4 ++--
 3 files changed, 4 insertions(+), 4 deletions(-)

Comments

Mukesh Ojha Jan. 27, 2023, 7:02 a.m. UTC | #1

On 1/27/2023 12:09 PM, Randy Dunlap wrote:
> Correct spelling problems for Documentation/arm64/ as reported
> by codespell.
> 
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: linux-doc@vger.kernel.org
> ---
>   Documentation/arm64/booting.rst    |    2 +-
>   Documentation/arm64/elf_hwcaps.rst |    2 +-
>   Documentation/arm64/sve.rst        |    4 ++--
>   3 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff -- a/Documentation/arm64/booting.rst b/Documentation/arm64/booting.rst
> --- a/Documentation/arm64/booting.rst
> +++ b/Documentation/arm64/booting.rst
> @@ -223,7 +223,7 @@ Before jumping into the kernel, the foll
>     For systems with a GICv3 interrupt controller to be used in v3 mode:
>     - If EL3 is present:
>   
> -      - ICC_SRE_EL3.Enable (bit 3) must be initialiased to 0b1.
> +      - ICC_SRE_EL3.Enable (bit 3) must be initialised to 0b1.
>         - ICC_SRE_EL3.SRE (bit 0) must be initialised to 0b1.
>         - ICC_CTLR_EL3.PMHE (bit 6) must be set to the same value across
>           all CPUs the kernel is executing on, and must stay constant
> diff -- a/Documentation/arm64/elf_hwcaps.rst b/Documentation/arm64/elf_hwcaps.rst
> --- a/Documentation/arm64/elf_hwcaps.rst
> +++ b/Documentation/arm64/elf_hwcaps.rst
> @@ -14,7 +14,7 @@ Some hardware or software features are o
>   implementations, and/or with certain kernel configurations, but have no
>   architected discovery mechanism available to userspace code at EL0. The
>   kernel exposes the presence of these features to userspace through a set
> -of flags called hwcaps, exposed in the auxilliary vector.
> +of flags called hwcaps, exposed in the auxiliary vector.
>   
>   Userspace software can test for features by acquiring the AT_HWCAP or
>   AT_HWCAP2 entry of the auxiliary vector, and testing whether the relevant
> diff -- a/Documentation/arm64/sve.rst b/Documentation/arm64/sve.rst
> --- a/Documentation/arm64/sve.rst
> +++ b/Documentation/arm64/sve.rst
> @@ -175,7 +175,7 @@ the SVE instruction set architecture.
>   When returning from a signal handler:
>   
>   * If there is no sve_context record in the signal frame, or if the record is
> -  present but contains no register data as desribed in the previous section,
> +  present but contains no register data as described in the previous section,
>     then the SVE registers/bits become non-live and take unspecified values.
>   
>   * If sve_context is present in the signal frame and contains full register
> @@ -223,7 +223,7 @@ prctl(PR_SVE_SET_VL, unsigned long arg)
>   	    Defer the requested vector length change until the next execve()
>   	    performed by this thread.
>   
> -	    The effect is equivalent to implicit exceution of the following
> +	    The effect is equivalent to implicit execution of the following
>   	    call immediately after the next execve() (if any) by the thread:
>   
>   		prctl(PR_SVE_SET_VL, arg & ~PR_SVE_SET_VL_ONEXEC)
> 

Reviewed-by: Mukesh Ojha <quic_mojha@quicinc.com>

-Mukesh

> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

diff mbox series

Patch

diff -- a/Documentation/arm64/booting.rst b/Documentation/arm64/booting.rst
--- a/Documentation/arm64/booting.rst
+++ b/Documentation/arm64/booting.rst
@@ -223,7 +223,7 @@  Before jumping into the kernel, the foll
   For systems with a GICv3 interrupt controller to be used in v3 mode:
   - If EL3 is present:
 
-      - ICC_SRE_EL3.Enable (bit 3) must be initialiased to 0b1.
+      - ICC_SRE_EL3.Enable (bit 3) must be initialised to 0b1.
       - ICC_SRE_EL3.SRE (bit 0) must be initialised to 0b1.
       - ICC_CTLR_EL3.PMHE (bit 6) must be set to the same value across
         all CPUs the kernel is executing on, and must stay constant
diff -- a/Documentation/arm64/elf_hwcaps.rst b/Documentation/arm64/elf_hwcaps.rst
--- a/Documentation/arm64/elf_hwcaps.rst
+++ b/Documentation/arm64/elf_hwcaps.rst
@@ -14,7 +14,7 @@  Some hardware or software features are o
 implementations, and/or with certain kernel configurations, but have no
 architected discovery mechanism available to userspace code at EL0. The
 kernel exposes the presence of these features to userspace through a set
-of flags called hwcaps, exposed in the auxilliary vector.
+of flags called hwcaps, exposed in the auxiliary vector.
 
 Userspace software can test for features by acquiring the AT_HWCAP or
 AT_HWCAP2 entry of the auxiliary vector, and testing whether the relevant
diff -- a/Documentation/arm64/sve.rst b/Documentation/arm64/sve.rst
--- a/Documentation/arm64/sve.rst
+++ b/Documentation/arm64/sve.rst
@@ -175,7 +175,7 @@  the SVE instruction set architecture.
 When returning from a signal handler:
 
 * If there is no sve_context record in the signal frame, or if the record is
-  present but contains no register data as desribed in the previous section,
+  present but contains no register data as described in the previous section,
   then the SVE registers/bits become non-live and take unspecified values.
 
 * If sve_context is present in the signal frame and contains full register
@@ -223,7 +223,7 @@  prctl(PR_SVE_SET_VL, unsigned long arg)
 	    Defer the requested vector length change until the next execve()
 	    performed by this thread.
 
-	    The effect is equivalent to implicit exceution of the following
+	    The effect is equivalent to implicit execution of the following
 	    call immediately after the next execve() (if any) by the thread:
 
 		prctl(PR_SVE_SET_VL, arg & ~PR_SVE_SET_VL_ONEXEC)