On Thu, Jun 01, 2023 at 05:27:21PM +0200, Krzysztof Kozlowski wrote: > On 01/06/2023 15:27, Bjorn Andersson wrote: > > On Thu, Jun 01, 2023 at 12:47:03PM +0530, Vinod Koul wrote: > >> On 31-05-23, 10:26, Krzysztof Kozlowski wrote: > >>> On 30/05/2023 18:24, Vinod Koul wrote: > >>>> This add interconnect nodes and add LMH to sc8180x SoC dtsi > >>>> > >>>> Co-developed-by: Bjorn Andersson <bjorn.andersson@xxxxxxxxxx> > >>>> Signed-off-by: Bjorn Andersson <bjorn.andersson@xxxxxxxxxx> > >>>> Signed-off-by: Vinod Koul <vkoul@xxxxxxxxxx> > >>>> --- > >>> > >>> I don't understand why this was split. We talked on IRC many times on > >>> this - artificial splits are not "release early, release often". Your > >>> previous patchset was correct in that approach, but why this is separate > >>> patch? > >> > >> Coz the patch was big to review. This is usual Linux approach to break a > >> change into smaller chunks for review! > >> > > > > We break patches into small, logical units so that it's easy to follow > > the thought through each step in the process of introducing a change. > > For example splitting interconnects which are essential part of several > IP blocks is not making it easy. One patch introduces incomplete block > which is then fixed (completed) in next patch. > > > > > This is not the same thing as splitting one logical change into multiple > > smaller patches to keep the line count of each patch down. This just > > forces the reviewer to jump between emails to get the full picture of > > the logical change. > > Reviewer has to jump here to see full picture of UART or some other IP > block. > Sorry if it wasn't clear, I'm trying to make the same argument as you, Krzysztof. The way to split such series would be to introduce some minimal bootable board, and then extend that in a bisectable fashion. But given that both contributor and maintainer primarily care about the whole set at this stage, I'd generally prefer longer patches. Regards, Bjorn
