From: Sam Edwards <sam@turingpi.com>
To: Andi Shyti <andi.shyti@kernel.org>
Cc: Gregory CLEMENT <gregory.clement@bootlin.com>,
linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RESEND RFC PATCH 0/5] Enhancements for mv64xxx I2C driver
Date: Thu, 21 Mar 2024 00:24:43 -0600 [thread overview]
Message-ID: <4a043be8-8e88-4b92-913c-abd8f138b90d@turingpi.com> (raw)
In-Reply-To: <p37qqpplxgmfzlq6wz7fvmvnrsumy6ra5nivzi4hd2gbvlbezx@dlh6ygyjbk24>
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
next prev parent reply other threads:[~2024-03-21 6:24 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-20 4:19 [RESEND RFC PATCH 0/5] Enhancements for mv64xxx I2C driver Sam Edwards
2024-03-21 2:28 ` Andi Shyti
2024-03-21 6:24 ` Sam Edwards [this message]
2024-03-21 20:54 ` Andi Shyti
2024-03-21 22:00 ` Sam Edwards
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4a043be8-8e88-4b92-913c-abd8f138b90d@turingpi.com \
--to=sam@turingpi.com \
--cc=andi.shyti@kernel.org \
--cc=gregory.clement@bootlin.com \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).