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]
Date:   Thu, 1 Jun 2023 17:27:21 +0200
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Bjorn Andersson <andersson@...nel.org>,
        Vinod Koul <vkoul@...nel.org>
Cc:     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 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@...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.

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.

Best regards,
Krzysztof

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ