linux-kernel - Re: [RESEND RFC PATCH 0/5] Enhancements for mv64xxx I2C driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4a043be8-8e88-4b92-913c-abd8f138b90d@turingpi.com>
Date: Thu, 21 Mar 2024 00:24:43 -0600
From: Sam Edwards <sam@...ingpi.com>
To: Andi Shyti <andi.shyti@...nel.org>
Cc: Gregory CLEMENT <gregory.clement@...tlin.com>, linux-i2c@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [RESEND RFC PATCH 0/5] Enhancements for mv64xxx I2C driver

On 3/20/24 20:28, Andi Shyti wrote:
> Hi Sam,
> 
> Thanks for your patches.
> 
>> Sorry about the resend; it seems my mail client "helpfully" swallowed the
>> newlines on any line consisting only of whitespace, garbling the patches.
> 
> I received three series from you:
> 
>   1. [RESEND v2 RFC 1/5] i2c: mv64xxx: Clear bus errors before transfer
>   2. [RFC PATCH 0/5] Enhancements for mv64xxx I2C driver
>   3. [RESEND RFC PATCH 0/5] Enhancements for mv64xxx I2C driver
> 
> By the versioning, 1. is good, the rest is not good. Standing to
> the time sent and comments in patch '0', 3. is good, the rest
> not.
> 
> Which one should be discarded? Can you please state it clearly?

Hi Andi,

Thanks so much for your patience -- this is the first series I sent with 
this particular mail client and it really didn't go as smoothly as a 
plain git-send-email. I'll get it nailed down in time for the non-RFC 
series.

I sent the series in the order 2-3-1, so 1 is the version to look at 
(though I made no content changes between resends as I was only fighting 
my mail client's formatting).

> 
> Besides, youre mails are not threaded, They look like:
> 
>     Mar 19 Sam Edwards     (2.3K) [RESEND RFC PATCH 0/5] Enhancements for mv64xxx I2C driver
>     Mar 19 Sam Edwards     (2.3K) [RESEND RFC PATCH 1/5] i2c: mv64xxx: Clear bus errors before transfer
>     Mar 19 Sam Edwards     (2.3K) [RESEND RFC PATCH 2/5] i2c: mv64xxx: Clean up the private data struct
>     Mar 19 Sam Edwards     ( 15K) [RESEND RFC PATCH 3/5] i2c: mv64xxx: Refactor FSM
>     Mar 19 Sam Edwards     (5.2K) [RESEND RFC PATCH 4/5] i2c: mv64xxx: Allow continuing after read
>     Mar 19 Sam Edwards     ( 11K) [RESEND RFC PATCH 5/5] i2c: mv64xxx: Implement I2C_FUNC_NOSTART
> 
> instead of
> 
>     Mar 19 Sam Edwards     (2.3K) [RESEND RFC PATCH 0/5] Enhancements for mv64xxx I2C driver
>     Mar 19 Sam Edwards     (2.3K) ├─>[RESEND RFC PATCH 1/5] i2c: mv64xxx: Clear bus errors before transfer
>     Mar 19 Sam Edwards     (2.3K) ├─>[RESEND RFC PATCH 2/5] i2c: mv64xxx: Clean up the private data struct
>     Mar 19 Sam Edwards     ( 15K) ├─>[RESEND RFC PATCH 3/5] i2c: mv64xxx: Refactor FSM
>     Mar 19 Sam Edwards     (5.2K) ├─>[RESEND RFC PATCH 4/5] i2c: mv64xxx: Allow continuing after read
>     Mar 19 Sam Edwards     ( 11K) └─>[RESEND RFC PATCH 5/5] i2c: mv64xxx: Implement I2C_FUNC_NOSTART
> 
> Which is the default of "git format-patch".
> 
> Can you please make sure, next time (unless someone asks to
> resend them again), that the patches are threaded? You can send
> them to yourself first and see if they are really threaded.

Yes, definitely. I take it from your phrasing that you're willing to 
collect the scattered mails yourself this one time only? If so, thank 
you for cleaning up after my mess. :)

If not (and/or if someone else doesn't like the mess), I can always 
resend. I have already made one cleanup (removing the useless `default:` 
at the end of the FSM) so I guess it would technically be an "RFC v2" at 
this point.

> If you are using some weird mail client, you can also check the
> mail header, making sure that mails from 1 to 5 have the field:
> 
>     In-Reply-To: <Message-Id of patch 0>
> 
> Andi

Cheers,
Sam