Messages in this thread | | | Date | Thu, 21 Mar 2024 16:00:53 -0600 | Subject | Re: [RESEND RFC PATCH 0/5] Enhancements for mv64xxx I2C driver | From | 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
| |