It's "must not", not "musn't", meaning "shall not".
Let's fix that.
Suggested-by: Joe Perches <[email protected]>
Signed-off-by: Jun Miao <[email protected]>
---
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
// 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
--
2.32.0
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 <[email protected]>
> Signed-off-by: Jun Miao <[email protected]>
> ---
> ?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
On 8/8/21 12:58 AM, Joe Perches wrote:
> [Please note: This e-mail is from an EXTERNAL e-mail address]
>
> 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 <[email protected]>
>> Signed-off-by: Jun Miao <[email protected]>
>> ---
>> 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.
Please ignore this e-mail. Sorry, confuse the mailing list.
I am so careless to forget change there. After this 2 minutest, i send
new same V2(in fact should v3 but forgive for a freshman)
>> // 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
>