Correct many spelling errors in Documentation/ as reported by codespell.
Maintainers of specific kernel subsystems are only Cc-ed on their
respective patches, not the entire series.
These patches are based on linux-next-20230209.
[PATCH 01/24] Documentation: arm: correct spelling
[PATCH 02/24] Documentation: block: correct spelling
[PATCH 03/24] Documentation: core-api: correct spelling
[PATCH 04/24] Documentation: fault-injection: correct spelling
[PATCH 05/24] Documentation: fb: correct spelling
[PATCH 06/24] Documentation: features: correct spelling
[PATCH 07/24] Documentation: input: correct spelling
[PATCH 08/24] Documentation: isdn: correct spelling
[PATCH 09/24] Documentation: livepatch: correct spelling
[PATCH 10/24] Documentation: locking: correct spelling
[PATCH 11/24] Documentation: mm: correct spelling
[PATCH 12/24] Documentation: openrisc: correct spelling
[PATCH 13/24] Documentation: PCI: correct spelling
[PATCH 14/24] Documentation: powerpc: correct spelling
[PATCH 15/24] Documentation: s390: correct spelling
[PATCH 16/24] Documentation: scheduler: correct spelling
[PATCH 17/24] Documentation: security: correct spelling
[PATCH 18/24] Documentation: timers: correct spelling
[PATCH 19/24] Documentation: tools/rtla: correct spelling
[PATCH 20/24] Documentation: trace/rv: correct spelling
[PATCH 21/24] Documentation: trace: correct spelling
[PATCH 22/24] Documentation: w1: correct spelling
[PATCH 23/24] Documentation: x86: correct spelling
[PATCH 24/24] Documentation: xtensa: correct spelling
diffstat:
Documentation/PCI/endpoint/pci-vntb-howto.rst | 2 +-
Documentation/PCI/msi-howto.rst | 2 +-
Documentation/arm/arm.rst | 2 +-
Documentation/arm/ixp4xx.rst | 4 ++--
Documentation/arm/keystone/knav-qmss.rst | 2 +-
Documentation/arm/stm32/stm32-dma-mdma-chaining.rst | 6 +++---
Documentation/arm/sunxi/clocks.rst | 2 +-
Documentation/arm/swp_emulation.rst | 2 +-
Documentation/arm/tcm.rst | 2 +-
Documentation/arm/vlocks.rst | 2 +-
Documentation/block/data-integrity.rst | 2 +-
Documentation/core-api/packing.rst | 2 +-
Documentation/core-api/padata.rst | 2 +-
Documentation/fault-injection/fault-injection.rst | 2 +-
Documentation/fb/sm712fb.rst | 2 +-
Documentation/fb/sstfb.rst | 2 +-
Documentation/features/core/thread-info-in-task/arch-support.txt | 2 +-
Documentation/input/devices/iforce-protocol.rst | 2 +-
Documentation/input/multi-touch-protocol.rst | 2 +-
Documentation/isdn/interface_capi.rst | 2 +-
Documentation/isdn/m_isdn.rst | 2 +-
Documentation/livepatch/reliable-stacktrace.rst | 2 +-
Documentation/locking/lockdep-design.rst | 4 ++--
Documentation/locking/locktorture.rst | 2 +-
Documentation/locking/locktypes.rst | 2 +-
Documentation/locking/preempt-locking.rst | 2 +-
Documentation/mm/hmm.rst | 4 ++--
Documentation/mm/hwpoison.rst | 2 +-
Documentation/openrisc/openrisc_port.rst | 4 ++--
Documentation/power/suspend-and-interrupts.rst | 2 +-
Documentation/powerpc/kasan.txt | 2 +-
Documentation/powerpc/papr_hcalls.rst | 2 +-
Documentation/powerpc/qe_firmware.rst | 4 ++--
Documentation/powerpc/vas-api.rst | 4 ++--
Documentation/s390/pci.rst | 4 ++--
Documentation/s390/vfio-ccw.rst | 2 +-
Documentation/scheduler/sched-bwc.rst | 2 +-
Documentation/scheduler/sched-energy.rst | 4 ++--
Documentation/security/digsig.rst | 4 ++--
Documentation/security/keys/core.rst | 2 +-
Documentation/security/secrets/coco.rst | 2 +-
Documentation/timers/hrtimers.rst | 2 +-
Documentation/tools/rtla/rtla-timerlat-top.rst | 2 +-
Documentation/trace/coresight/coresight-etm4x-reference.rst | 2 +-
Documentation/trace/events.rst | 6 +++---
Documentation/trace/fprobe.rst | 2 +-
Documentation/trace/ftrace-uses.rst | 2 +-
Documentation/trace/hwlat_detector.rst | 2 +-
Documentation/trace/rv/runtime-verification.rst | 2 +-
Documentation/trace/uprobetracer.rst | 2 +-
Documentation/w1/w1-netlink.rst | 2 +-
Documentation/x86/boot.rst | 2 +-
Documentation/x86/buslock.rst | 2 +-
Documentation/x86/mds.rst | 2 +-
Documentation/x86/resctrl.rst | 2 +-
Documentation/x86/sgx.rst | 2 +-
Documentation/xtensa/atomctl.rst | 2 +-
57 files changed, 70 insertions(+), 70 deletions(-)
Cc: Jonathan Corbet <[email protected]>
Cc: Russell King <[email protected]>
Cc: Jens Axboe <[email protected]>
Cc: Vladimir Oltean <[email protected]>
Cc: Steffen Klassert <[email protected]>
Cc: Daniel Jordan <[email protected]>
Cc: Akinobu Mita <[email protected]>
Cc: Helge Deller <[email protected]>
?Cc: "Rafael J. Wysocki" <[email protected]>
Cc: Dmitry Torokhov <[email protected]>
Cc: Henrik Rydberg <[email protected]>
Cc: Karsten Keil <[email protected]>
Cc: Jiri Kosina <[email protected]>
Cc: Miroslav Benes <[email protected]>
Cc: Petr Mladek <[email protected]>
Cc: Josh Poimboeuf <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Will Deacon <[email protected]>
Cc: Jérôme Glisse <[email protected]>
Cc: Naoya Horiguchi <[email protected]>
Cc: Miaohe Lin <[email protected]>
Cc: Jonas Bonn <[email protected]>
Cc: Stefan Kristiansson <[email protected]>
Cc: Stafford Horne <[email protected]>
Cc: Bjorn Helgaas <[email protected]>
Cc: Lorenzo Pieralisi <[email protected]>
Cc: Marc Zyngier <[email protected]>
Cc: Michael Ellerman <[email protected]>
Cc: Heiko Carstens <[email protected]>
Cc: Vasily Gorbik <[email protected]>
Cc: Alexander Gordeev <[email protected]>
Cc: Juri Lelli <[email protected]>
Cc: Vincent Guittot <[email protected]>
Cc: David Howells <[email protected]>
Cc: Jarkko Sakkinen <[email protected]>
Cc: Paul Moore <[email protected]>
Cc: James Morris <[email protected]>
Cc: "Serge E. Hallyn" <[email protected]>
Cc: Daniel Bristot de Oliveira <[email protected]>
Cc: Steven Rostedt <[email protected]>
Cc: Masami Hiramatsu <[email protected]>
Cc: Mathieu Poirier <[email protected]>
Cc: Suzuki K Poulose <[email protected]>
Cc: Evgeniy Polyakov <[email protected]>
Cc: Fenghua Yu <[email protected]>
Cc: Reinette Chatre <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: Chris Zankel <[email protected]>
Cc: Max Filippov <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Correct spelling problems for Documentation/xtensa/ as reported
by codespell.
Signed-off-by: Randy Dunlap <[email protected]>
Cc: Chris Zankel <[email protected]>
Cc: Max Filippov <[email protected]>
Cc: [email protected]
Cc: Jonathan Corbet <[email protected]>
Cc: [email protected]
Acked-by: Max Filippov <[email protected]>
---
Documentation/xtensa/atomctl.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -- a/Documentation/xtensa/atomctl.rst b/Documentation/xtensa/atomctl.rst
--- a/Documentation/xtensa/atomctl.rst
+++ b/Documentation/xtensa/atomctl.rst
@@ -23,7 +23,7 @@ doing a Cached (WB) transaction and use
operations.
For systems without an coherent cache controller, non-MX, we always
-use the memory controllers RCW, thought non-MX controlers likely
+use the memory controllers RCW, though non-MX controllers likely
support the Internal Operation.
CUSTOMER-WARNING:
Correct spelling problems for Documentation/x86/ as reported
by codespell.
Signed-off-by: Randy Dunlap <[email protected]>
Cc: Jarkko Sakkinen <[email protected]>
Cc: [email protected]
Cc: Fenghua Yu <[email protected]>
Cc: Reinette Chatre <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: [email protected]
Cc: Jonathan Corbet <[email protected]>
Cc: [email protected]
---
Documentation/x86/boot.rst | 2 +-
Documentation/x86/buslock.rst | 2 +-
Documentation/x86/mds.rst | 2 +-
Documentation/x86/resctrl.rst | 2 +-
Documentation/x86/sgx.rst | 2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
diff -- a/Documentation/x86/boot.rst b/Documentation/x86/boot.rst
--- a/Documentation/x86/boot.rst
+++ b/Documentation/x86/boot.rst
@@ -1105,7 +1105,7 @@ The kernel command line should not be lo
code, nor should it be located in high memory.
-Sample Boot Configuartion
+Sample Boot Configuration
=========================
As a sample configuration, assume the following layout of the real
diff -- a/Documentation/x86/buslock.rst b/Documentation/x86/buslock.rst
--- a/Documentation/x86/buslock.rst
+++ b/Documentation/x86/buslock.rst
@@ -32,7 +32,7 @@ mechanisms to detect split locks and bus
--------------------------------------
Beginning with the Tremont Atom CPU split lock operations may raise an
-Alignment Check (#AC) exception when a split lock operation is attemped.
+Alignment Check (#AC) exception when a split lock operation is attempted.
#DB exception for bus lock detection
------------------------------------
diff -- a/Documentation/x86/mds.rst b/Documentation/x86/mds.rst
--- a/Documentation/x86/mds.rst
+++ b/Documentation/x86/mds.rst
@@ -60,7 +60,7 @@ needed for exploiting MDS requires:
data
The existence of such a construct in the kernel cannot be excluded with
-100% certainty, but the complexity involved makes it extremly unlikely.
+100% certainty, but the complexity involved makes it extremely unlikely.
There is one exception, which is untrusted BPF. The functionality of
untrusted BPF is limited, but it needs to be thoroughly investigated
diff -- a/Documentation/x86/resctrl.rst b/Documentation/x86/resctrl.rst
--- a/Documentation/x86/resctrl.rst
+++ b/Documentation/x86/resctrl.rst
@@ -487,7 +487,7 @@ this would be dependent on number of cor
depending on # of threads:
For the same SKU in #1, a 'single thread, with 10% bandwidth' and '4
-thread, with 10% bandwidth' can consume upto 10GBps and 40GBps although
+thread, with 10% bandwidth' can consume up to 10GBps and 40GBps although
they have same percentage bandwidth of 10%. This is simply because as
threads start using more cores in an rdtgroup, the actual bandwidth may
increase or vary although user specified bandwidth percentage is same.
diff -- a/Documentation/x86/sgx.rst b/Documentation/x86/sgx.rst
--- a/Documentation/x86/sgx.rst
+++ b/Documentation/x86/sgx.rst
@@ -245,7 +245,7 @@ SGX will likely become unusable because
limited. However, while this may be fatal to SGX, the rest of the kernel
is unlikely to be impacted and should continue to work.
-As a result, when this happpens, user should stop running any new
+As a result, when this happens, the user should stop running any new
SGX workloads, (or just any new workloads), and migrate all valuable
workloads. Although a machine reboot can recover all EPC memory, the bug
should be reported to Linux developers.
Hi Randy,
On 2/8/2023 11:13 PM, Randy Dunlap wrote:
> Correct spelling problems for Documentation/x86/ as reported
> by codespell.
>
> Signed-off-by: Randy Dunlap <[email protected]>
> Cc: Jarkko Sakkinen <[email protected]>
> Cc: [email protected]
> Cc: Fenghua Yu <[email protected]>
> Cc: Reinette Chatre <[email protected]>
> Cc: Thomas Gleixner <[email protected]>
> Cc: Ingo Molnar <[email protected]>
> Cc: Borislav Petkov <[email protected]>
> Cc: [email protected]
> Cc: Jonathan Corbet <[email protected]>
> Cc: [email protected]
> ---
> Documentation/x86/boot.rst | 2 +-
> Documentation/x86/buslock.rst | 2 +-
> Documentation/x86/mds.rst | 2 +-
> Documentation/x86/resctrl.rst | 2 +-
> Documentation/x86/sgx.rst | 2 +-
> 5 files changed, 5 insertions(+), 5 deletions(-)
>
...
> diff -- a/Documentation/x86/resctrl.rst b/Documentation/x86/resctrl.rst
> --- a/Documentation/x86/resctrl.rst
> +++ b/Documentation/x86/resctrl.rst
> @@ -487,7 +487,7 @@ this would be dependent on number of cor
> depending on # of threads:
>
> For the same SKU in #1, a 'single thread, with 10% bandwidth' and '4
> -thread, with 10% bandwidth' can consume upto 10GBps and 40GBps although
> +thread, with 10% bandwidth' can consume up to 10GBps and 40GBps although
> they have same percentage bandwidth of 10%. This is simply because as
> threads start using more cores in an rdtgroup, the actual bandwidth may
> increase or vary although user specified bandwidth percentage is same.
Acked-by: Reinette Chatre <[email protected]> #resctrl
Thank you very much
Reinette
On Wed, Feb 08, 2023 at 11:13:59PM -0800, Randy Dunlap wrote:
> Correct spelling problems for Documentation/x86/ as reported
> by codespell.
>
> Signed-off-by: Randy Dunlap <[email protected]>
> Cc: Jarkko Sakkinen <[email protected]>
> Cc: [email protected]
> Cc: Fenghua Yu <[email protected]>
> Cc: Reinette Chatre <[email protected]>
> Cc: Thomas Gleixner <[email protected]>
> Cc: Ingo Molnar <[email protected]>
> Cc: Borislav Petkov <[email protected]>
> Cc: [email protected]
> Cc: Jonathan Corbet <[email protected]>
> Cc: [email protected]
> ---
> Documentation/x86/boot.rst | 2 +-
> Documentation/x86/buslock.rst | 2 +-
> Documentation/x86/mds.rst | 2 +-
> Documentation/x86/resctrl.rst | 2 +-
> Documentation/x86/sgx.rst | 2 +-
> 5 files changed, 5 insertions(+), 5 deletions(-)
>
> diff -- a/Documentation/x86/boot.rst b/Documentation/x86/boot.rst
> --- a/Documentation/x86/boot.rst
> +++ b/Documentation/x86/boot.rst
> @@ -1105,7 +1105,7 @@ The kernel command line should not be lo
> code, nor should it be located in high memory.
>
>
> -Sample Boot Configuartion
> +Sample Boot Configuration
> =========================
>
> As a sample configuration, assume the following layout of the real
> diff -- a/Documentation/x86/buslock.rst b/Documentation/x86/buslock.rst
> --- a/Documentation/x86/buslock.rst
> +++ b/Documentation/x86/buslock.rst
> @@ -32,7 +32,7 @@ mechanisms to detect split locks and bus
> --------------------------------------
>
> Beginning with the Tremont Atom CPU split lock operations may raise an
> -Alignment Check (#AC) exception when a split lock operation is attemped.
> +Alignment Check (#AC) exception when a split lock operation is attempted.
>
> #DB exception for bus lock detection
> ------------------------------------
> diff -- a/Documentation/x86/mds.rst b/Documentation/x86/mds.rst
> --- a/Documentation/x86/mds.rst
> +++ b/Documentation/x86/mds.rst
> @@ -60,7 +60,7 @@ needed for exploiting MDS requires:
> data
>
> The existence of such a construct in the kernel cannot be excluded with
> -100% certainty, but the complexity involved makes it extremly unlikely.
> +100% certainty, but the complexity involved makes it extremely unlikely.
>
> There is one exception, which is untrusted BPF. The functionality of
> untrusted BPF is limited, but it needs to be thoroughly investigated
> diff -- a/Documentation/x86/resctrl.rst b/Documentation/x86/resctrl.rst
> --- a/Documentation/x86/resctrl.rst
> +++ b/Documentation/x86/resctrl.rst
> @@ -487,7 +487,7 @@ this would be dependent on number of cor
> depending on # of threads:
>
> For the same SKU in #1, a 'single thread, with 10% bandwidth' and '4
> -thread, with 10% bandwidth' can consume upto 10GBps and 40GBps although
> +thread, with 10% bandwidth' can consume up to 10GBps and 40GBps although
> they have same percentage bandwidth of 10%. This is simply because as
> threads start using more cores in an rdtgroup, the actual bandwidth may
> increase or vary although user specified bandwidth percentage is same.
> diff -- a/Documentation/x86/sgx.rst b/Documentation/x86/sgx.rst
> --- a/Documentation/x86/sgx.rst
> +++ b/Documentation/x86/sgx.rst
> @@ -245,7 +245,7 @@ SGX will likely become unusable because
> limited. However, while this may be fatal to SGX, the rest of the kernel
> is unlikely to be impacted and should continue to work.
>
> -As a result, when this happpens, user should stop running any new
> +As a result, when this happens, the user should stop running any new
> SGX workloads, (or just any new workloads), and migrate all valuable
> workloads. Although a machine reboot can recover all EPC memory, the bug
> should be reported to Linux developers.
Acked-by: Jarkko Sakkinen <[email protected]>
BR, Jarkko
On 2/8/23 23:13, Randy Dunlap wrote:
> Correct spelling problems for Documentation/x86/ as reported
> by codespell.
>
> Signed-off-by: Randy Dunlap <[email protected]>
> Cc: Jarkko Sakkinen <[email protected]>
> Cc: [email protected]
> Cc: Fenghua Yu <[email protected]>
> Cc: Reinette Chatre <[email protected]>
> Cc: Thomas Gleixner <[email protected]>
> Cc: Ingo Molnar <[email protected]>
> Cc: Borislav Petkov <[email protected]>
> Cc: [email protected]
> Cc: Jonathan Corbet <[email protected]>
> Cc: [email protected]
> ---
> Documentation/x86/boot.rst | 2 +-
> Documentation/x86/buslock.rst | 2 +-
> Documentation/x86/mds.rst | 2 +-
> Documentation/x86/resctrl.rst | 2 +-
> Documentation/x86/sgx.rst | 2 +-
> 5 files changed, 5 insertions(+), 5 deletions(-)
>
> diff -- a/Documentation/x86/boot.rst b/Documentation/x86/boot.rst
> --- a/Documentation/x86/boot.rst
> +++ b/Documentation/x86/boot.rst
> @@ -1105,7 +1105,7 @@ The kernel command line should not be lo
> code, nor should it be located in high memory.
>
>
> -Sample Boot Configuartion
> +Sample Boot Configuration
> =========================
>
> As a sample configuration, assume the following layout of the real
> diff -- a/Documentation/x86/buslock.rst b/Documentation/x86/buslock.rst
> --- a/Documentation/x86/buslock.rst
> +++ b/Documentation/x86/buslock.rst
> @@ -32,7 +32,7 @@ mechanisms to detect split locks and bus
> --------------------------------------
>
> Beginning with the Tremont Atom CPU split lock operations may raise an
> -Alignment Check (#AC) exception when a split lock operation is attemped.
> +Alignment Check (#AC) exception when a split lock operation is attempted.
>
> #DB exception for bus lock detection
> ------------------------------------
> diff -- a/Documentation/x86/mds.rst b/Documentation/x86/mds.rst
> --- a/Documentation/x86/mds.rst
> +++ b/Documentation/x86/mds.rst
> @@ -60,7 +60,7 @@ needed for exploiting MDS requires:
> data
>
> The existence of such a construct in the kernel cannot be excluded with
> -100% certainty, but the complexity involved makes it extremly unlikely.
> +100% certainty, but the complexity involved makes it extremely unlikely.
>
> There is one exception, which is untrusted BPF. The functionality of
> untrusted BPF is limited, but it needs to be thoroughly investigated
> diff -- a/Documentation/x86/resctrl.rst b/Documentation/x86/resctrl.rst
> --- a/Documentation/x86/resctrl.rst
> +++ b/Documentation/x86/resctrl.rst
> @@ -487,7 +487,7 @@ this would be dependent on number of cor
> depending on # of threads:
>
> For the same SKU in #1, a 'single thread, with 10% bandwidth' and '4
> -thread, with 10% bandwidth' can consume upto 10GBps and 40GBps although
> +thread, with 10% bandwidth' can consume up to 10GBps and 40GBps although
> they have same percentage bandwidth of 10%. This is simply because as
> threads start using more cores in an rdtgroup, the actual bandwidth may
> increase or vary although user specified bandwidth percentage is same.
> diff -- a/Documentation/x86/sgx.rst b/Documentation/x86/sgx.rst
> --- a/Documentation/x86/sgx.rst
> +++ b/Documentation/x86/sgx.rst
> @@ -245,7 +245,7 @@ SGX will likely become unusable because
> limited. However, while this may be fatal to SGX, the rest of the kernel
> is unlikely to be impacted and should continue to work.
>
> -As a result, when this happpens, user should stop running any new
> +As a result, when this happens, the user should stop running any new
> SGX workloads, (or just any new workloads), and migrate all valuable
> workloads. Although a machine reboot can recover all EPC memory, the bug
> should be reported to Linux developers.
Acked-by: Fenghua Yu <[email protected]>
Thanks.
-Fenghua
Hello:
This series was applied to netdev/net-next.git (master)
by Jakub Kicinski <[email protected]>:
On Wed, 8 Feb 2023 23:13:36 -0800 you wrote:
> Correct many spelling errors in Documentation/ as reported by codespell.
>
> Maintainers of specific kernel subsystems are only Cc-ed on their
> respective patches, not the entire series.
>
> These patches are based on linux-next-20230209.
>
> [...]
Here is the summary with links:
- [03/24] Documentation: core-api: correct spelling
(no matching commit)
- [08/24] Documentation: isdn: correct spelling
https://git.kernel.org/netdev/net-next/c/d12f9ad02806
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
> > diff -- a/Documentation/x86/sgx.rst b/Documentation/x86/sgx.rst
> > --- a/Documentation/x86/sgx.rst
> > +++ b/Documentation/x86/sgx.rst
> > @@ -245,7 +245,7 @@ SGX will likely become unusable because
> > limited. However, while this may be fatal to SGX, the rest of the kernel
> > is unlikely to be impacted and should continue to work.
> >
> > -As a result, when this happpens, user should stop running any new
> > +As a result, when this happens, the user should stop running any new
> > SGX workloads, (or just any new workloads), and migrate all valuable
> > workloads. Although a machine reboot can recover all EPC memory, the bug
> > should be reported to Linux developers.
>
>
> Acked-by: Jarkko Sakkinen <[email protected]>
>
> BR, Jarkko
For SGX part:
Acked-by: Kai Huang <[email protected]>