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;
Message-ID: <7afa073ece002f84f4f2c28b3ac3032ded94bf43.camel@perches.com>
Subject: Re: [V2][PATCH] atm: horizon: Fix spelling mistakes in TX comment
From:   Joe Perches <joe@perches.com>
To:     Jun Miao <jun.miao@windriver.com>, 3chas3@gmail.com
Cc:     linux-atm-general@lists.sourceforge.net, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org
Date:   Sat, 07 Aug 2021 09:58:14 -0700
In-Reply-To: <20210807153830.1293760-1-jun.miao@windriver.com>
References: <20210807153830.1293760-1-jun.miao@windriver.com>
Content-Type: text/plain; charset="ISO-8859-1"
User-Agent: Evolution 3.40.0-1 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: bulk

On Sat, 2021-08-07 at 23:38 +0800, Jun Miao wrote:
> It's "must not", not "musn't", meaning "shall not".
> Let's fix that.
> 
> Suggested-by: Joe Perches <joe@perches.com>
> Signed-off-by: Jun Miao <jun.miao@windriver.com>
> ---
> ?drivers/atm/horizon.c | 6 +++---
> ?1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/atm/horizon.c b/drivers/atm/horizon.c
> index 4f2951cbe69c..9ee494bc5c51 100644
> --- a/drivers/atm/horizon.c
> +++ b/drivers/atm/horizon.c
> @@ -2167,10 +2167,10 @@ static int hrz_open (struct atm_vcc *atm_vcc)
> ???
> 
> ???// Part of the job is done by atm_pcr_goal which gives us a PCR
> ???// specification which says: EITHER grab the maximum available PCR
> -  // (and perhaps a lower bound which we musn't pass), OR grab this
> +  // (and perhaps a lower bound which we mustn't pass), OR grab this

I meant to suggest you change the patch to use "must not" not
the commit message.

> ???// amount, rounding down if you have to (and perhaps a lower bound
> -  // which we musn't pass) OR grab this amount, rounding up if you
> -  // have to (and perhaps an upper bound which we musn't pass). If any
> +  // which we mustn't pass) OR grab this amount, rounding up if you
> +  // have to (and perhaps an upper bound which we mustn't pass). If any
> ???// bounds ARE passed we fail. Note that rounding is only rounding to
> ???// match device limitations, we do not round down to satisfy
> ???// bandwidth availability even if this would not violate any given