Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <3a73cf7f02915891c77dc5a3203dc187f6d91194.camel@HansenPartnership.com>
Subject: Re: [PATCH] drivers/ata: fix repeated words in comments
From:   James Bottomley <James.Bottomley@HansenPartnership.com>
To:     Conor.Dooley@microchip.com, wangjianli@cdjrlc.com,
        damien.lemoal@opensource.wdc.com
Cc:     linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org
Date:   Thu, 08 Sep 2022 09:02:20 -0400
In-Reply-To: <e2f882f7-6871-a754-fbbd-6a5201f45f4a@microchip.com>
References: <20220908124937.25962-1-wangjianli@cdjrlc.com>
         <e2f882f7-6871-a754-fbbd-6a5201f45f4a@microchip.com>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.34.4 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: bulk

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