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

[Sam Edwards]

Hi Andi,

On 3/21/24 14:54, Andi Shyti wrote:
> so that it's the [RFC v2 ...] the right series... are you sure?

[RESEND v2 RFC ...] -- it's the second resend (thus third send), not the 
second RFC (in retrospect I definitely should have used # instead of v)

> The order of arrival is:
>
>   1. Date: Tue, 19 Mar 2024 16:51:51 -0600
>   2. Date: Tue, 19 Mar 2024 19:40:51 -0600
>   3. Date: Tue, 19 Mar 2024 22:19:53 -0600
>
> Anyway, I will take "1" as the good one, being a v2. I will
> discard "2" and "3".
>
> Then, please, do not forget next time the patch 0 and the
> changelog.

Patch 0 was probably separated by the lack of threading but can be found 
here: https://www.spinics.net/lists/linux-i2c/msg68235.html

There is no changelog as there were no changes to the patch content vs. 
either of the first two sending attempts; I was only trying a different 
way of navigating the minefield of mail agents that make whitespace 
changes without my consent. :)

> ...
>
> > > 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.
>
> For now no need to resend (unless someone complains). Let's give
> it some time for review.
>
> Andi

Thanks again,
Sam