Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Sun, 21 Mar 2021 16:41:53 -0700
User-Agent: K-9 Mail for Android
In-Reply-To: <20210321233108.3885240-1-unixbhaskar@gmail.com>
References: <20210321233108.3885240-1-unixbhaskar@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PATCH] hyperv: Few mundane typo fixes
To:     Bhaskar Chowdhury <unixbhaskar@gmail.com>, kys@microsoft.com,
        haiyangz@microsoft.com, sthemmin@microsoft.com, wei.liu@kernel.org,
        linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org
From:   Randy Dunlap <rdunlap@infradead.org>
Message-ID: <97467DD8-0B7A-4555-8334-4C3470909A2B@infradead.org>
Precedence: bulk

On March 21, 2021 4:31:08 PM PDT, Bhaskar Chowdhury <unixbhaskar@gmail=2Eco=
m> wrote:
>
>s/sructure/structure/
>s/extention/extension/
>s/offerred/offered/
>s/adversley/adversely/
>
>Signed-off-by: Bhaskar Chowdhury <unixbhaskar@gmail=2Ecom>

Acked-by: Randy Dunlap <rdunlap@infradead=2Eorg>

>---
> include/linux/hyperv=2Eh | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
>diff --git a/include/linux/hyperv=2Eh b/include/linux/hyperv=2Eh
>index f1d74dcf0353=2E=2E2c18c8e768ef 100644
>--- a/include/linux/hyperv=2Eh
>+++ b/include/linux/hyperv=2Eh
>@@ -284,7 +284,7 @@ struct vmbus_channel_offer {
>
> 		/*
> 		 * Pipes:
>-		 * The following sructure is an integrated pipe protocol, which
>+		 * The following structure is an integrated pipe protocol, which
> 		 * is implemented on top of standard user-defined data=2E Pipe
> 		 * clients have MAX_PIPE_USER_DEFINED_BYTES left for their own
> 		 * use=2E
>@@ -883,11 +883,11 @@ struct vmbus_channel {
> 	 * Support for sub-channels=2E For high performance devices,
> 	 * it will be useful to have multiple sub-channels to support
> 	 * a scalable communication infrastructure with the host=2E
>-	 * The support for sub-channels is implemented as an extention
>+	 * The support for sub-channels is implemented as an extension
> 	 * to the current infrastructure=2E
> 	 * The initial offer is considered the primary channel and this
> 	 * offer message will indicate if the host supports sub-channels=2E
>-	 * The guest is free to ask for sub-channels to be offerred and can
>+	 * The guest is free to ask for sub-channels to be offered and can
> 	 * open these sub-channels as a normal "primary" channel=2E However,
> 	 * all sub-channels will have the same type and instance guids as the
> 	 * primary channel=2E Requests sent on a given channel will result in a
>@@ -951,7 +951,7 @@ struct vmbus_channel {
> 	 * Clearly, these optimizations improve throughput at the expense of
> 	 * latency=2E Furthermore, since the channel is shared for both
> 	 * control and data messages, control messages currently suffer
>-	 * unnecessary latency adversley impacting performance and boot
>+	 * unnecessary latency adversely impacting performance and boot
> 	 * time=2E To fix this issue, permit tagging the channel as being
> 	 * in "low latency" mode=2E In this mode, we will bypass the monitor
> 	 * mechanism=2E
>--
>2=2E31=2E0


--=20
Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E