Re: [PATCH] ARC:kernel:Fix typos in comments
On 6/22/22 00:52, Jilin Yuan wrote: Delete the redundant word 'call'. Signed-off-by: Jilin Yuan --- arch/arc/kernel/smp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arc/kernel/smp.c b/arch/arc/kernel/smp.c index d947473f1e6d..6c22a53711e9 100644 --- a/arch/arc/kernel/smp.c +++ b/arch/arc/kernel/smp.c @@ -393,7 +393,7 @@ irqreturn_t do_IPI(int irq, void *dev_id) * API called by platform code to hookup arch-common ISR to their IPI IRQ * * Note: If IPI is provided by platform (vs. say ARC MCIP), their intc setup/map - * function needs to call call irq_set_percpu_devid() for IPI IRQ, otherwise + * function needs to call irq_set_percpu_devid() for IPI IRQ, otherwise * request_percpu_irq() below will fail */ static DEFINE_PER_CPU(int, ipi_dev); I'd prefer to have this is the other fix in a single change. No point increasing commits for trivial things. -Vineet ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] ARC:mm:Fix syntax errors in comments
On 6/22/22 01:30, Bagas Sanjaya wrote:
- * If the U-mapping is not congruent to to K-mapping, former needs flushing.
+ * If the U-mapping is not congruent to K-mapping, former needs flushing.
*/
void flush_dcache_page(struct page *page)
{
The patch is OK, but its subject is wrong.
Right.
The patch above isn't fixing any syntax errors, but rather minor cleanup.
The subject should have been "Remove duplicate 'to' in the
flush_dcache_page() comment".
I'd just say "ARC: mm: fix typos"
I think that this kind of cleanup patches (typofixes) are best done
as part of **actual** work on the code in question (for example
refactoring or fixing build errors).
In an ideal world yes. But sometimes maintainer complain to break
whitespacxe fixes and such into independent fix. Also as someone said
later in the thread, for somebody just getting into kernel and figuring
out patch submission etc this could be a perfect dry run and helps
improve the code anyways.
-Vineet
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] ARC:mm:Fix syntax errors in comments
On Wed, 22 Jun 2022, Bagas Sanjaya wrote: > On 6/22/22 16:38, Julia Lawall wrote: > >>> So code that is fine will have typos forever? Fixing typos in comments > >>> doesn't break git blame for the following code. And typos in comments > >>> give a bad impression about the state of the code in general. > >> > >> Of course not! Documentation is as important as the code, if not even more. > >> However, fixing typos to increase your commit counts to a reputable project > >> is not fine either. For instance, many of these proposed fixes are > >> targeting > >> one single typo at a time. Couldn't they just be sent altogether!?! > > > > I have the impression that the person is just trying to figure out the > > patch submission process. For example, the subject lines are not > > formatter in the standard way (I sent the person a private email about > > that). Perhaps just let him know about how you would rather have received > > the patches. > > In recent times I had seen many typofix patches sent to LKML. You can see most > of them by querying `s:"fix typo"` on lore.kernel.org. Some of these patches > have been merged, though. > > What I say as starter thread is "ideal" scenario as described in > Documentation/process/2.Process.rst; that is we prefer to see these minor > fixes as part of real patches work (say refactoring), rather than just being > trivial patches. > > But what most reviewers here missed is how these typos are found? I guess > these can be from codespell or some other tools, or even manual review, > then send the fixes en mass. > > Take a look at "fix typo in a comment" aka "delete redundant word" patches > at [1], [2], [3]. and [4]. > > [1]: https://lore.kernel.org/lkml/20220618132659.17100-1-wangxi...@cdjrlc.com/ > [2]: https://lore.kernel.org/lkml/20220618130349.11507-1-wangxi...@cdjrlc.com/ > [3]: https://lore.kernel.org/lkml/20220616163830.11366-1-wangxi...@cdjrlc.com/ > [4]: https://lore.kernel.org/lkml/20220606123419.29109-1-wangxi...@cdjrlc.com/ > > IMHO, these patches should have been in a single, consolidated patch, since > these strip duplicate (hence redundant) word (single logical change). They go to different maintainers, so perhaps each one would prefer to get their own patches? There was a trivial tree, but it is apparently not very active. It would indeed be good to indicate how the problems were found. That could suggest whether the problem has been addressed comprehensively, or whether just some random issues have been detected. julia ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] ARC:mm:Fix syntax errors in comments
On 6/22/22 16:38, Julia Lawall wrote: >>> So code that is fine will have typos forever? Fixing typos in comments >>> doesn't break git blame for the following code. And typos in comments >>> give a bad impression about the state of the code in general. >> >> Of course not! Documentation is as important as the code, if not even more. >> However, fixing typos to increase your commit counts to a reputable project >> is not fine either. For instance, many of these proposed fixes are targeting >> one single typo at a time. Couldn't they just be sent altogether!?! > > I have the impression that the person is just trying to figure out the > patch submission process. For example, the subject lines are not > formatter in the standard way (I sent the person a private email about > that). Perhaps just let him know about how you would rather have received > the patches. In recent times I had seen many typofix patches sent to LKML. You can see most of them by querying `s:"fix typo"` on lore.kernel.org. Some of these patches have been merged, though. What I say as starter thread is "ideal" scenario as described in Documentation/process/2.Process.rst; that is we prefer to see these minor fixes as part of real patches work (say refactoring), rather than just being trivial patches. But what most reviewers here missed is how these typos are found? I guess these can be from codespell or some other tools, or even manual review, then send the fixes en mass. Take a look at "fix typo in a comment" aka "delete redundant word" patches at [1], [2], [3]. and [4]. [1]: https://lore.kernel.org/lkml/20220618132659.17100-1-wangxi...@cdjrlc.com/ [2]: https://lore.kernel.org/lkml/20220618130349.11507-1-wangxi...@cdjrlc.com/ [3]: https://lore.kernel.org/lkml/20220616163830.11366-1-wangxi...@cdjrlc.com/ [4]: https://lore.kernel.org/lkml/20220606123419.29109-1-wangxi...@cdjrlc.com/ IMHO, these patches should have been in a single, consolidated patch, since these strip duplicate (hence redundant) word (single logical change). Thanks. -- An old man doll... just what I always wanted! - Clara ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] ARC:mm:Fix syntax errors in comments
On Wed, 22 Jun 2022, Shahab Vahedi wrote: > On 6/22/22 11:16, Julia Lawall wrote: > > > > > > On Wed, 22 Jun 2022, Shahab Vahedi wrote: > > > >> On 6/22/22 10:30, Bagas Sanjaya wrote: > >> > >>> I think that this kind of cleanup patches (typofixes) are best done > >>> as part of **actual** work on the code in question (for example > >>> refactoring or fixing build errors). > >> > >> Amen! > > > > So code that is fine will have typos forever? Fixing typos in comments > > doesn't break git blame for the following code. And typos in comments > > give a bad impression about the state of the code in general. > > Of course not! Documentation is as important as the code, if not even more. > However, fixing typos to increase your commit counts to a reputable project > is not fine either. For instance, many of these proposed fixes are targeting > one single typo at a time. Couldn't they just be sent altogether!?! I have the impression that the person is just trying to figure out the patch submission process. For example, the subject lines are not formatter in the standard way (I sent the person a private email about that). Perhaps just let him know about how you would rather have received the patches. julia ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] ARC:mm:Fix syntax errors in comments
On Wed, 22 Jun 2022, Shahab Vahedi wrote: > On 6/22/22 10:30, Bagas Sanjaya wrote: > > > I think that this kind of cleanup patches (typofixes) are best done > > as part of **actual** work on the code in question (for example > > refactoring or fixing build errors). > > Amen! So code that is fine will have typos forever? Fixing typos in comments doesn't break git blame for the following code. And typos in comments give a bad impression about the state of the code in general. But that is a general statement. Perhaps this code does particularly need work. julia ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] ARC:mm:Fix syntax errors in comments
On Wed, Jun 22, 2022 at 04:04:23PM +0800, Jilin Yuan wrote:
> Delete the redundant word 'to'.
>
> Signed-off-by: Jilin Yuan
> ---
> arch/arc/mm/cache.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arc/mm/cache.c b/arch/arc/mm/cache.c
> index 5446967ea98d..84fe78c41c37 100644
> --- a/arch/arc/mm/cache.c
> +++ b/arch/arc/mm/cache.c
> @@ -750,7 +750,7 @@ static inline void arc_slc_enable(void)
> * -In SMP, if hardware caches are coherent
> *
> * There's a corollary case, where kernel READs from a userspace mapped page.
> - * If the U-mapping is not congruent to to K-mapping, former needs flushing.
> + * If the U-mapping is not congruent to K-mapping, former needs flushing.
> */
> void flush_dcache_page(struct page *page)
> {
The patch is OK, but its subject is wrong.
The patch above isn't fixing any syntax errors, but rather minor cleanup.
The subject should have been "Remove duplicate 'to' in the
flush_dcache_page() comment".
I think that this kind of cleanup patches (typofixes) are best done
as part of **actual** work on the code in question (for example
refactoring or fixing build errors).
Thanks.
--
An old man doll... just what I always wanted! - Clara
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH] ARC:mm:Fix syntax errors in comments
Delete the redundant word 'to'.
Signed-off-by: Jilin Yuan
---
arch/arc/mm/cache.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arc/mm/cache.c b/arch/arc/mm/cache.c
index 5446967ea98d..84fe78c41c37 100644
--- a/arch/arc/mm/cache.c
+++ b/arch/arc/mm/cache.c
@@ -750,7 +750,7 @@ static inline void arc_slc_enable(void)
* -In SMP, if hardware caches are coherent
*
* There's a corollary case, where kernel READs from a userspace mapped page.
- * If the U-mapping is not congruent to to K-mapping, former needs flushing.
+ * If the U-mapping is not congruent to K-mapping, former needs flushing.
*/
void flush_dcache_page(struct page *page)
{
--
2.36.1
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH] ARC:kernel:Fix typos in comments
Delete the redundant word 'call'. Signed-off-by: Jilin Yuan --- arch/arc/kernel/smp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arc/kernel/smp.c b/arch/arc/kernel/smp.c index d947473f1e6d..6c22a53711e9 100644 --- a/arch/arc/kernel/smp.c +++ b/arch/arc/kernel/smp.c @@ -393,7 +393,7 @@ irqreturn_t do_IPI(int irq, void *dev_id) * API called by platform code to hookup arch-common ISR to their IPI IRQ * * Note: If IPI is provided by platform (vs. say ARC MCIP), their intc setup/map - * function needs to call call irq_set_percpu_devid() for IPI IRQ, otherwise + * function needs to call irq_set_percpu_devid() for IPI IRQ, otherwise * request_percpu_irq() below will fail */ static DEFINE_PER_CPU(int, ipi_dev); -- 2.36.1 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
