linux-kernel - Re: [PATCH v3 07/15] arm64: dts: qcom: sc8180x: Add interconnects and lmh

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230601132717.yslaigqg4lprkniv@ripper>
Date:   Thu, 1 Jun 2023 06:27:17 -0700
From:   Bjorn Andersson <andersson@...nel.org>
To:     Vinod Koul <vkoul@...nel.org>
Cc:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        linux-arm-msm@...r.kernel.org,
        Konrad Dybcio <konrad.dybcio@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley <conor+dt@...nel.org>, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 07/15] arm64: dts: qcom: sc8180x: Add interconnects
 and lmh

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@...aro.org>
> > > Signed-off-by: Bjorn Andersson <bjorn.andersson@...aro.org>
> > > Signed-off-by: Vinod Koul <vkoul@...nel.org>
> > > ---
> > 
> > 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.

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.

And it's not until patch 14 that any of this content is introduced to
the build system, so it's not split to ensure bisectability etc.


I'd be perfectly happy to have received the dts changes as 3-4 patches.

Regards,
Bjorn