On 3/6/20 4:19 PM, Joseph Myers wrote: > On Fri, 6 Mar 2020, Vineet Gupta wrote: > >> Signed-off-by: Vineet Gupta <vgupta@xxxxxxxxxxxx> >> --- >> .../sysv/linux/arc/bits/socket-constants.h | 4 +-- > > There is a general principle for patch series: you should not have later > patches fixing up things that were wrong with earlier patches. Each patch > should add files in the form desired to be reviewed, not in a form that > gets fixed up later. > > (Sometimes a patch series might change a file that was correct in an > earlier patch in the series, as part of adding additional features, if the > first M patches add feature X and the next N add feature Y on top of it. > But that's not the case here - such later patches should not make > incompatible changes to earlier ones.) I agree and you've mentioned this fact before as well. The only reason I carved it this way was to ease my testing. The 64-bit time code was based on RV32 which in turn was based on bleeding edge upstream some of which needed additional work for ARC but ininitial days of 64-bit work, it was hard to know if the fix was needed for 64-bit or for upstream tracking. And that's exactly what I got bitten by - when I missed the fixup for init constructor invocation from Florian, wasting 3 days [1] Anyhow that's just to give you the context. I can split them up and add to respective sections for next iteration. If we end up not doing another iteration - hypothetically speaking :-) the whole port is anyhow committed as 1 patch so it doesn't matter. [1] http://lists.infradead.org/pipermail/linux-snps-arc/2020-February/006974.html _______________________________________________ linux-snps-arc mailing list linux-snps-arc@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/linux-snps-arc
