| Message ID | 20210607031537.12366-1-thunder.leizhen@huawei.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [1/1] lib/test: Fix spelling mistakes | expand |
On Mon, Jun 7, 2021 at 6:21 AM Zhen Lei <thunder.leizhen@huawei.com> wrote: > Fix some spelling mistakes in comments: > thats ==> that's > unitialized ==> uninitialized > panicing ==> panicking > sucess ==> success > possitive ==> positive > intepreted ==> interpreted Thanks for the fix! Is it done with the help of the codespell tool? If not, can you run it and check if it suggests more fixes? -- With Best Regards, Andy Shevchenko
On 2021/6/7 16:39, Andy Shevchenko wrote: > On Mon, Jun 7, 2021 at 6:21 AM Zhen Lei <thunder.leizhen@huawei.com> wrote: > >> Fix some spelling mistakes in comments: >> thats ==> that's >> unitialized ==> uninitialized >> panicing ==> panicking >> sucess ==> success >> possitive ==> positive >> intepreted ==> interpreted > > Thanks for the fix! Is it done with the help of the codespell tool? If > not, can you run it and check if it suggests more fixes? Yes, it's detected by codespell tool. But to avoid too many changes in one patch, I tried breaking it down into smaller patches(If it can be classified) to make it easier to review. In fact, the other patch I just posted included the rest. >
On 2021/6/7 16:52, Leizhen (ThunderTown) wrote: > > > On 2021/6/7 16:39, Andy Shevchenko wrote: >> On Mon, Jun 7, 2021 at 6:21 AM Zhen Lei <thunder.leizhen@huawei.com> wrote: >> >>> Fix some spelling mistakes in comments: >>> thats ==> that's >>> unitialized ==> uninitialized >>> panicing ==> panicking >>> sucess ==> success >>> possitive ==> positive >>> intepreted ==> interpreted >> >> Thanks for the fix! Is it done with the help of the codespell tool? If >> not, can you run it and check if it suggests more fixes? > > Yes, it's detected by codespell tool. But to avoid too many changes in one patch, I tried > breaking it down into smaller patches(If it can be classified) to make it easier to review. > In fact, the other patch I just posted included the rest. https://lkml.org/lkml/2021/6/7/151 All the remaining spelling mistakes are fixed by the patch above. I can combine the two of them into one patch if you think it's necessary. > > > > >>
On Mon, Jun 7, 2021 at 11:56 AM Leizhen (ThunderTown) <thunder.leizhen@huawei.com> wrote: > On 2021/6/7 16:52, Leizhen (ThunderTown) wrote: > > On 2021/6/7 16:39, Andy Shevchenko wrote: > >> On Mon, Jun 7, 2021 at 6:21 AM Zhen Lei <thunder.leizhen@huawei.com> wrote: > >> > >>> Fix some spelling mistakes in comments: > >>> thats ==> that's > >>> unitialized ==> uninitialized > >>> panicing ==> panicking > >>> sucess ==> success > >>> possitive ==> positive > >>> intepreted ==> interpreted > >> > >> Thanks for the fix! Is it done with the help of the codespell tool? If > >> not, can you run it and check if it suggests more fixes? > > > > Yes, it's detected by codespell tool. But to avoid too many changes in one patch, I tried > > breaking it down into smaller patches(If it can be classified) to make it easier to review. > > In fact, the other patch I just posted included the rest. > > https://lkml.org/lkml/2021/6/7/151 > > All the remaining spelling mistakes are fixed by the patch above. I can combine the two of > them into one patch if you think it's necessary. No, it's good to keep them split. What I meant is to use the tool against the same subset of the files you have done your patch for. But please mention in the commit message that you have used that tool, so reviewers will not waste time on the comments like mine. -- With Best Regards, Andy Shevchenko
On 2021/6/7 17:06, Andy Shevchenko wrote: > On Mon, Jun 7, 2021 at 11:56 AM Leizhen (ThunderTown) > <thunder.leizhen@huawei.com> wrote: >> On 2021/6/7 16:52, Leizhen (ThunderTown) wrote: >>> On 2021/6/7 16:39, Andy Shevchenko wrote: >>>> On Mon, Jun 7, 2021 at 6:21 AM Zhen Lei <thunder.leizhen@huawei.com> wrote: >>>> >>>>> Fix some spelling mistakes in comments: >>>>> thats ==> that's >>>>> unitialized ==> uninitialized >>>>> panicing ==> panicking >>>>> sucess ==> success >>>>> possitive ==> positive >>>>> intepreted ==> interpreted >>>> >>>> Thanks for the fix! Is it done with the help of the codespell tool? If >>>> not, can you run it and check if it suggests more fixes? >>> >>> Yes, it's detected by codespell tool. But to avoid too many changes in one patch, I tried >>> breaking it down into smaller patches(If it can be classified) to make it easier to review. >>> In fact, the other patch I just posted included the rest. >> >> https://lkml.org/lkml/2021/6/7/151 >> >> All the remaining spelling mistakes are fixed by the patch above. I can combine the two of >> them into one patch if you think it's necessary. > > No, it's good to keep them split. What I meant is to use the tool > against the same subset of the files you have done your patch for. But > please mention in the commit message that you have used that tool, so > reviewers will not waste time on the comments like mine. Okay, thanks for the advice. > >
On Mon, Jun 7, 2021 at 6:18 AM Zhen Lei <thunder.leizhen@huawei.com> wrote: > > Fix some spelling mistakes in comments: > thats ==> that's > unitialized ==> uninitialized > panicing ==> panicking > sucess ==> success > possitive ==> positive > intepreted ==> interpreted > > Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> > --- > lib/test_bitops.c | 2 +- > lib/test_bpf.c | 2 +- > lib/test_kasan.c | 2 +- > lib/test_kmod.c | 6 +++--- > lib/test_scanf.c | 2 +- > 5 files changed, 7 insertions(+), 7 deletions(-) > > diff --git a/lib/test_bitops.c b/lib/test_bitops.c > index 471141ddd691..3b7bcbee84db 100644 > --- a/lib/test_bitops.c > +++ b/lib/test_bitops.c > @@ -15,7 +15,7 @@ > * get_count_order/long > */ > > -/* use an enum because thats the most common BITMAP usage */ > +/* use an enum because that's the most common BITMAP usage */ > enum bitops_fun { > BITOPS_4 = 4, > BITOPS_7 = 7, > diff --git a/lib/test_bpf.c b/lib/test_bpf.c > index 4dc4dcbecd12..d500320778c7 100644 > --- a/lib/test_bpf.c > +++ b/lib/test_bpf.c > @@ -1095,7 +1095,7 @@ static struct bpf_test tests[] = { > { > "RET_A", > .u.insns = { > - /* check that unitialized X and A contain zeros */ > + /* check that uninitialized X and A contain zeros */ > BPF_STMT(BPF_MISC | BPF_TXA, 0), > BPF_STMT(BPF_RET | BPF_A, 0) > }, > diff --git a/lib/test_kasan.c b/lib/test_kasan.c > index cacbbbdef768..72b8e808c39c 100644 > --- a/lib/test_kasan.c > +++ b/lib/test_kasan.c > @@ -656,7 +656,7 @@ static void kasan_global_oob(struct kunit *test) > { > /* > * Deliberate out-of-bounds access. To prevent CONFIG_UBSAN_LOCAL_BOUNDS > - * from failing here and panicing the kernel, access the array via a > + * from failing here and panicking the kernel, access the array via a > * volatile pointer, which will prevent the compiler from being able to > * determine the array bounds. > * > diff --git a/lib/test_kmod.c b/lib/test_kmod.c > index 38c250fbace3..ce1589391413 100644 > --- a/lib/test_kmod.c > +++ b/lib/test_kmod.c > @@ -286,7 +286,7 @@ static int tally_work_test(struct kmod_test_device_info *info) > * If this ran it means *all* tasks were created fine and we > * are now just collecting results. > * > - * Only propagate errors, do not override with a subsequent sucess case. > + * Only propagate errors, do not override with a subsequent success case. > */ > static void tally_up_work(struct kmod_test_device *test_dev) > { > @@ -543,7 +543,7 @@ static int trigger_config_run(struct kmod_test_device *test_dev) > * wrong with the setup of the test. If the test setup went fine > * then userspace must just check the result of config->test_result. > * One issue with relying on the return from a call in the kernel > - * is if the kernel returns a possitive value using this trigger > + * is if the kernel returns a positive value using this trigger > * will not return the value to userspace, it would be lost. > * > * By not relying on capturing the return value of tests we are using > @@ -585,7 +585,7 @@ trigger_config_store(struct device *dev, > * Note: any return > 0 will be treated as success > * and the error value will not be available to userspace. > * Do not rely on trying to send to userspace a test value > - * return value as possitive return errors will be lost. > + * return value as positive return errors will be lost. > */ > if (WARN_ON(ret > 0)) > return -EINVAL; > diff --git a/lib/test_scanf.c b/lib/test_scanf.c > index 48ff5747a4da..84fe09eaf55e 100644 > --- a/lib/test_scanf.c > +++ b/lib/test_scanf.c > @@ -600,7 +600,7 @@ static void __init numbers_prefix_overflow(void) > /* > * 0x prefix in a field of width 2 using %i conversion: first field > * converts to 0. Next field scan starts at the character after "0x", > - * which will convert if can be intepreted as decimal but will fail > + * which will convert if can be interpreted as decimal but will fail > * if it contains any hex digits (since no 0x prefix). > */ > test_number_prefix(long long, "0x67", "%2lli%lli", 0, 67, 2, check_ll); > -- > 2.25.1 For lib/test_kasan.c: Acked-by: Andrey Konovalov <andreyknvl@gmail.com>
diff --git a/lib/test_bitops.c b/lib/test_bitops.c index 471141ddd691..3b7bcbee84db 100644 --- a/lib/test_bitops.c +++ b/lib/test_bitops.c @@ -15,7 +15,7 @@ * get_count_order/long */ -/* use an enum because thats the most common BITMAP usage */ +/* use an enum because that's the most common BITMAP usage */ enum bitops_fun { BITOPS_4 = 4, BITOPS_7 = 7, diff --git a/lib/test_bpf.c b/lib/test_bpf.c index 4dc4dcbecd12..d500320778c7 100644 --- a/lib/test_bpf.c +++ b/lib/test_bpf.c @@ -1095,7 +1095,7 @@ static struct bpf_test tests[] = { { "RET_A", .u.insns = { - /* check that unitialized X and A contain zeros */ + /* check that uninitialized X and A contain zeros */ BPF_STMT(BPF_MISC | BPF_TXA, 0), BPF_STMT(BPF_RET | BPF_A, 0) }, diff --git a/lib/test_kasan.c b/lib/test_kasan.c index cacbbbdef768..72b8e808c39c 100644 --- a/lib/test_kasan.c +++ b/lib/test_kasan.c @@ -656,7 +656,7 @@ static void kasan_global_oob(struct kunit *test) { /* * Deliberate out-of-bounds access. To prevent CONFIG_UBSAN_LOCAL_BOUNDS - * from failing here and panicing the kernel, access the array via a + * from failing here and panicking the kernel, access the array via a * volatile pointer, which will prevent the compiler from being able to * determine the array bounds. * diff --git a/lib/test_kmod.c b/lib/test_kmod.c index 38c250fbace3..ce1589391413 100644 --- a/lib/test_kmod.c +++ b/lib/test_kmod.c @@ -286,7 +286,7 @@ static int tally_work_test(struct kmod_test_device_info *info) * If this ran it means *all* tasks were created fine and we * are now just collecting results. * - * Only propagate errors, do not override with a subsequent sucess case. + * Only propagate errors, do not override with a subsequent success case. */ static void tally_up_work(struct kmod_test_device *test_dev) { @@ -543,7 +543,7 @@ static int trigger_config_run(struct kmod_test_device *test_dev) * wrong with the setup of the test. If the test setup went fine * then userspace must just check the result of config->test_result. * One issue with relying on the return from a call in the kernel - * is if the kernel returns a possitive value using this trigger + * is if the kernel returns a positive value using this trigger * will not return the value to userspace, it would be lost. * * By not relying on capturing the return value of tests we are using @@ -585,7 +585,7 @@ trigger_config_store(struct device *dev, * Note: any return > 0 will be treated as success * and the error value will not be available to userspace. * Do not rely on trying to send to userspace a test value - * return value as possitive return errors will be lost. + * return value as positive return errors will be lost. */ if (WARN_ON(ret > 0)) return -EINVAL; diff --git a/lib/test_scanf.c b/lib/test_scanf.c index 48ff5747a4da..84fe09eaf55e 100644 --- a/lib/test_scanf.c +++ b/lib/test_scanf.c @@ -600,7 +600,7 @@ static void __init numbers_prefix_overflow(void) /* * 0x prefix in a field of width 2 using %i conversion: first field * converts to 0. Next field scan starts at the character after "0x", - * which will convert if can be intepreted as decimal but will fail + * which will convert if can be interpreted as decimal but will fail * if it contains any hex digits (since no 0x prefix). */ test_number_prefix(long long, "0x67", "%2lli%lli", 0, 67, 2, check_ll);
Fix some spelling mistakes in comments: thats ==> that's unitialized ==> uninitialized panicing ==> panicking sucess ==> success possitive ==> positive intepreted ==> interpreted Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> --- lib/test_bitops.c | 2 +- lib/test_bpf.c | 2 +- lib/test_kasan.c | 2 +- lib/test_kmod.c | 6 +++--- lib/test_scanf.c | 2 +- 5 files changed, 7 insertions(+), 7 deletions(-) -- 2.25.1