linux-kernel - Re: [PATCH] atm: horizon: Fix spelling mistakes in TX comment

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <0b52c87bb939fe45c1cf07fe9c3409e927138046.camel@perches.com>
Date:   Sat, 07 Aug 2021 06:21:53 -0700
From:   Joe Perches <joe@...ches.com>
To:     Jun Miao <jun.miao@...driver.com>, 3chas3@...il.com
Cc:     linux-atm-general@...ts.sourceforge.net, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] atm: horizon: Fix spelling mistakes in TX comment

On Sat, 2021-08-07 at 20:49 +0800, Jun Miao wrote:
> It's "mustn't", not "musn't", meaning "shall not".
> Let's fix that.

Perhaps more useful to change to 'must not' for the
non-native speaker.
 
> diff --git 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
>    // 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