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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <d50b58fe-298b-a285-59ec-2d3aa275d221@windriver.com>
Date:   Sat, 7 Aug 2021 21:57:08 +0800
From:   Jun Miao <jun.miao@...driver.com>
To:     Joe Perches <joe@...ches.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 8/7/21 9:21 PM, Joe Perches wrote:
> [Please note: This e-mail is from an EXTERNAL e-mail address]
>
> 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.

Ok, V2 : Suggested-by: Joe Perches <joe@...ches.com>

Thanks
Jun
>> diff --git a/drivers/atm/horizon.c b/drivers/atm/horizon.c
> []

What's mean this [] ?


>> @@ -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
>