Message-ID: <d5b5cf43-0dea-da68-1417-3d12e4a4bce8@intel.com>
Date:   Thu, 9 Feb 2023 20:19:22 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Firefox/91.0 Thunderbird/91.11.0
Subject: Re: [PATCH 23/24] Documentation: x86: correct spelling
Content-Language: en-US
To:     Randy Dunlap <rdunlap@infradead.org>,
        <linux-kernel@vger.kernel.org>
CC:     Jarkko Sakkinen <jarkko@kernel.org>, <linux-sgx@vger.kernel.org>,
        "Reinette Chatre" <reinette.chatre@intel.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        <x86@kernel.org>, Jonathan Corbet <corbet@lwn.net>,
        <linux-doc@vger.kernel.org>
References: <20230209071400.31476-1-rdunlap@infradead.org>
 <20230209071400.31476-24-rdunlap@infradead.org>
From:   Fenghua Yu <fenghua.yu@intel.com>
In-Reply-To: <20230209071400.31476-24-rdunlap@infradead.org>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?S1RzSGxKZFNQK2ZKTGdLM0x1RGJXME9LcHhDazdWa01OUjNxQkVtU2xEbmY4?=
 =?utf-8?B?OGF2czdxRVlBNGRITmdySzJISmFNdnU1bEIreE5nY2xTV1dkbk1jUTU5MURa?=
 =?utf-8?B?ZGR3ajFjMzdMYTk4M1lVZUVsb0p5R1VKVjR2WTUzZzd4a1ZZYUpodHlsRHpK?=
 =?utf-8?B?NmhrRjY1UTJUSmZyMi9sMjNBb1IvNm13TFFEUFJtRUMvYkdubGpzVmdSVGZq?=
 =?utf-8?B?OEJRWkJVcHMxbFBmSGM5bjR5LzFubmtHVWQ1S01WVnVXWTJpVnV1R3FSTG10?=
 =?utf-8?B?NVZweGZOZHZzOUcwdE5pTUF1by81NkVyQXNjamc1dUZYMDNZbGhJNDRJTUJI?=
 =?utf-8?B?TGo5a3JKNHpaVEEzOUxtT2s5WERjaER2Q2JzWlNZNDA4SlNTSXNHRGExeGhx?=
 =?utf-8?B?RXJ0WmVVY3hJUFRFNWt5QXlvcXdYSCs1a2RDYjN4TmR0UjhBZlEzd0M1Mzlw?=
 =?utf-8?B?b2NPdGtPc3V4Vk12SXY0YlFnVFdPcjljMzE2cHlnRlhpRUozUjhwNW90U2ZT?=
 =?utf-8?B?aTUwMW4yYkdwK1ZqNXJRanFjTDFEWVcvWXVtQjhSc0wwby9PSVhDNGhlVGlO?=
 =?utf-8?B?LzhOL1NqeXN0VnhNL3FqZi8vaVU4ajJzekJZUERKYTJRZXFKampsR0szdm1i?=
 =?utf-8?B?RkZoUzZBYlI5SmhPdVdITVBLUUpxbTBFcWp6TE5VRHl4N3VGYytGdWhTaFZ1?=
 =?utf-8?B?QW5yZkRDWkdkUFlobnFWU084UksxYkVXYzV2elFyOWxiNEtpbVB2V3N2bmZT?=
 =?utf-8?B?K0l1cGZObS9VcEw3MHNJeUxuT1RVSjN3RFY0MWtqN2J1YU1oSUphQk1lWHF0?=
 =?utf-8?B?bithWDNGR0s4VlU0MUVpT3BaYjcxektnTXdyQkpGQUZ4M1ltRFZ6K05NTVBP?=
 =?utf-8?B?ZVpKNnlydFRiQnFPMEhPamtDMjREdjlMQVZjVWdlZk01aVhTSlE4Q2ZNZGY0?=
 =?utf-8?B?b2dOdzMwTVBDSFRzazNJQ0M0YTg1VnYrY1d3VWsrZzNKUlhyODA5TTJoQzBS?=
 =?utf-8?B?dk5xajh5UExSWHlQQzJEZkZ6OU1BZjlnQlJvRWJCRTYzanNaQ2JzOWR6azNo?=
 =?utf-8?B?YzNxVGhBR2QvYlRrTXFkTmNXdHRYQXh4MWJ4c3g5RkVla2diNXFGNTdDT0ZS?=
 =?utf-8?B?Q1FaWmtIY2NQZnJUaUJrSFoxUGpoTnhZMjRwcTN6R1k1UXgvdm4rV3dmaGlS?=
 =?utf-8?B?TVVodyt4YzFKenVoN0U5V240eVNhK1piWDc1WkpZemxRbWVIZTJONVpWWFZW?=
 =?utf-8?B?Y09yTXBHWnVXQmwyOHhBUEFpM3FkM01xMXJKdmFUZ0psVFBERUNUcG9wbks2?=
 =?utf-8?B?WGdOS29SQW9pVUg2K2c1Z2x3cFV5UXFoVVFWUkZ3QlFKOHpacUpEeTc2TjFq?=
 =?utf-8?B?TmN0Q1JxTHJkcHlwVVhsRU00aU5lYlBJN0xDZEllRHZKbzJLTXY4NkhLWmxq?=
 =?utf-8?B?Yzg4VGlBUXc3Y1ZPSnIxRHdRbklEaFZHRzFuTDR0dEJyUXFqekxPaWl5WmxZ?=
 =?utf-8?B?VTRkZTVxNTVIN21MY0lkQU84bXV6aUhHVDE5cU5XcVhQa1VZT2xmVWVhMG9B?=
 =?utf-8?B?bXlISThLQ1NKUzNERzl3U04xZzJRb1M5dUg5THRKZVFQUlJYNjlhVTNpRzVS?=
 =?utf-8?B?WnBEVjJBQzJGbVEzR1dRVlkrLy9RTTlOTEZhNWVWczh1cnJVUXQvME0yZlB0?=
 =?utf-8?B?dmJiSVV4dm5EUHRydUp4eENaU3FEb1NaODRxbkhmQTJJV0lFZmIxcTZNakpw?=
 =?utf-8?B?VytxVk15YWswY3BWM2VPTmhwZDAwdnBnRndUcEdVUm5lQXFtY0pTWFJ6T1RQ?=
 =?utf-8?B?VFdKMWQyYVpma2ovRGNBaG81SWFPNHRrQ2VOWlZ6Q0FZa2tKRitqczhKdnRG?=
 =?utf-8?B?bkRVNVhNVmpvSm9YekhaSkFWek90STY3Nm9ZTGtjWXJ1THZDV0tJaUZaaVZv?=
 =?utf-8?B?V2pkNjdoMVJzTkpGaC85cGFHaHFHZzlVc0pQemFPY2w2aFB5WitCOVh6cSti?=
 =?utf-8?B?cXZIck83VlB5RFNpdGQ2dlhNZ2VzSnN6VUdJRDlvNVJ1MFZacFloQmJRLy93?=
 =?utf-8?B?aE9QWUZtUHdONnpTSyt4ZGdVY2JLYzM0YWcwSlExSXorVkVtNVpGM29JNVdG?=
 =?utf-8?B?UVlKa1puSlgzZzg4L09rMXZrZktnVy9IZitDdm5BZHFsZDN6NjA0dWhRa0Rs?=
 =?utf-8?B?aGc9PQ==?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 1771026e-436d-4ffe-ab9b-08db0b1dfcc5
X-MS-Exchange-CrossTenant-AuthSource: IA1PR11MB6097.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Feb 2023 04:19:22.8014
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: u7IN10YdSEFoWw6/2FBYc7oe7uFroJrBNuPUrK0MkynFdF7XTz/+obmyK8PSqC0F0MiunxGtSXv53QKzwcOfPg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR11MB6041
X-OriginatorOrg: intel.com
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


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