Delete the redundant word 'in'.
Signed-off-by: wangjianli <[email protected]>
---
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.
*
* LOCKING:
* spin_lock_irqsave(host lock)
--
2.36.1
On 08/09/2022 14:02, James Bottomley wrote:
> [You don't often get email from [email protected]. 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, [email protected] 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 <[email protected]>
>>> ---
>>> 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 12:56 +0000, [email protected] 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 <[email protected]>
> > ---
> > 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 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 <[email protected]>
> ---
> 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 13:09 +0000, [email protected] 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, [email protected] 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 <[email protected]>
>>> ---
>>> 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 :)
--
Damien Le Moal
Western Digital Research