| Message ID | 20220908124937.25962-1-wangjianli@cdjrlc.com |
|---|---|
| State | New |
| Headers | show |
| Series | drivers/ata: fix repeated words in comments | expand |
On 08/09/2022 13:49, wangjianli wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > Delete the redundant word 'in'. > > Signed-off-by: wangjianli <wangjianli@cdjrlc.com> > --- > drivers/ata/libata-eh.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c > index 7c128c89b454..ca865a95cf24 100644 > --- a/drivers/ata/libata-eh.c > +++ b/drivers/ata/libata-eh.c > @@ -863,7 +863,7 @@ void ata_eh_fastdrain_timerfn(struct timer_list *t) > * > * Set ATA_PFLAG_EH_PENDING and activate fast drain if @fastdrain > * is non-zero and EH wasn't pending before. Fast drain ensures > - * that EH kicks in in timely manner. > + * that EH kicks in timely manner. Hey wangjianli, This does not look like the right fix to me.. To me, it looks like it should be s/in in/in in a/. If you're using an automated tool, which I can only assume you are, to find these typos it'd be a good idea to check the output for correctness prior to sending patches. Thanks, Conor. > * > * LOCKING: > * spin_lock_irqsave(host lock) > -- > 2.36.1 >
On Thu, 2022-09-08 at 12:56 +0000, Conor.Dooley@microchip.com wrote: > On 08/09/2022 13:49, wangjianli wrote: > > EXTERNAL EMAIL: Do not click links or open attachments unless you > > know the content is safe > > > > Delete the redundant word 'in'. > > > > Signed-off-by: wangjianli <wangjianli@cdjrlc.com> > > --- > > drivers/ata/libata-eh.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c > > index 7c128c89b454..ca865a95cf24 100644 > > --- a/drivers/ata/libata-eh.c > > +++ b/drivers/ata/libata-eh.c > > @@ -863,7 +863,7 @@ void ata_eh_fastdrain_timerfn(struct timer_list > > *t) > > * > > * Set ATA_PFLAG_EH_PENDING and activate fast drain if > > @fastdrain > > * is non-zero and EH wasn't pending before. Fast drain > > ensures > > - * that EH kicks in in timely manner. > > + * that EH kicks in timely manner. > > Hey wangjianli, > This does not look like the right fix to me.. To me, it looks like it > should be s/in in/in in a/. > > If you're using an automated tool, which I can only assume you are, > to find these typos it'd be a good idea to check the output for > correctness prior to sending patches. And it would also have been nice to accommodate the exact same feedback last time these patches were posted: https://lore.kernel.org/all/cec12e246d7151f6041bf553629a3047e81d4afe.camel@HansenPartnership.com/ It's really disappointing you haven't accommodated any feedback either into your bot or the patches it sends. Not doing so really does render this work largely useless. James
On 08/09/2022 14:02, James Bottomley wrote: > [You don't often get email from james.bottomley@hansenpartnership.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] > > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > On Thu, 2022-09-08 at 12:56 +0000, Conor.Dooley@microchip.com wrote: >> On 08/09/2022 13:49, wangjianli wrote: >>> EXTERNAL EMAIL: Do not click links or open attachments unless you >>> know the content is safe >>> >>> Delete the redundant word 'in'. >>> >>> Signed-off-by: wangjianli <wangjianli@cdjrlc.com> >>> --- >>> drivers/ata/libata-eh.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c >>> index 7c128c89b454..ca865a95cf24 100644 >>> --- a/drivers/ata/libata-eh.c >>> +++ b/drivers/ata/libata-eh.c >>> @@ -863,7 +863,7 @@ void ata_eh_fastdrain_timerfn(struct timer_list >>> *t) >>> * >>> * Set ATA_PFLAG_EH_PENDING and activate fast drain if >>> @fastdrain >>> * is non-zero and EH wasn't pending before. Fast drain >>> ensures >>> - * that EH kicks in in timely manner. >>> + * that EH kicks in timely manner. >> >> Hey wangjianli, >> This does not look like the right fix to me.. To me, it looks like it >> should be s/in in/in in a/. >> >> If you're using an automated tool, which I can only assume you are, >> to find these typos it'd be a good idea to check the output for >> correctness prior to sending patches. > > And it would also have been nice to accommodate the exact same feedback > last time these patches were posted: > > https://lore.kernel.org/all/cec12e246d7151f6041bf553629a3047e81d4afe.camel@HansenPartnership.com/ > > It's really disappointing you haven't accommodated any feedback either > into your bot or the patches it sends. Not doing so really does render > this work largely useless. I've been replying a bit to these typo "fixes" that are not fixes since I am a native speaker and maybe some things get lost in translation but I have pretty much never got responses from the patch submitters. It's a little bit frustrating since fairly often, the fix is not to remove the dupe, but instead s/in in/is in/ etc. If there's a tool running against this stuff but maintainers are not applying the patches as the "fixes" are not fixes it's only going to keep generating the same patches over and over is it not?
On Thu, 2022-09-08 at 13:09 +0000, Conor.Dooley@microchip.com wrote: [...] > If there's a tool running against this stuff but maintainers are not > applying the patches as the "fixes" are not fixes it's only going to > keep generating the same patches over and over is it not? That's up to the maintainers, but it's fairly easy to ignore patches from given sources however often they are repeated. There's a lot of wrong patches that keep getting repeated ... My own take is that the value would be marginal if all the patches were correct, but they could be applied with minimal effort using patch automation. Once you have to verify correctness of each patch, I don't think the tracking and verification effort is worth the marginal improvement, but that's a maintainer call. Regards, James
On 2022/09/08 22:02, James Bottomley wrote: > On Thu, 2022-09-08 at 12:56 +0000, Conor.Dooley@microchip.com wrote: >> On 08/09/2022 13:49, wangjianli wrote: >>> EXTERNAL EMAIL: Do not click links or open attachments unless you >>> know the content is safe >>> >>> Delete the redundant word 'in'. >>> >>> Signed-off-by: wangjianli <wangjianli@cdjrlc.com> >>> --- >>> drivers/ata/libata-eh.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c >>> index 7c128c89b454..ca865a95cf24 100644 >>> --- a/drivers/ata/libata-eh.c >>> +++ b/drivers/ata/libata-eh.c >>> @@ -863,7 +863,7 @@ void ata_eh_fastdrain_timerfn(struct timer_list >>> *t) >>> * >>> * Set ATA_PFLAG_EH_PENDING and activate fast drain if >>> @fastdrain >>> * is non-zero and EH wasn't pending before. Fast drain >>> ensures >>> - * that EH kicks in in timely manner. >>> + * that EH kicks in timely manner. >> >> Hey wangjianli, >> This does not look like the right fix to me.. To me, it looks like it >> should be s/in in/in in a/. >> >> If you're using an automated tool, which I can only assume you are, >> to find these typos it'd be a good idea to check the output for >> correctness prior to sending patches. > > And it would also have been nice to accommodate the exact same feedback > last time these patches were posted: > > https://lore.kernel.org/all/cec12e246d7151f6041bf553629a3047e81d4afe.camel@HansenPartnership.com/ > > It's really disappointing you haven't accommodated any feedback either > into your bot or the patches it sends. Not doing so really does render > this work largely useless. And another submitter sent a similar incorrect "fix", twice, ignoring my comments. I am OK with applying such fixes, even though they have little value. But the submitter has to be willing to listen and fix their patches. I will not do that for them :)
diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c index 7c128c89b454..ca865a95cf24 100644 --- a/drivers/ata/libata-eh.c +++ b/drivers/ata/libata-eh.c @@ -863,7 +863,7 @@ void ata_eh_fastdrain_timerfn(struct timer_list *t) * * Set ATA_PFLAG_EH_PENDING and activate fast drain if @fastdrain * is non-zero and EH wasn't pending before. Fast drain ensures - * that EH kicks in in timely manner. + * that EH kicks in timely manner. * * LOCKING: * spin_lock_irqsave(host lock)
Delete the redundant word 'in'. Signed-off-by: wangjianli <wangjianli@cdjrlc.com> --- drivers/ata/libata-eh.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)