[PATCH 00/24 v2] Documentation: correct lots of spelling errors (series 1)

[PATCH 00/24 v2] Documentation: correct lots of spelling errors (series 1)

[Randy Dunlap]

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 <corbet@lwn.net>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Vladimir Oltean <olteanv@gmail.com>
Cc: Steffen Klassert <steffen.klassert@secunet.com>
Cc: Daniel Jordan <daniel.m.jordan@oracle.com>
Cc: Akinobu Mita <akinobu.mita@gmail.com>
Cc: Helge Deller <deller@gmx.de>
?Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Henrik Rydberg <rydberg@bitmath.org>
Cc: Karsten Keil <isdn@linux-pingi.de>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Miroslav Benes <mbenes@suse.cz>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Josh Poimboeuf <jpoimboe@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Will Deacon <will@kernel.org>
Cc: Jérôme Glisse <jglisse@redhat.com>
Cc: Naoya Horiguchi <naoya.horiguchi@nec.com>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Cc: Jonas Bonn <jonas@southpole.se>
Cc: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
Cc: Stafford Horne <shorne@gmail.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Lorenzo Pieralisi <lpieralisi@kernel.org>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: Juri Lelli <juri.lelli@redhat.com>
Cc: Vincent Guittot <vincent.guittot@linaro.org>
Cc: David Howells <dhowells@redhat.com>
Cc: Jarkko Sakkinen <jarkko@kernel.org>
Cc: Paul Moore <paul@paul-moore.com>
Cc: James Morris <jmorris@namei.org>
Cc: "Serge E. Hallyn" <serge@hallyn.com>
Cc: Daniel Bristot de Oliveira <bristot@kernel.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Evgeniy Polyakov <zbr@ioremap.net>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: Reinette Chatre <reinette.chatre@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Chris Zankel <chris@zankel.net>
Cc: Max Filippov <jcmvbkbc@gmail.com>

Cc: coresight@lists.linaro.org
Cc: dri-devel@lists.freedesktop.org
Cc: keyrings@vger.kernel.org
Cc: linux-block@vger.kernel.org
Cc: linux-crypto@vger.kernel.org
Cc: linux-doc@vger.kernel.org
Cc: linux-fbdev@vger.kernel.org
Cc: linux-input@vger.kernel.org
Cc: linux-pci@vger.kernel.org
Cc: linux-s390@vger.kernel.org
Cc: linux-scsi@vger.kernel.org
Cc: linux-sgx@vger.kernel.org
Cc: linux-trace-devel@vger.kernel.org
Cc: linux-trace-kernel@vger.kernel.org
Cc: live-patching@vger.kernel.org
Cc: linux-security-module@vger.kernel.org
Cc: linux-usb@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: linux-mm@kvack.org
Cc: openrisc@lists.librecores.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-xtensa@linux-xtensa.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: x86@kernel.org

[PATCH 23/24] Documentation: x86: correct spelling

[Randy Dunlap]

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

Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Jarkko Sakkinen <jarkko@kernel.org>
Cc: linux-sgx@vger.kernel.org
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: Reinette Chatre <reinette.chatre@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: x86@kernel.org
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: linux-doc@vger.kernel.org
---
 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.

Re: [PATCH 23/24] Documentation: x86: correct spelling

[Reinette Chatre]

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 <rdunlap@infradead.org>
> Cc: Jarkko Sakkinen <jarkko@kernel.org>
> Cc: linux-sgx@vger.kernel.org
> Cc: Fenghua Yu <fenghua.yu@intel.com>
> Cc: Reinette Chatre <reinette.chatre@intel.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: x86@kernel.org
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: linux-doc@vger.kernel.org
> ---
>  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 <reinette.chatre@intel.com> #resctrl

Thank you very much

Reinette

Re: [PATCH 23/24] Documentation: x86: correct spelling

[Jarkko Sakkinen]

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 <rdunlap@infradead.org>
> Cc: Jarkko Sakkinen <jarkko@kernel.org>
> Cc: linux-sgx@vger.kernel.org
> Cc: Fenghua Yu <fenghua.yu@intel.com>
> Cc: Reinette Chatre <reinette.chatre@intel.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: x86@kernel.org
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: linux-doc@vger.kernel.org
> ---
>  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 <jarkko@kernel.org>

BR, Jarkko

Re: [PATCH 23/24] Documentation: x86: correct spelling

[Fenghua Yu]

On 2/8/23 23:13, Randy Dunlap wrote:
> Correct spelling problems for Documentation/x86/ as reported
> by codespell.
> 
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> Cc: Jarkko Sakkinen <jarkko@kernel.org>
> Cc: linux-sgx@vger.kernel.org
> Cc: Fenghua Yu <fenghua.yu@intel.com>
> Cc: Reinette Chatre <reinette.chatre@intel.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: x86@kernel.org
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: linux-doc@vger.kernel.org
> ---
>   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 <fenghua.yu@intel.com>

Thanks.

-Fenghua

Re: [PATCH 00/24 v2] Documentation: correct lots of spelling errors (series 1)

[patchwork-bot+netdevbpf]

Hello:

This series was applied to netdev/net-next.git (master)
by Jakub Kicinski <kuba@kernel.org>:

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

Re: [PATCH 23/24] Documentation: x86: correct spelling

[Huang, Kai]

> > 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 <jarkko@kernel.org>
> 
> BR, Jarkko

For SGX part:

Acked-by: Kai Huang <kai.huang@intel.com>

Re: [PATCH 00/24 v2] Documentation: correct lots of spelling errors (series 1)

[Krzysztof Wilczyński]

Hello,

> 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 13/24] Documentation: PCI: correct spelling
[...]

Applied to misc, thank you!

[1/1] Documentation: PCI: correct spelling
      https://git.kernel.org/pci/pci/c/b58d6d89ae02

	Krzysztof